[Bug libfortran/21354] [4.0 only] Rank 7 not handled correctly

[tkoenig at gcc dot gnu dot org]

--- Additional Comments From tkoenig at gcc dot gnu dot org  2005-05-06 
07:30 ---
Fixed in 4.1, still needs to be applied to 4.0.

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |tkoenig at gcc dot gnu dot
   |dot org |org
URL||http://gcc.gnu.org/ml/fortra
   ||n/2005-05/msg00034.html
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed||1
  Known to fail||4.0.0
  Known to work||4.1.0
   Last reconfirmed|-00-00 00:00:00 |2005-05-06 07:30:53
   date||
Summary|Rank 7 not handled correctly|[4.0 only] Rank 7 not
   ||handled correctly
   Target Milestone|--- |4.0.1


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

[Bug debug/19885] [4.0/4.1 Regression] avr dwarf-2 support is broken for head 4.0/4.1

[bjoern dot m dot haase at web dot de]

--- Additional Comments From bjoern dot m dot haase at web dot de  
2005-05-06 07:44 ---
It seems that when disabling two sanity checks, one again gets head to compile 
also with dwarf2 support. The following patch might be a workaround until the 
problem is solved by addressing it's roots. 
 
Yours, 
 
Björn 
 
Index: simplify-rtx.c 
=== 
RCS file: /cvsroot/gcc/gcc/gcc/simplify-rtx.c,v 
retrieving revision 1.237 
diff -u -r1.237 simplify-rtx.c 
--- simplify-rtx.c  13 Apr 2005 19:47:28 -  1.237 
+++ simplify-rtx.c  6 May 2005 07:41:08 - 
@@ -3737,8 +3737,8 @@ 
   gcc_assert (innermode != BLKmode); 
   gcc_assert (outermode != BLKmode); 
  
-  gcc_assert (GET_MODE (op) == innermode 
- || GET_MODE (op) == VOIDmode); 
+//  gcc_assert (GET_MODE (op) == innermode 
+//   || GET_MODE (op) == VOIDmode); 
  
   gcc_assert ((byte % GET_MODE_SIZE (outermode)) == 0); 
   gcc_assert (byte < GET_MODE_SIZE (innermode)); 
Index: varasm.c 
=== 
RCS file: /cvsroot/gcc/gcc/gcc/varasm.c,v 
retrieving revision 1.498 
diff -u -r1.498 varasm.c 
--- varasm.c13 Apr 2005 14:34:13 -  1.498 
+++ varasm.c6 May 2005 07:41:17 - 
@@ -2212,7 +2212,7 @@ 
   gcc_assert (!i); 
 } 
  
-  gcc_assert (!force); 
+  //gcc_assert (!force); 

   return false; 
 } 
 

-- 


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

[Bug target/21412] New: [PowerPC] ICE loading TLS address

[rth at gcc dot gnu dot org]

struct S { int x[10]; };
extern __thread struct S s;
int *foo() { return &s.x[2]; }

$ ./cc1 -quiet -O2 -fPIC zz.c
zz.c: In function ‘foo’:
zz.c:3: internal compiler error: Segmentation fault

It looks like rs6000_emit_move is only prepared for a tls symbol_ref,
and not a (const (plus (symbol_ref) (const_int))).

-- 
   Summary: [PowerPC] ICE loading TLS address
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rth at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: powerpc*-linux


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

[Bug target/21412] [PowerPC] ICE loading TLS address

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2005-05-06 08:04 
---
ia64.c has a similar bug in ia64_expand_load_address.

-- 


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

[Bug tree-optimization/19791] [tcb] A constant not fully propagated

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-05-06 
08:39 ---
Looks fixed to me. 
 
The only problem now is that there is an extra load of 128 as an immediate, 
I haven't looked at why uncprop doesn't fix this. 
 
--- 
extern void abort (void) __attribute__ ((__noreturn__)); 
 
extern int bar (int, int); 
 
int 
PR19791_test (int mode, int size, unsigned int align) 
{ 
  int align0; 
  int iftmp1; 
 
  if (mode == 0) 
{ 
  if (align != 128) 
abort (); 
} 
 
  align0 = (int) align; 
  if (mode == 0) 
{ 
  int D1131 = align0 / 8; 
  int D1132 = D1131 + size; 
  int D1133 = D1132 - 1; 
  int D1134 = D1131 - 1; 
  int D1135 = ~D1134; 
 
  iftmp1 = D1133 & D1135; 
} 
  else 
{ 
  iftmp1 = size; 
} 
 
  return bar (iftmp1, align0); 
} 
 
 
int 
PR19791_result (int mode, int size, unsigned int align) 
{ 
  int align0; 
  int iftmp1; 
 
  if (mode == 0) 
{ 
  if (align != 128) 
abort (); 
} 
 
  align0 = (int) align; 
  if (mode == 0) 
{ 
  int D1131 = ((int) 128) / 8; 
  int D1132 = D1131 + size; 
  int D1133 = D1132 - 1; 
  int D1134 = D1131 - 1; 
  int D1135 = ~D1134; 
 
  iftmp1 = D1133 & D1135; 
} 
  else 
{ 
  iftmp1 = size; 
} 
 
  return bar (iftmp1, align0); 
} 
--- 
 
--- 
PR19791_test (mode, size, align) 
{ 
  int D1135; 
  int D1134; 
  int D1133; 
  int D1132; 
  int D1131; 
  int iftmp1; 
  int align0; 
  int D.1579; 
  int D.1578; 
 
: 
  if (mode == 0) goto ; else goto ; 
 
:; 
  if (align != 128) goto ; else goto ; 
 
:; 
  abort (); 
 
:; 
  align0 = (int) align; 
  iftmp1 = size; 
  goto  (); 
 
:; 
  iftmp1 = size + 15 & -16; 
  align0 = 128; 
 
:; 
  D.1578 = bar (iftmp1, align0) [tail call]; 
  return D.1578; 
 
} 
 
PR19791_result (mode, size, align) 
{ 
  int D1135; 
  int D1134; 
  int D1133; 
  int D1132; 
  int D1131; 
  int iftmp1; 
  int align0; 
  int D.1593; 
  int D.1592; 
 
: 
  if (mode == 0) goto ; else goto ; 
 
:; 
  if (align != 128) goto ; else goto ; 
 
:; 
  abort (); 
 
:; 
  align0 = (int) align; 
  iftmp1 = size; 
  goto  (); 
 
:; 
  iftmp1 = size + 15 & -16; 
  align0 = 128; 
 
:; 
  D.1592 = bar (iftmp1, align0) [tail call]; 
  return D.1592; 
 
} 
--- 
 

-- 


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

[Bug tree-optimization/20514] hoisting of label out of jumptable would take place at cse, should happen at trees

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2005-05-06 
08:50 ---
Can someone explain what is expected here?  I get the following .optimized 
dump: 
 
main () 
{ 
  int lsm_tmp.1; 
  int D.1572; 
  int D.1571; 
  int i.0; 
 
:; 
  lsm_tmp.1 = i; 
  goto  (); 
 
:; 
 
:; 
  switch (lsm_tmp.1) 
{ 
  case 0 ... 1: goto ; 
  case 2 ... 3: goto ; 
  case 5: goto ; 
  default : goto ; 
} 
 
:; 
  i = lsm_tmp.1; 
  D.1571 = 1; 
  goto  (); 
 
:; 
  lsm_tmp.1 = 4; 
  goto  (); 
 
:; 
  i = lsm_tmp.1; 
  D.1571 = 0; 
 
:; 
  return D.1571; 
 
} 
 

-- 


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

[Bug c++/20961] [4.0/4.1 Regression] ICE on pragma weak/__attribute__((weak))

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-06 
09:16 ---
Subject: Bug 20961

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-05-06 09:16:24

Modified files:
gcc: ChangeLog varasm.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/g++.dg/ext: weak3.C 

Log message:
PR c++/20961
* varasm.c (merge_weak): Remove NEWDECL from WEAK_DECLS chain
if both NEWDECL and OLDDECL are already weak.

* g++.dg/ext/weak3.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8620&r2=2.8621
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/varasm.c.diff?cvsroot=gcc&r1=1.507&r2=1.508
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5442&r2=1.5443
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/weak3.C.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug preprocessor/21410] Infinite memory usage in preprocessor

[lucier at math dot purdue dot edu]

--- Additional Comments From lucier at math dot purdue dot edu  2005-05-06 
09:25 ---
Subject: Re:  Infinite memory usage in preprocessor

Ah, after I reported it I was afraid it might be something like this. 
Thank you for explaining this.

Brad



-- 


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

[Bug c++/20961] [4.0/4.1 Regression] ICE on pragma weak/__attribute__((weak))

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-06 
09:27 ---
Subject: Bug 20961

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-05-06 09:27:33

Modified files:
gcc: ChangeLog varasm.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/g++.dg/ext: weak3.C 

Log message:
PR c++/20961
* varasm.c (merge_weak): Remove NEWDECL from WEAK_DECLS chain
if both NEWDECL and OLDDECL are already weak.

* g++.dg/ext/weak3.C: New test.

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.222&r2=2.7592.2.223
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/varasm.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.477.6.9&r2=1.477.6.10
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.162&r2=1.5084.2.163
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/weak3.C.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=20961

[Bug java/21070] [4.1 Regression]: java compiler generates wrong code on ia64

[schwab at suse dot de]

--- Additional Comments From schwab at suse dot de  2005-05-06 09:33 ---
I'm using binutils 2.16.90.0.2. 

-- 


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

[Bug c++/21413] New: bogus diagnostic from unidentified template

[igodard at pacbell dot net]

In:

#include 
template void foo(int);
template typename std::iterator_traits::value_type foo(const C&);
int main() {
int s;
foo(s);
}


you get:

~/ootbc/members/src$ g++ foo.cc
/mnt/export/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.0/../../../../include/c++/3.4.0/bits/stl_iterator_base_types.h:
In instantiation of `std::iterator_traits':
foo.cc:6:   instantiated from here
/mnt/export/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.0/../../../../include/c++/3.4.0/bits/stl_iterator_base_types.h:129:
error: `float' is not a class, struct, or union type
/mnt/export/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.0/../../../../include/c++/3.4.0/bits/stl_iterator_base_types.h:130:
error: `float' is not a class, struct, or union type
/mnt/export/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.0/../../../../include/c++/3.4.0/bits/stl_iterator_base_types.h:131:
error: `float' is not a class, struct, or union type
/mnt/export/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.0/../../../../include/c++/3.4.0/bits/stl_iterator_base_types.h:132:
error: `float' is not a class, struct, or union type
/mnt/export/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.0/../../../../include/c++/3.4.0/bits/stl_iterator_base_types.h:133:
error: `float' is not a class, struct, or union type


The call identifies the first overload, but you get a diagnostic from the 
second 
overload which is not identified. If you remove the iterator_traits reference
from the return type (just 'void' or some other innocuous type) then the first
overload identifies successfully without diagnostic.

Ivan

-- 
   Summary: bogus diagnostic from unidentified 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=21413

[Bug bootstrap/21414] New: thread lib posix => runtime & gij segfaults on Debian G/L Woody

[vaclav dot ovsik at i dot cz]

Thread lib posix fails on Debian GNU/Linux Woody (current
stable and yes a bit older distro :-)
Thread lib posix95 seems to be working.

I did:
../gcc-4.0.0/configure \
--program-suffix=-4.0 \
--disable-nls \
--enable-languges=c,c++,java

Built gone ok, but installed gij-4.0 segfaults and executable
compiled from .java too (and may be other thing based on threads).

I added option --enable-threads=posix95 to above configure command
and gij works now (I tested only short & simple progs.)

gcc 3.4.3 - dtto

I don't know if problem is in gcc/configure or in the Debian libc6.
My libc6/glibc is deb version 2.2.5-11.8 binutils 2.12.90.0.1-4.

Should I try some gdb session?

-- 
   Summary: thread lib posix => runtime & gij segfaults on Debian
G/L Woody
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P2
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vaclav dot ovsik at i dot cz
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug rtl-optimization/21330] [4.0 Regression] ICE in compare_and_jump_seq, at loop-unswitch.c:120

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-06 
10:53 ---
Subject: Bug 21330

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-05-06 10:52:39

Modified files:
gcc: ChangeLog loop-unswitch.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.c-torture/execute: 20050502-1.c 

Log message:
PR rtl-optimization/21330
* loop-unswitch.c (may_unswitch_on): Set *cinsn only when
returning non-NULL.
(unswitch_single_loop): Clear cinsn when retrying.

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

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.223&r2=2.7592.2.224
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/loop-unswitch.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.25&r2=1.25.12.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.163&r2=1.5084.2.164
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/20050502-1.c.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=21330

[Bug fortran/21415] New: internal compiler error in gfortran -fdefault-integer-8

[jiri dot pittner at jh-inst dot cas dot cz]

The following file.f causes the following error:
gfortran -fdefault-integer-8 -c fi.f
fi.f: In function 'bug':
fi.f:1: internal compiler error: in gfc_conv_string_tmp, at 
fortran/trans-expr.c:736

Without -fdefault-integer-8 works just fine.
fi.f:
  SUBROUTINE bug
  CHARACTER*6 S
  CALL something(S//'X')
  RETURN
  END
The error happens both on an opteron machine with
GNU Fortran 95 (GCC 4.0.0 20050406 (Red Hat 4.0.0-0.41.fc3))
and on a pentium machine where I compiled gcc4 myself
GNU Fortran 95 (GCC 4.0.0)

-- 
   Summary: internal compiler error in gfortran -fdefault-integer-8
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P1
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jiri dot pittner at jh-inst dot cas dot cz
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: 4.0.0
GCC target triplet: 4.0.0


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

[Bug target/21098] .note.GNU-stack emitted

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-06 
12:00 ---
Subject: Bug 21098

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-rhl-branch
Changes by: [EMAIL PROTECTED]   2005-05-06 11:59:51

Modified files:
gcc: ChangeLog 
gcc/config/rs6000: linux64.h rs6000.c 

Log message:
Revert:
2005-04-29  Alan Modra  <[EMAIL PROTECTED]>
PR target/21098
* config/rs6000/rs6000.c (rs6000_elf_end_indicate_exec_stack): New.
* config/rs6000/linux64.h (TARGET_ASM_FILE_END): Use the above.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=2.2326.2.399.2.75&r2=2.2326.2.399.2.76
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/linux64.h.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.53.4.6.2.5&r2=1.53.4.6.2.6
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.576.2.15.2.16&r2=1.576.2.15.2.17



-- 


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

[Bug target/21416] New: wrong code for __builtin_isless, __builtin_islessequal

[niva at niisi dot msk dot ru]

* the options given when GCC was configured/built;

Configured with: /home/niva/src/gcc-3.4-binutils/configure
--with-headers=/home/vxuser/oc2000/mips/src/include
--without-libs --enable-generated-files-in-srcdir
--enable-threads=posix -with-dwarf2 --disable-shared
--target=mips64-none-elf --verbose --enable-checking
--enable-languages=c --srcdir=/home/niva/svnwork/src
--prefix=/home/niva/local --enable-cpp

 * the complete command line that triggers the bug;

 mips64-none-elf-gcc-3.4.3 -mips3 -O3 -S fp-cmp.c -o fp-cmp-mips3.s

 * the compiler output (error messages, warnings, etc.);

No error messages

 * the  preprocessed  file (*.i*) 


void
test_isunordered(double x, double y, int true)
{
  if (__builtin_isunordered(x, y))
{
  if (! true)
abort ();
}
  else
{
  if (true)
abort ();
}
}

void
test_isless(double x, double y, int true)
{
  if (__builtin_isless(x, y))
{
  if (! true)
abort ();
}
  else
{
  if (true)
abort ();
}
}

void
test_islessequal(double x, double y, int true)
{
  if (__builtin_islessequal(x, y))
{
  if (! true)
abort ();
}
  else
{
  if (true)
abort ();
}
}

void
test_isgreater(double x, double y, int true)
{
  if (__builtin_isgreater(x, y))
{
  if (! true)
abort ();
}
  else
{
  if (true)
abort ();
}
}

void
test_isgreaterequal(double x, double y, int true)
{
  if (__builtin_isgreaterequal(x, y))
{
  if (! true)
abort ();
}
  else
{
  if (true)
abort ();
}
}

void
test_islessgreater(double x, double y, int true)
{
  if (__builtin_islessgreater(x, y))
{
  if (! true)
abort ();
}
  else
{
  if (true)
abort ();
}
}


 *  The functions __builtin_isless, __builtin_islessequal 
are implemented via mips instructions c.lt.d, c.le.d that 
raise the 'invalid' floating-point exception when the operands 
 are unordered.
  
This contradicts to ISO/IEC 9899:1999 specification of the
'isless' and 'islessequal' functions:

"The isless macro determines whether its first argument is less than its
second argument. The value of isless(x, y) is always equal to (x) < (y);
however, unlike (x) < (y), isless(x, y) does not raise the 
‘‘invalid’’ 
floating-point exception when x and y are unordered."

Likewise for 'islessequal'. "

Note that __builtin_isgreater,
   __builtin_isgreaterequal are implemented via c.ule.d, c.ult.d
   that do not raise the exception.

-- 
   Summary: wrong code for __builtin_isless, __builtin_islessequal
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: niva at niisi dot msk dot ru
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: mips64-none-elf


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

[Bug fortran/19425] Duplicate SAVE attribute problem

[Konrad dot Bernloehr at mpi-hd dot mpg dot de]

--- Additional Comments From Konrad dot Bernloehr at mpi-hd dot mpg dot de  
2005-05-06 13:08 ---
In the Fortran 77 standard (ANSI X3.9-1978) I could not find any sentence that
indicates that a SAVE statement without a list cannot appear in the same program
unit as a SAVE statement with a list of variables. I would conclude that
gfortran does NOT compile valid F77 code. Code which, by the way, is not only
compiled by
g77 but by commercial compilers as well.

Please be more specific if you think that I am wrong.



-- 


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

[Bug middle-end/21417] New: Missed jump threading opportunity on trees

[steven at gcc dot gnu dot org]

Consider the following test case (t.c): 
 
struct tree_common 
{ 
  int code; 
}; 
union tree_node 
{ 
  struct tree_common common; 
}; 
typedef union tree_node *tree; 
 
extern tree test (tree, int, int); 
extern tree foo (void); 
extern void abort (void) __attribute__ ((__noreturn__)); 
 
tree 
test (tree expr, int t, int D17630) 
{ 
  int __i; 
 
L0: 
  if (expr->common.code != 142) goto L23; else goto L2; 
 
L2: 
  __i = 0; 
  goto L10; 
 
L10: 
  __i = __i + 1; 
  if (D17630 != __i) goto L8; else goto L19; 
 
L8: 
  if (t) goto L15; else goto L10; 
 
L15: 
  expr = foo (); 
  if (expr->common.code != 142) goto L23; else goto L0; 
 
L19: 
  abort (); 
 
L23: 
  return expr; 
} 
 
 
$ ./cc1 -quiet -O3 -dG --param max-cse-path-length=1 -fdump-tree-vars t.c 
$ grep "Bypass edge" t.c.07.bypass 
Bypass edge from 5->1 to 2 
# ./cc1 --version 
GNU C version 4.1.0 20050506 (experimental) (x86_64-unknown-linux-gnu) 
compiled by GNU C version 4.1.0 20050506 (experimental). 
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072

-- 
   Summary: Missed jump threading opportunity on trees
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: missed-optimization, TREE
  Severity: normal
  Priority: P2
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,law at redhat dot com


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

[Bug preprocessor/21410] Infinite memory usage in preprocessor

[belyshev at depni dot sinp dot msu dot ru]

--- Additional Comments From belyshev at depni dot sinp dot msu dot ru  
2005-05-06 13:15 ---
Ok, so closing as invalid.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/19425] Duplicate SAVE attribute problem

[tow21 at cam dot ac dot uk]

--- Additional Comments From tow21 at cam dot ac dot uk  2005-05-06 13:21 
---
(In reply to comment #5) 
> In the Fortran 77 standard (ANSI X3.9-1978) I could not find any sentence 
that 
> indicates that a SAVE statement without a list cannot appear in the same 
program 
> unit as a SAVE statement with a list of variables. 
> [snip] 
> Please be more specific if you think that I am wrong. 
 
Please see the thread on the gfortran mailing list, starting at 
http://gcc.gnu.org/ml/fortran/2005-03/msg00372.html> 
 
The definitive answer is probably Richard Maine's at: 
http://gcc.gnu.org/ml/fortran/2005-03/msg00410.html> 
 
In brief, the code is almost certainly illegal - but since g77 compiles it (as 
do several other compilers), it is a clear regression for gfortran to not 
allow its compilation (albeit not under -std=f95) 
 

-- 


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

[Bug tree-optimization/20514] hoisting of label out of jumptable would take place at cse, should happen at trees

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-06 
13:39 ---
(In reply to comment #3)
> Can someone explain what is expected here?  I get the following .optimized 

This is what it should look like instead:
main () 
{ 
  int lsm_tmp.1; 
  int D.1572; 
  int D.1571; 
  int i.0; 
 
:; 
  lsm_tmp.1 = i; 
  goto  (); 
 
:; 
  goto ;
 
:; 
  switch (lsm_tmp.1) 
{ 
  case 0 ... 1: goto ; 
  case 2 ... 3: goto ; 
  case 5: goto ; 
  default : goto ; 
} 
 
:; 
  i = lsm_tmp.1; 
  D.1571 = 1; 
  goto  (); 
 
:; 
  lsm_tmp.1 = 4; 
  goto  (); 
 
:; 
  i = lsm_tmp.1; 
  D.1571 = 0; 
 
:; 
  return D.1571; 
 
} 

So we should get an infinite loop for L9 because there is no way lsm_tmp.1 can 
change.

-- 


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

[Bug c++/20961] [4.0/4.1 Regression] ICE on pragma weak/__attribute__((weak))

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-06 
13:41 ---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

Re: Double backslashes in fixincl header (__FD_ZERO macro)

[Bruce Korb]

On Thursday 05 May 2005 10:26 pm, Frank Heckenbach wrote:
> > I do not know where you got your code, but what you have is not what
> > was released and not what is under CVS.  Your patch to fixincl.x
> > will correct the deviation from the released source. I just downloaded
> > the distro from ftp.gnu.org:
> > 
> > > $ md5sum *tar.bz2
> > > d2cbfe8fc3205c1d7969b26377405778  gcc-core-3.4.3.tar.bz2
> 
> Script started on Fri May  6 07:14:34 2005
> # md5sum gcc-core-3.4.3.tar.bz2
> d2cbfe8fc3205c1d7969b26377405778  gcc-core-3.4.3.tar.bz2
> # tar xjf gcc-core-3.4.3.tar.bz2 \*.x
> # head -134 gcc-3.4.3/gcc/fixinc/fixincl.x | tail -7
>   do { \n\
> int __d0, __d1; \n\
> __asm__ __volatile__(\"cld ; rep ; stosl\" \n\
> \t: \"=&c\" (__d0), \"=&D\" (__d1) \n\

Hi Frank,

That is, indeed, very bizarre.  I opened that file and the lines that
are supposed to be continued with backslashes ended with:  \\\n\
which is correct.  After you extract it, you have:  \n\
which is not correct.  I am at a loss as to what to suggest.
I cannot apply your patch because "patch" just complains that
the changes have already been applied and would I like to reverse
it.  You would end up with lines ending in \n\  ;).
Sorry.

Regards, Bruce

[Bug libgcj/21414] thread lib posix => runtime & gij segfaults on Debian G/L Woody

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-06 
13:45 ---
This sounds like recursive mutexes are not working on your machine.

Also you need a newer binutils, from :
As of GCC 3.3, binutils 2.13.1 or later is required for this platform. See bug 
10877 for more 
information.


Can you first try with a newer binutils?

-- 
   What|Removed |Added

  Component|bootstrap   |libgcj


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

[Bug rtl-optimization/21330] [4.0 Regression] ICE in compare_and_jump_seq, at loop-unswitch.c:120

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-06 
13:46 ---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/21415] internal compiler error in gfortran -fdefault-integer-8

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-06 
13:52 ---


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

-- 
   What|Removed |Added

   Severity|critical|normal
 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug fortran/20971] gfortran - internal compiler error on bad program -fdefault-integer-8

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-06 
13:52 ---
*** Bug 21415 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||jiri dot pittner at jh-inst
   ||dot cas dot cz


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

[Bug middle-end/21417] Missed jump threading opportunity on trees

[kazu at cs dot umass dot edu]

-- 
   What|Removed |Added

 CC||kazu at cs dot umass dot edu


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

[Bug tree-optimization/21417] Missed jump threading opportunity on trees

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|middle-end  |tree-optimization


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

[Bug target/17994] avr-gcc does not output a dwarf2 .debug_frame section

[bjoern dot m dot haase at web dot de]

--- Additional Comments From bjoern dot m dot haase at web dot de  
2005-05-06 13:59 ---
Hi, 
 
I have been reviewing PR19885 and come to the following conclusions: 
 
1.) As expected, Torleif is right: I can confirm that the problem exists,  
2.) it should, however, probably be called rather a request for enhancement 
than a bug: Beside call stack information the debugging info should be ok in 
principle. 
3.) There seems to be only one little part missing in order to add the call 
stack information as well: The back-end needs to provide the information at 
which memory address the debugger could localize the return address. This would 
require to implement the target hook INCOMING_RETURN_ADDR_RTX and use the 
RTX_FRAME_RELATED_P predicate for all of the prologue/epilogue insn. 
 
I think the best way to address this issue would be to resolve this issue 
simultaneously when switching from asm-prologue/epilogue to 
RTL-prologue/epilogue. Since Andy Hutchinson is just working on this issue, we 
might soon have a solution. Hopefully :-). Would be very helpfull to have call 
stack info in avrstudio. 
 
Yours, 
 
Bjoern 
 
P.S.:  
I hope you will not be flaming me for adding you on the CC list. :-) Just 
thought that you might be interrested since I know you are working on the 
prologue/epilogue issue. 

-- 
   What|Removed |Added

 CC||hutchinsonandy at netscape
   ||dot net


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

[Bug tree-optimization/19791] [tcb] A constant not fully propagated

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-06 
14:02 ---
Fixed by the new jump threader.

-- 
   What|Removed |Added

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


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

[Bug middle-end/19721] [meta-bug] optimizations that CSE still catches

[pinskia at gcc dot gnu dot org]

-- 
Bug 19721 depends on bug 19791, which changed state.

Bug 19791 Summary: [tcb] A constant not fully propagated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19791

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug c++/21413] bogus diagnostic from unidentified template

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-06 
14:07 ---
Here is the reduced testcase:

template  struct a
{
  typedef typename TT::value_type value_type;
};

template void foo(int);
template typename a::value_type foo(const C&);
int main() {
int s;
foo(s);
}


But I cannot remember if the diagnostic is valid or not.

-- 


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

[Bug tree-optimization/21417] Missed jump threading opportunity on trees

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-06 
14:12 ---
Confirmed, there is a load PRE missing also which looks like is causing the 
jump threader not to be able 
to do this jump.



-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-05-06 14:12:07
   date||


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

[Bug target/19087] Overflowed address in dwarf debug line information

[bjoern dot m dot haase at web dot de]

--- Additional Comments From bjoern dot m dot haase at web dot de  
2005-05-06 14:12 ---
Hi Torleif, 
 
I have just had a look at PR19885 and I am having one additional question: 
IIUC, the lable references, that eventually cause the overflow problems refer 
to memory in form of "byte" addresses and not "word" addresses: I.e. the 
offsets and address information you are finding in the elf files all are "byte" 
addresses. Am I right? 
 
In the asm outputs I have investigated so far, I realized that for the lable 
references in the dwarf sections avr-gcc is allocating two bytes only. So in 
case that these two bytes are filled with "byte" addresses instead of "word" 
addresses, it is obvious that an overflow could not be avoided. The cleanest 
solution then would be to redefine the debugging format such that within the 
debugging sections for the dwarf symbols, gcc allocates four bytes for the 
pointers. I fear, however, that this would be a major challenge since one would 
probably need to rewrite a considerable portion of the dwarf-output-genenerator 
in a target-specific fashion. 
If I'm not too wrong, we probably won't have a short term solution for this PR. 
 
Anyway, I think that this bug should be marked as NEW. 
 
Yours, 
 
Björn 

-- 


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

[Bug target/21416] wrong code for __builtin_isless, __builtin_islessequal

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  GCC build triplet|i686-pc-linux-gnu   |
   GCC host triplet|i686-pc-linux-gnu   |


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

[Bug target/21416] wrong code for __builtin_isless, __builtin_islessequal

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-06 
14:21 ---
Confirmed, see also .

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2005-05-06 14:21:22
   date||


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

[Bug java/21418] New: Order of source files matters when compiling

[mark at gcc dot gnu dot org]

We occasionally get bug reports against GNU Classpath about strange compilation
errors. Kalle Olavi Niemitalo finally tracked it down. The order in which gcj -C
is given source files to compile. The smallest example given was:

gcj --bootclasspath '' --classpath .:vm/reference -C -d /tmp/obj
java/io/ObjectInputStream.java gnu/java/io/ClassLoaderObjectInputStream.java
gnu/java/rmi/server/RMIObjectInputStream.java
gnu/java/rmi/RMIMarshalledObjectInputStream.java
org/omg/CORBA/portable/InputStream.java

Which gives lots of errors like:

gnu/java/rmi/RMIMarshalledObjectInputStream.java:52: error: Class
'gnu.java.rmi.RMIMarshalledObjectInputStream' doesn't define the abstract method
'org.omg.CORBA.Object org.omg.CORBA.portable.InputStream.read_Object()' from
class 'org.omg.CORBA.portable.InputStream'. This method must be defined or class
'gnu.java.rmi.RMIMarshalledObjectInputStream' must be declared abstract.
   public class RMIMarshalledObjectInputStream extends RMIObjectInputStream

Obviously gcj somehow picked up the wrong InputStream class from the
org.omg.CORBA.portable package instead of the java.io package.

No compilation errors occur when changing the order of arguments to:

gcj --bootclasspath '' --classpath .:vm/reference -C -d /tmp/obj
org/omg/CORBA/portable/InputStream.java java/io/ObjectInputStream.java
gnu/java/io/ClassLoaderObjectInputStream.java
gnu/java/rmi/server/RMIObjectInputStream.java
gnu/java/rmi/RMIMarshalledObjectInputStream.java

This is with either a GNU Classpath 0.15 release or a CVS checkout done in the
top level directory.

Similar bahavior in 3.3, 3.4, 4.0 and 4.1 branches:
gcj (GCC) 3.3.5 (Debian 1:3.3.5-12) 
gcj-3.4 (GCC) 3.4.4 20050314 (prerelease) (Debian 3.4.3-12)
gcj (GCC) 4.0.1 20050505 (prerelease) 
gcj (GCC) 4.1.0 20050501 (experimental)

For GNU Classpath CVS I will "workaround" this issue by sorting the classes file
list. That way at least we will get uniform bug reports not depending on the
order in which find returns the source files.

-- 
   Summary: Order of source files matters when compiling
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mark at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org,kon at iki dot fi


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

[Bug java/21418] Order of source files matters when compiling

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-06 
14:31 ---
I thought I saw something like this before.

-- 


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

[Bug c/21419] New: [4.0/4.1 Regression] Accepts writting to const via asm

[pinskia at gcc dot gnu dot org]

The following code is accepted now in 4.0.0 and above but should not be:
void sigaddset(const int set)
{
__asm__("" : "=m"(set) );
}

-- 
   Summary: [4.0/4.1 Regression] Accepts writting to const via asm
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c/21420] [3.4/4.0/4.1 Regression] Accepts writting to const via asm

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

Summary|[3.4/4.0/4.1 Regression]|[3.4/4.0/4.1 Regression]
   ||Accepts writting to const
   ||via asm


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

[Bug c/21419] [4.0/4.1 Regression] Accepts writting to const via asm

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.0.1


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

[Bug inline-asm/21396] inline asm doesn't compile with -O2 optimization

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-06 
14:47 ---
Fixed for 4.0.0 and above.

-- 
   What|Removed |Added

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


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

[Bug c/21419] [4.0/4.1 Regression] Accepts writting to const via asm

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-06 
14:48 ---
This also happens with the C++ front-end too.

-- 


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

[Bug c/21420] [3.4/4.0/4.1 Regression] Accepts writting to const via asm

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Known to fail||4.0.0 3.4.0 4.0.0
  Known to work||3.3.3
   Target Milestone|--- |3.4.4


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

[Bug java/21418] Order of source files matters when compiling

[mark at gcc dot gnu dot org]

--- Additional Comments From mark at gcc dot gnu dot org  2005-05-06 14:50 
---
> I thought I saw something like this before.

You are probably refering to bug #17845 which was recently closed since it
couldn't be reproduced (because I added a workaround to GNU Classpath). I cannot
say with certainty that this is the same bug though. The main difference with
that bug is that we have a testcase here (even though there was another
workaround added to GNU Classpath CVS).

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-05-06 14:50:24
   date||


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

[Bug c++/21421] New: [3.4/4.0/4.1 Regression] Accepts writting to const via asm

[pinskia at gcc dot gnu dot org]

Just like PR 21420 but this is for C++ and is a regression from 2.95.3 and not 
from 3.3.3.
static inline void sigaddset(const int set, int i)
{
__asm__("" : "=r"(set) );
}

-- 
   Summary: [3.4/4.0/4.1 Regression] Accepts writting to const via
asm
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: accepts-invalid, diagnostic
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/21421] [3.4/4.0/4.1 Regression] Accepts writting to const via asm

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Known to fail||3.4.0 3.0.4 3.3.3 4.0.0
   ||4.1.0
  Known to work||2.95.3
   Target Milestone|--- |3.4.4


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

[Bug c/21420] New: [3.4/4.0/4.1 Regression]

[pinskia at gcc dot gnu dot org]

The following code in 3.4.0 and above does not warn/error our about assignment 
of read only location:
static inline void sigaddset(const int set, int i)
{
__asm__("" : "=r"(set) );
}

THis is just like 21419 but this time a "static inline" function instead.

-- 
   Summary: [3.4/4.0/4.1 Regression]
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: accepts-invalid, diagnostic
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/21422] New: [4.0/4.1 Regression] Accepts writting to const via asm

[pinskia at gcc dot gnu dot org]

Like PR 21419 but for C++:
void sigaddset(const int set)
{
__asm__("" : "=m"(set) );
}

-- 
   Summary: [4.0/4.1 Regression] Accepts writting to const via asm
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: accepts-invalid, diagnostic
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c/21419] [4.0/4.1 Regression] Accepts writting to const via asm

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Known to fail||4.0.0 4.1.0
  Known to work||3.4.0 3.3.3


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

[Bug c++/21422] [4.0/4.1 Regression] Accepts writting to const via asm

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Known to fail||4.0.0 4.1.0
  Known to work||3.4.0 3.3.3
   Target Milestone|--- |4.0.1


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

[Bug c/21419] [4.0/4.1 Regression] Accepts writting to const via asm

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-06 
14:57 ---
(In reply to comment #1)
> This also happens with the C++ front-end too.
Which I filed as PR 21422 as I think it is a related issue but not fully the 
same bug.

-- 


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

[Bug web/21423] New: http://gcc.gnu.org/java/status.html needs updating

[greenrd at greenrd dot org]

http://gcc.gnu.org/java/status.html needs updating. It refers to gcj 3.2, which
is a bit stale.

-- 
   Summary: http://gcc.gnu.org/java/status.html needs updating
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P2
 Component: web
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: greenrd at greenrd dot org
CC: gcc-bugs at gcc dot gnu dot org


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

Re: Double backslashes in fixincl header (__FD_ZERO macro)

[Joseph S. Myers]

On Fri, 6 May 2005, Bruce Korb wrote:

> That is, indeed, very bizarre.  I opened that file and the lines that
> are supposed to be continued with backslashes ended with:  \\\n\
> which is correct.  After you extract it, you have:  \n\
> which is not correct.  I am at a loss as to what to suggest.

Are you sure you aren't confusing the lines in 
apzAab_Fd_Zero_Asm_Posix_Types_HPatch (with \\\n\) with those in 
apzAab_Fd_Zero_Gnu_Types_HPatch (with \n\)?

-- 
Joseph S. Myers   http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)

[Bug c++/21386] Inconsistent diagnostics for taking address of rvalue

[benh at bwsint dot com]

--- Additional Comments From benh at bwsint dot com  2005-05-06 16:04 
---
(In reply to comment #1)
> (In reply to comment #0)
> > The first error message is also odd; "non-lvalue" is C terminology that is
> > rarely used in relation to C++.
> 
> That is wrong because the standard actually uses lvalue and rvalue all the 
> time.

Right, and it uses "rvalue" rather than "non-lvalue". So far as I can see, all
rvalues of user-defined type are temporaries, so there would be no loss of
precision in changing "temporary" to "rvalue" as well.


-- 


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

[Bug c++/21386] Inconsistent diagnostics for taking address of rvalue

[benh at bwsint dot com]

--- Additional Comments From benh at bwsint dot com  2005-05-06 16:10 
---
(In reply to comment #2)
> Note ICC causes the same thing in terms of error vs warning.

That'll be because ICC emulates gcc behaviour...


-- 


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

Fixed: Double backslashes in fixincl header (__FD_ZERO macro)

[Bruce Korb]

On Friday 06 May 2005 09:01 am, Joseph S. Myers wrote:
> On Fri, 6 May 2005, Bruce Korb wrote:
> 
> > That is, indeed, very bizarre.  I opened that file and the lines that
> > are supposed to be continued with backslashes ended with:  \\\n\
> > which is correct.  After you extract it, you have:  \n\
> > which is not correct.  I am at a loss as to what to suggest.
> 
> Are you sure you aren't confusing the lines in 
> apzAab_Fd_Zero_Asm_Posix_Types_HPatch (with \\\n\) with those in 
> apzAab_Fd_Zero_Gnu_Types_HPatch (with \n\)?

Oops.  Yes.  That is exactly what I was doing.  Sorry.  Those are
remarkably similar patches.  Fixed.  Thank you - Bruce

[Bug tree-optimization/21380] [4.0 Regression] ICE compiling with -O

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-06 
16:44 ---
Subject: Bug 21380

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-05-06 16:43:58

Modified files:
gcc: ChangeLog tree-ssa-threadupdate.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.c-torture/compile: pr21380.c 

Log message:
PR tree-optimization/21380
* tree-ssa-threadupdate.c (thread_through_all_blocks): Do not
thread through a block with no preds.

* gcc.c-torture/compile/pr21380.c: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8625&r2=2.8626
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-threadupdate.c.diff?cvsroot=gcc&r1=2.24&r2=2.25
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5443&r2=1.5444
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/pr21380.c.diff?cvsroot=gcc&r1=1.1&r2=1.2



-- 


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

[Bug tree-optimization/21380] [4.0 Regression] ICE compiling with -O

[law at redhat dot com]

--- Additional Comments From law at redhat dot com  2005-05-06 16:44 ---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/21409] Attached fortran 95 code generates error

[eedelman at acclab dot helsinki dot fi]

--- Additional Comments From eedelman at acclab dot helsinki dot fi  
2005-05-06 16:59 ---
(In reply to comment #2)
> Reduced testcase (I tried not to reduce it too much):
>   subroutine  difq3 (jmax, ngmax, ams)
>   implicit none
>   integer*4 :: jmax, ngmax
>   real*8, dimension(32) ::  ams
>   real*8, dimension(32) ::  edd
>   integer*4 :: j
>   forall (j=2:jmax)
>  ams(1:ngmax)= edd(j-1)
>   end forall
>   end
> 
> 
> But note I get a warning with ICC:
> fortcom: Warning: t.f, line 8: All active combinations of index-names are not
used within the variable 
> being defined (i.e., leftside) of this assignment-stmt.   [AMS]
>  ams(1:ngmax)= edd(j-1)
> .^
> 
> So I don't know if this code is valid or not.

I don't think it is valid; from the F2003 (draft) standard, section 7.4.4.4:

"A many-to-one assignment is more than one assignment to the same object, or
association of more than one target with the same pointer, whether the object is
referenced directly or indirectly through a pointer. A many-to-one assignment
shall not occur within a single statement in a FORALL construct or
statement."

In any case, that code does not make much sense to me: different values are
assigned to the same variable in undefined order (or even simultaneously).

-- 


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

[Bug rtl-optimization/21424] New: Infinite memory allocation when -O3 is used

[vvv dot ivanov at gmail dot com]

Compiling the following testcase with -O3 gcc tries to allocate an infinite
memory (and freezes the system for some time).

void f(int type){
int tmp;

for(tmp = 0; tmp < 2; tmp++){
switch(type) {
case 0:
s1(); break;
case 1:
s2(); break;
case 2:
s3(); break;
}
}
}

how to reproduce:
[EMAIL PROTECTED] tmp]$ arm-unknown-linux-gnu-gcc -c -O3 test.c

The bug was reproduced in gcc-2005-04-29 build for arm-unknown-linux-gnu
gcc -v:
[EMAIL PROTECTED] tmp]$
/fsf/inst/arm-3.4-20050429-2.3.2/arm-unknown-linux-gnu/gcc-3.4-20050429-glibc-2.3.2/bin/arm-unknown-linux-gnu-gcc
-v
Reading specs from
/fsf/inst/arm-3.4-20050429-2.3.2/arm-unknown-linux-gnu/gcc-3.4-20050429-glibc-2.3.2/lib/gcc/arm-unknown-linux-gnu/3.4.4/specs
Configured with:
/work/distr/fsf/crosstool-0.31/build/arm-unknown-linux-gnu/gcc-3.4-20050429-glibc-2.3.2/gcc-3.4-20050429/configure
--target=arm-unknown-linux-gnu --host=i686-host_pc-linux-gnu
--prefix=/fsf/inst/arm-3.4-20050429-2.3.2/arm-unknown-linux-gnu/gcc-3.4-20050429-glibc-2.3.2
--with-local-prefix=/fsf/inst/arm-3.4-20050429-2.3.2/arm-unknown-linux-gnu/gcc-3.4-20050429-glibc-2.3.2/arm-unknown-linux-gnu
--disable-multilib --with-newlib --without-headers --disable-nls
--enable-threads=no --enable-symvers=gnu --enable-__cxa_atexit
--enable-languages=c --disable-shared
Thread model: single
gcc version 3.4.4 20050429 (prerelease)

-- 
   Summary: Infinite memory allocation when -O3 is used
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vvv dot ivanov at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug rtl-optimization/21424] Infinite memory allocation when -O3 is used

[vvv dot ivanov at gmail dot com]

--- Additional Comments From vvv dot ivanov at gmail dot com  2005-05-06 
18:15 ---
The bug is reproduced with the latest csl-arm-branch too (2005-05-06). But
instead of infinite memory allocations, it crashes with segmentation fault:

[EMAIL PROTECTED] tmp]$
/fsf/inst/arm-csl-arm-20050506-2.3.2/arm-unknown-linux-gnu/gcc-csl-arm-20050506-glibc-2.3.2/bin/arm-unknown-linux-gnu-gcc
-c -O3 test.c
test.c: In function `f':
test.c:14: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
Send email to [EMAIL PROTECTED] for instructions.


gcc info:Reading specs from
/fsf/inst/arm-csl-arm-20050506-2.3.2/arm-unknown-linux-gnu/gcc-csl-arm-20050506-glibc-2.3.2/lib/gcc/arm-unknown-linux-gnu/3.4.3/specs
Configured with:
/work/distr/fsf/crosstool-0.31/build/arm-unknown-linux-gnu/gcc-csl-arm-20050506-glibc-2.3.2/gcc-csl-arm-20050506/configure
--target=arm-unknown-linux-gnu --host=i686-host_pc-linux-gnu
--prefix=/fsf/inst/arm-csl-arm-20050506-2.3.2/arm-unknown-linux-gnu/gcc-csl-arm-20050506-glibc-2.3.2
--with-local-prefix=/fsf/inst/arm-csl-arm-20050506-2.3.2/arm-unknown-linux-gnu/gcc-csl-arm-20050506-glibc-2.3.2/arm-unknown-linux-gnu
--disable-multilib --with-newlib --without-headers --disable-nls
--enable-threads=no --enable-symvers=gnu --enable-__cxa_atexit
--enable-languages=c --disable-shared
Thread model: single
gcc version 3.4.3 (release) (CodeSourcery ARM Q3cvs 2004)



-- 
   What|Removed |Added

 CC||mmitchel at gcc dot gnu dot
   ||org
Summary|Infinite memory allocation  |Infinite memory allocation
   |when -O3 is used|when -O3 is used


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

[Bug target/21325] [4.0 Regression] libjava should be re-enabled for ppc-darwin

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-06 
18:27 ---
Subject: Bug 21325

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-05-06 18:27:45

Modified files:
.  : ChangeLog configure configure.in 

Log message:
2005-05-06  Andreas Tobler  <[EMAIL PROTECTED]>

PR target/21325
* configure.in (powerpc-*-darwin*): Remove ${libgcj} from noconfigdirs.
* configure: Regenerated.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.1057.2.11&r2=1.1057.2.12
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/configure.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.204.2.3&r2=1.204.2.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/configure.in.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.341.2.2&r2=1.341.2.3



-- 


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

[Bug target/21325] [4.0 Regression] libjava should be re-enabled for ppc-darwin

[andreast at gcc dot gnu dot org]

--- Additional Comments From andreast at gcc dot gnu dot org  2005-05-06 
18:33 ---
Fixed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug target/21389] optimized code seg faults due to double load on sparcV9

[drew dot johnson at andrew dot com]

-- 
   What|Removed |Added

   Attachment #8820|compile with -O3 or higher, |compile with -O1 or higher,
description|and execution generates seg-|and execution generates seg-
   |fault   |fault


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

[Bug c++/21425] New: typeof with parens rejected

[sstrasser at systemhaus-gruppe dot de]

one might argue that this isn't a bug because it isn't in std but it looks
inconsistent, so I let you decide:

int a;   // ok
int (b); // ok

typeof(a) c; // ok
typeof(a) (d) // error

-- 
   Summary: typeof with parens rejected
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sstrasser at systemhaus-gruppe dot de
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug target/21389] optimized code seg faults due to double load on sparcV9

[drew dot johnson at andrew dot com]

--- Additional Comments From drew dot johnson at andrew dot com  2005-05-06 
18:53 ---
(In reply to comment #0)
> When -O3 or higher is used, the optimizer utilizes the lddf sparc 
instruction 
> to load doubles into registers.  This can generate a bus-error/seg-fault at 
> runtime if the source address of the load is not mod8.  The optimizer does 
not 
> check this, even with -munaligned-doubles set.

This actually fails when -O1 or higher is used.  For some reason, I thought 
that -O2 was the default.


-- 


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

[Bug target/21389] optimized code seg faults due to double load on sparcV9

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-06 
18:54 ---
I think you violating alignment rules in C:

x = tptr[1].f3;
p = (char *)tptr;
p += 4;
tptr = (test1 *)p;

-- 


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

[Bug target/21389] optimized code seg faults due to double load on sparcV9

[drew dot johnson at andrew dot com]

--- Additional Comments From drew dot johnson at andrew dot com  2005-05-06 
19:04 ---
Subject: RE:  optimized code seg faults due to double load on sparcV9

I don't think so.  Malloc does not guarantee anything but mod-4
alignment.  You have to use memalign to get something better (at least
on a Sun).  I only did the +4 pointer stuff to ensure that the double
would be misaligned mod8, as this is what was happening in my code.  As
long as I am on a mod4 boundary for my struct, the -munaligned-doubles
flag should force the handling of doubles as though they are unaligned.
The compiler with no optimization does this.  But as soon as you turn on
-O1, it ignores the unaligned-doubles directive.

Drew

-Original Message-
From: pinskia at gcc dot gnu dot org [mailto:[EMAIL PROTECTED] 
Sent: Friday, May 06, 2005 2:55 PM
To: Johnson, Drew
Subject: [Bug target/21389] optimized code seg faults due to double load
on sparcV9


--- Additional Comments From pinskia at gcc dot gnu dot org
2005-05-06 18:54 ---
I think you violating alignment rules in C:

x = tptr[1].f3;
p = (char *)tptr;
p += 4;
tptr = (test1 *)p;

-- 


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

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




This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.

[mf2]


-- 


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

[Bug target/21389] optimized code seg faults due to double load on sparcV9

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-06 
19:07 ---
(In reply to comment #4)
> Subject: RE:  optimized code seg faults due to double load on sparcV9
> 
> I don't think so.  Malloc does not guarantee anything but mod-4
> alignment.  You have to use memalign to get something better (at least
> on a Sun).  I only did the +4 pointer stuff to ensure that the double
> would be misaligned mod8, as this is what was happening in my code.  As
> long as I am on a mod4 boundary for my struct, the -munaligned-doubles
> flag should force the handling of doubles as though they are unaligned.
> The compiler with no optimization does this.  But as soon as you turn on
> -O1, it ignores the unaligned-doubles directive.

Again what you said about malloc is not true and has not been true since 1989.
The C standard says malloc aligns things the largest alignment required for 
that machine.  In this case 
doubles are aligned by 8.  So your code is invalid.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

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

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-06 
19:31 ---
Subject: Bug 21329

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-05-06 19:31:17

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

Log message:
2005-05-06  Denis Vlasenko  <[EMAIL PROTECTED]>
Jakub Jelinek  <[EMAIL PROTECTED]>

PR target/21329
* config/i386/i386.c (ix86_expand_movmem): Don't use rep; movsb
for -Os if (movsl;)*(movsw;)?(movsb;)? sequence is shorter.
Don't use rep; movs{l,q} if the repetition count is really small,
instead use a sequence of movs{l,q} instructions.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8626&r2=2.8627
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.c.diff?cvsroot=gcc&r1=1.818&r2=1.819



-- 


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

[Bug target/21389] optimized code seg faults due to double load on sparcV9

[drew dot johnson at andrew dot com]

--- Additional Comments From drew dot johnson at andrew dot com  2005-05-06 
19:47 ---
Subject: RE:  optimized code seg faults due to double load on sparcV9

Then what is the point of the -munaligned-doubles flag?  Is this simply
ignored?  I understand your point about malloc, but what if we have
casts to buffers that are not mod8-aligned?  Isn't that what
-munaligned-doubles is for? 

I am going back over the original code to find out how we are allocating
the data struct that is causing my program to fail.  I will let you know
when I find something more.

Drew

-Original Message-
From: pinskia at gcc dot gnu dot org [mailto:[EMAIL PROTECTED] 
Sent: Friday, May 06, 2005 3:08 PM
To: Johnson, Drew
Subject: [Bug target/21389] optimized code seg faults due to double load
on sparcV9


--- Additional Comments From pinskia at gcc dot gnu dot org
2005-05-06 19:07 ---
(In reply to comment #4)
> Subject: RE:  optimized code seg faults due to double load on sparcV9
> 
> I don't think so.  Malloc does not guarantee anything but mod-4
> alignment.  You have to use memalign to get something better (at least
> on a Sun).  I only did the +4 pointer stuff to ensure that the double
> would be misaligned mod8, as this is what was happening in my code.
As
> long as I am on a mod4 boundary for my struct, the -munaligned-doubles
> flag should force the handling of doubles as though they are
unaligned.
> The compiler with no optimization does this.  But as soon as you turn
on
> -O1, it ignores the unaligned-doubles directive.

Again what you said about malloc is not true and has not been true since
1989.
The C standard says malloc aligns things the largest alignment required
for that machine.  In this case 
doubles are aligned by 8.  So your code is invalid.

-- 
   What|Removed |Added


 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

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




This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.

[mf2]


-- 


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

[Bug c++/21426] New: anonymous enums vs. templates

[amu at alum dot mit dot edu]

If one instance of an overloaded function or operator is generic, I cannot
supply a member of an anonymous enum to that function or operator, even if I
wouldn't be calling the generic instance anyway.  As an example of the problem,
attempting to compile the simplified code

  class S;
  template  S& operator<< (S&, const T&);

  enum { x };
  static const int xx = 1 << x;

with G++ 4.0.0 fails with the error

anonenum.cc:5: error: '' is/uses anonymous type
anonenum.cc:5: error:   trying to instantiate 'template S&
operator<<(S&, const T&)'

This is a regression over previous versions, which have no problem with such
code.  (Neither do other vendors' compilers.)

It is obviously trivial to work around the bug by naming the enum, but I believe
I shouldn't need to.

-- 
   Summary: anonymous enums vs. templates
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amu at alum dot mit dot edu
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux-gnu


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

[Bug c++/19404] [4.0 Regression] anonymous types and templates and rejecting valid code

[pinskia at gcc dot gnu dot org]

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

-- 
   What|Removed |Added

 CC||amu at alum dot mit dot edu


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

[Bug c++/21426] anonymous enums vs. templates

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-06 
20:16 ---
The code is invalid, see PR 19404 and PR 20589

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug rtl-optimization/21254] [4.0/4.1 regression] Incorrect code with -funroll-loops for multiple targets with same code

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-06 
20:24 ---
Subject: Bug 21254

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-05-06 20:24:01

Modified files:
gcc: ChangeLog loop-iv.c loop-unroll.c 

Log message:
PR rtl-optimization/21254
* loop-iv.c (iv_number_of_iterations): Simplify infiniteness
assumptions for loops that otherwise do not roll.
(find_simple_exit): Prefer # of iterations that is guaranteed
not to be infinite.
* loop-unroll.c (decide_peel_once_rolling,
decide_peel_completely): Check whether the loop is infinite.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8628&r2=2.8629
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/loop-iv.c.diff?cvsroot=gcc&r1=2.31&r2=2.32
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/loop-unroll.c.diff?cvsroot=gcc&r1=1.32&r2=1.33



-- 


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

[Bug c++/21427] New: Failure in make_thunk, cp/method.c:145 when compiling with multiply-inherited members

[lord dot dimwit at gmail dot com]

Complete command line:
g++ -fPIC -c -o objs/MallocIO.o -pedantic -ansi -g -DDEBUG -Wall -Wno-multichar
-Iheaders -Iheaders/support -Iheaders/kernel libbe/MallocIO.cpp

Error:
In file included from libbe/MallocIO.cpp:15:
headers/support/MallocIO.h:24: internal compiler error: in make_thunk, at
cp/method.c:145

Preproccessed source is attached.

-- 
   Summary: Failure in make_thunk, cp/method.c:145 when compiling
with multiply-inherited members
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lord dot dimwit at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: x86_64-redhat-linux
  GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux


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

[Bug c++/21427] Failure in make_thunk, cp/method.c:145 when compiling with multiply-inherited members

[lord dot dimwit at gmail dot com]

--- Additional Comments From lord dot dimwit at gmail dot com  2005-05-06 
20:58 ---
Created an attachment (id=8831)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8831&action=view)
Complete preprocessed source for the bug.


-- 


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

[Bug java/21428] New: bogus warning: unused parameter 'this'

[kon at iki dot fi]

[EMAIL PROTECTED]:~/pikkuohjelmat/java/TESTIT$ echo 'class foo {}' > foo.java
[EMAIL PROTECTED]:~/pikkuohjelmat/java/TESTIT$ gcj -v -O2 -Wall -W -c foo.java
Using built-in specs.
Reading specs from
/home/kalle/stow/gcc/i686-pc-linux-gnu/bin/../lib/gcc/i686-pc-linux-gnu/4.1.0/../../../libgcj.spec
rename spec lib to liborig
Target: i686-pc-linux-gnu
Configured with: /home/kalle/src/FOREIGN-CVS/gcc/configure --prefix=/home/kalle
--exec-prefix=/home/kalle/i686-pc-linux-gnu --host=i686-pc-linux-gnu
--build=i686-pc-linux-gnu --with-x-toolkit=gtk --with-gjdoc
--enable-java-awt=gtk,xlib
Thread model: posix
gcc version 4.1.0 20050505 (experimental)

/home/kalle/stow/gcc/i686-pc-linux-gnu/bin/../libexec/gcc/i686-pc-linux-gnu/4.1.0/jc1
 foo.java -fhash-synchronization -fno-use-divide-subroutine -fuse-boehm-gc
-fnon-call-exceptions -fno-omit-frame-pointer -fkeep-inline-functions -quiet
-dumpbase foo.java -mtune=pentiumpro -auxbase foo -O2 -Wall -W -version -o
/tmp/ccProouV.s
GNU Java version 4.1.0 20050505 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.1.0 20050430 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Class path starts here:
/home/kalle/pikkuohjelmat/java/
   
/home/kalle/stow/gcc/i686-pc-linux-gnu/bin/../lib/gcc/../../../share/java/libgcj-4.1.0.jar/
 (system) (zip)
foo.java: In class 'foo':
foo.java: In constructor '()':
foo.java:0: warning: unused parameter â**thisâ**
 as -V -Qy -o foo.o /tmp/ccProouV.s
GNU assembler version 2.15 (i386-linux) using BFD version 2.15
[EMAIL PROTECTED]:~/pikkuohjelmat/java/TESTIT$ 

GCJ should not output that warning.

This causes trouble when building gjdoc with "CFLAGS=-O2 -g -Wall -W"
in the environment.  For some reason, Libtool 1.5.6 passes $CFLAGS to
the Java compiler when checking whether it supports the -c and -o
options together.  Because of the warning, Libtool assumes the
compiler did not support the options.  This breaks the build later
because --resource requires -o.

-- 
   Summary: bogus warning: unused parameter 'this'
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P2
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kon at iki dot fi
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug c++/21427] Failure in make_thunk, cp/method.c:145 when compiling with multiply-inherited members

[lord dot dimwit at gmail dot com]

--- Additional Comments From lord dot dimwit at gmail dot com  2005-05-06 
21:10 ---
Also happens in 4.0.0

-- 


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

[Bug tree-optimization/19401] Trivial loop not unrolled

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-06 
21:11 ---
Subject: Bug 19401

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-05-06 21:11:29

Modified files:
gcc: ChangeLog tree-flow.h tree-ssa-loop-ivcanon.c 
 tree-ssa-loop.c 

Log message:
PR tree-optimization/19401
* tree-flow.h (tree_unroll_loops_completely): Declaration changed.
* tree-ssa-loop-ivcanon.c (enum unroll_level): New.
(estimated_unrolled_size): New function.
(try_unroll_loop_completely, canonicalize_loop_induction_variables,
tree_unroll_loops_completely): Always unroll loops if the code size
does not increase.
* tree-ssa-loop.c (tree_complete_unroll): Indicate whether all
loops should be unrolled completely.
(gate_tree_complete_unroll): Run complete unrolling unconditionally.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8629&r2=2.8630
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-flow.h.diff?cvsroot=gcc&r1=2.101&r2=2.102
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop-ivcanon.c.diff?cvsroot=gcc&r1=2.11&r2=2.12
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop.c.diff?cvsroot=gcc&r1=2.28&r2=2.29



-- 


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

[Bug java/21428] bogus warning: unused parameter 'this'

[mark at gcc dot gnu dot org]

--- Additional Comments From mark at gcc dot gnu dot org  2005-05-06 21:13 
---
This also happens with 4.0 and 3.4, but 3.3 doesn't show any warning.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-05-06 21:13:10
   date||


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

[Bug java/21428] [3.4/4.0/4.1 Regression] bogus warning: unused parameter 'this'

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-06 
21:22 ---
Lets mark this as a regression then.

-- 
   What|Removed |Added

   Keywords||diagnostic
Summary|bogus warning: unused   |[3.4/4.0/4.1 Regression]
   |parameter 'this'|bogus warning: unused
   ||parameter 'this'
   Target Milestone|--- |4.1.0


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

[Bug c++/21413] bogus diagnostic from unidentified template

[bangerth at dealii dot org]

--- Additional Comments From bangerth at dealii dot org  2005-05-06 22:21 
---
I think that's a good question. We've had this before in some other PR. The 
problem is that because the template parameter is explicitly specialized, 
rather than deduced, SFINAE doesn't apply and the compiler can't silently 
remove the second template from the overload list to choose the first. I 
don't remember how this was resolved... 
 
W. 

-- 


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

[Bug fortran/21148] Can't open module file (case not taken into account)

[nicolas dot girard at nerim dot net]

--- Additional Comments From nicolas dot girard at nerim dot net  
2005-05-06 22:29 ---
Please ignore this report. At the time of writing it, I didn't know much 
about .mod and .o files 
Sorry for the trouble. 
 

-- 
   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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

[Bug c++/21427] Failure in make_thunk, cp/method.c:145 when compiling with multiply-inherited members

[bangerth at dealii dot org]

--- Additional Comments From bangerth at dealii dot org  2005-05-06 22:33 
---
That's an interesting case involving covariant return types: 
- 
class B1 { 
  public: 
virtual void foo(); 
}; 
 
class B2 { 
  public: 
virtual B2 & bar() = 0; 
}; 
 
class I : public B1, B2 { 
  public: 
virtual ~I(); 
virtual I & bar(); 
}; 
 
class D : public I { 
virtual ~D(); 
}; 
 
g/x> /home/bangerth/bin/gcc-4.0-pre/bin/c++ -c x.cc 
x.cc:17: internal compiler error: in make_thunk, at cp/method.c:127 
Please submit a full bug report, 
with preprocessed source if appropriate. 
See http://gcc.gnu.org/bugs.html> for instructions. 
 
The interesting part is: if I change the declarations to use "struct" instead 
of "class", then the ICE goes away. I wouldn't know what that would change 
but it happens anyway... 
 
Confirmed.  
  W. 

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-05-06 22:33:07
   date||


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

[Bug middle-end/21285] gij fails to handle NullPointerException exception

[tsv at solvo dot ru]

--- Additional Comments From tsv at solvo dot ru  2005-05-06 22:36 ---
Ok, I think I did find the problem. The unwind logic could not unwind deeper
than "ffi_closure_osf" function defined in libffi/src/alpha/osf.S (gdb showed
call stack like corrupted).
I checked number of bytes reserved from stack in ".frame" directive for the
functions and number of bytes for call stack described in FDEs in ".eh_frame"
section. They are different by 16 bytes for each function. I modified ".frame"
directive to reserve number of bytes as defined by FDEs (although changing of
FDEs would be easier) and my test cases started to work (even "ant" stopped
crashing).

Please, review the attached patch to libffi/src/alpha/osf.S file.

Thank you.

-- 


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

[Bug fortran/21429] New: Internal compiler error when trying to compile the HDF5 libs

[nicolas dot girard at nerim dot net]

Hi,  
I'm using the gfortran version from the 4.0.0-3mdk package ; here are the  
complete instructions I did before compiling the HDF5 libs (I followed the 
advices from [1]): 
 
wget ftp://ftp.ncsa.uiuc.edu/HDF/HDF5/current/src/hdf5-1.6.4.tar.gz 
tar xzf hdf5-1.6.4.tar.gz 
cd hdf5-1.6.4/ 
F9X=gfortran FFLAGS="-fno-second-underscore -O2" ./configure --prefix=/usr 
--enable-fortran=yes --enable-cxx=yes 
 
Here's the error I got: 
 
gfortran -I. -fno-second-underscore -O2 -I. -c H5f90global.f90  -fPIC -DPIC -o 
H5f90global.o 
H5f90global.f90:0: internal compiler error: backend decl for module variable 
h5t_enum_f already exists 
Please submit a full bug report, 
with preprocessed source if appropriate. 
 
How could I do to provide more useful informations ? 
 
Cheers 
 
[1] 
http://groups.google.fr/group/comp.lang.fortran/browse_thread/thread/1dc7c230f30ec667

-- 
   Summary: Internal compiler error when trying to compile the HDF5
libs
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nicolas dot girard at nerim dot net
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug middle-end/21285] gij fails to handle NullPointerException exception

[tsv at solvo dot ru]

--- Additional Comments From tsv at solvo dot ru  2005-05-06 22:39 ---
Created an attachment (id=8832)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8832&action=view)
Fixes call frame size mismatch in ".frame" and ".eh_frame"


-- 


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

[Bug c++/21427] [3.4/4.0 only] Failure in make_thunk, cp/method.c:145 when compiling with multiply-inherited members

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-06 
22:43 ---
Further reduced:
struct B1
{
virtual void f(void);
};
struct B2
{
  virtual B2 &g() = 0;
};
struct I :  B1, private B2
{
  I &g();
};
struct D :  I
{
};


This works on the mainline.

-- 
   What|Removed |Added

   Keywords||ice-on-valid-code
  Known to fail||3.4.0 4.0.0
  Known to work||4.1.0
Summary|Failure in make_thunk,  |[3.4/4.0 only] Failure in
   |cp/method.c:145 when|make_thunk, cp/method.c:145
   |compiling with multiply-|when compiling with
   |inherited members   |multiply-inherited members
   Target Milestone|--- |3.4.4


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

[Bug libffi/21285] gij fails to handle NullPointerException exception

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-06 
22:47 ---
CCing RTH since he is the alpha maintainer.


Confirmed.

-- 
   What|Removed |Added

 CC||rth at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
  Component|middle-end  |libffi
 Ever Confirmed||1
   Keywords|EH, wrong-code  |
   Last reconfirmed|-00-00 00:00:00 |2005-05-06 22:47:26
   date||


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

[Bug fortran/21429] Internal compiler error when trying to compile the HDF5 libs

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-06 
22:49 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug fortran/17917] gfortran ICE on "equivalence"

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-06 
22:49 ---
*** Bug 21429 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||nicolas dot girard at nerim
   ||dot net


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

[Bug java/20309] gcjh needs a -force option

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-06 
22:53 ---
Subject: Bug 20309

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

Modified files:
gcc/java   : ChangeLog Make-lang.in config-lang.in gcj.texi 
 gjavah.c 

Log message:
2005-05-06  Thomas Fitzsimmons  <[EMAIL PROTECTED]>

PR java/20309
* Make-lang.in (java): Add gjnih.
(JAVA_TARGET_INDEPENDENT_BIN_TOOLS): Likewise.
(GJNIH_OBJS): New variable.
(gjnih$(exeext)): New target.
(JAVA_MANFILES): Add gjnih.1.
(java.uninstall): Add gjnih.1.
(java.mostlyclean): Add gjnih.
(java.maintainer-clean): Add gjnih.1.
(java/gjavah-jni.o): New target.
(.INTERMEDIATE): Add gjnih.pod.
(gjnih.pod): New target.
* config-lang.in (stagestuff): Add gjnih.
* gcj.texi (Top): Add gjnih node.
(Invoking gcjh): Add descriptions of -force, -old, -trace, -J and
-bootclasspath options.
(Invoking gjnih): New node.
* gjavah.c Initialize flag_jni to 1 if JNI_DEFAULT is defined.
(TOOLNAME): New macro.
(error): Replace hard-coded gcjh with TOOLNAME.
(process_file): Likewise.
(usage): Likewise.
(version): Likewise.
(help): Likewise.  Add help output for -force, -old, -trace and -J
options.
(OPT_FORCE, OPT_OLD, OPT_TRACE): New macros.
(options): Add force, old, trace and J fields.
(main): Handle -force, -old, -trace and -J options.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.1556.2.17&r2=1.1556.2.18
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/Make-lang.in.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.152.8.2&r2=1.152.8.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/config-lang.in.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.16&r2=1.16.80.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/gcj.texi.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.73.2.6&r2=1.73.2.7
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/gjavah.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.128.6.2&r2=1.128.6.3



-- 


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

[Bug java/20309] gcjh needs a -force option

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|4.1.0   |4.0.1


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

[Bug target/18655] Incorrect data in .debug_frame section for PowerPC

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 GCC target triplet||powerpc-*-*


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

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

[kazu at cs dot umass dot edu]

Consider:

#define B1(C,D) \
  B0(C##0,D##0) B0(C##1,D##0) B0(C##2,D##0) B0(C##3,D##0) B0(C##4,D##0) \
  B0(C##5,D##0) B0(C##6,D##0) B0(C##7,D##0) B0(C##8,D##0) B0(C##9,D##0)

#define B2(C,D) \
  B1(C##0,D##0) B1(C##1,D##0) B1(C##2,D##0) B1(C##3,D##0) B1(C##4,D##0) \
  B1(C##5,D##0) B1(C##6,D##0) B1(C##7,D##0) B1(C##8,D##0) B1(C##9,D##0)

#define B3(C,D) \
  B2(C##0,D##0) B2(C##1,D##0) B2(C##2,D##0) B2(C##3,D##0) B2(C##4,D##0) \
  B2(C##5,D##0) B2(C##6,D##0) B2(C##7,D##0) B2(C##8,D##0) B2(C##9,D##0)

#define B4(C,D) \
  B3(C##0,D##0) B3(C##1,D##0) B3(C##2,D##0) B3(C##3,D##0) B3(C##4,D##0) \
  B3(C##5,D##0) B3(C##6,D##0) B3(C##7,D##0) B3(C##8,D##0) B3(C##9,D##0)

#define B0(C,D) C,
const int a[] = { B4(1,1) 0 };
#undef B0

void bar (int);

void
foo (void)
{
#define B0(C,D) bar(a[C-D]);
  B4(1,1);
#undef B0
}

Change B4(1,1) to B3(1,1), B2(1,1), etc.  You'll get quadratic behavior.

On my machine,

B110 elements  0.097s
B2   100 elements  0.094s
B3  1000 elements  1.373s
B4 1 elements 41.816s

I'm pretty sure the quadratic behavior comes from the ARRAY_REF case of
expand_expr_real_1.

-- 
   Summary: Quadratic behavior with constant initializers
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: compile-time-hog
  Severity: normal
  Priority: P2
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: gcc-bugs at gcc dot gnu dot org


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

Problem with use of anonymous types

[Julian Cummings]

People are reporting trouble compiling blitz with gcc-4.0.0, and the
compiler errors are resulting from the use of unnamed enums.  A simple code
illustrates the problem:

  struct nullType {};
  template  inline T operator+(const T& a, nullType) { return a;
}
  enum named { namedA = 1, namedB = 2 };
  enum { unnamedA = 2, unnamedB = 4 };
  struct bar {
enum { namedC = namedA + namedB,
   unnamedC = unnamedA + unnamedB };
  };
  int main() {
  }

The gcc compiler complains about trying to add unnamedA and unnamedB.
Apparently it gets confused by the presence of the operator+ overload for
the empty struct nullType.  I don't see why the compiler would think that
the anonymous enumerators unnamedA or unnamedB would match with type
nullType.  Enumerators are supposed to default to integers when used in
arithmetic operations such as operator+.  Everything compiles fine when the
operator+ overload is not present.  The code compiles as is under gcc-3.4.
What gives?

Thanks, Julian C.

Dr. Julian C. CummingsOffice: PB-111
Caltech/CACR, MC 158-79   Phone:  626-395-2543
1200 E. California Blvd.  Fax:626-584-5917
Pasadena, CA 91125 

Re: Problem with use of anonymous types

[Andrew Pinski]

On May 6, 2005, at 8:09 PM, Julian Cummings wrote:
People are reporting trouble compiling blitz with gcc-4.0.0, and the
compiler errors are resulting from the use of unnamed enums.  A simple 
code
illustrates the problem:

  struct nullType {};
  template  inline T operator+(const T& a, nullType) { 
return a;
}
  enum named { namedA = 1, namedB = 2 };
  enum { unnamedA = 2, unnamedB = 4 };
  struct bar {
enum { namedC = namedA + namedB,
   unnamedC = unnamedA + unnamedB };
  };
  int main() {
  }

The gcc compiler complains about trying to add unnamedA and unnamedB.
Apparently it gets confused by the presence of the operator+ overload 
for
the empty struct nullType.  I don't see why the compiler would think 
that
the anonymous enumerators unnamedA or unnamedB would match with type
nullType.  Enumerators are supposed to default to integers when used in
arithmetic operations such as operator+.  Everything compiles fine 
when the
operator+ overload is not present.  The code compiles as is under 
gcc-3.4.
What gives?
This is a bug in your code.  See PR 19404 and PR 20589.
-- Pinski