[Bug target/21719] program using "initgroups()" fails with stack corruption

[Ulrich dot Windl at rz dot uni-regensburg dot de]

--- Additional Comments From Ulrich dot Windl at rz dot uni-regensburg dot 
de  2005-06-01 06:14 ---
Just for reference: The machine in question does not have C-library patch
PHCO_31903 installed, but the quoted defect (JAGad41604) doesn't seem to be
relevant (The system isn't a trusted one, and only the "hosts" entry in
/etc/nsswitch.conf uses "dns", while the "group" entry uses "compat").
I'm hoping someone who really understands the PA assembler can compare the
assembly code of both compilers and find out whether there's a significant
difference. Having something like Linux' "ltrace" or "valgrind" for HP-UX would
be great to track down that problem.

-- 


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

[Bug rtl-optimization/21138] wrong code in sixtrack for -fmodulo-sched

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-06-01 
05:26 ---
Subject: Bug 21138

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

Modified files:
gcc: ChangeLog modulo-sched.c 

Log message:
2005-06-01 Mostafa Hagog <[EMAIL PROTECTED]>

* modulo-sched.c (undo_generate_reg_moves ): Fix PR 21138.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8968&r2=2.8969
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/modulo-sched.c.diff?cvsroot=gcc&r1=1.30&r2=1.31



-- 


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

[Bug fortran/20883] unassigned integer used as format

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-06-01 
03:44 ---
Subject: Bug 20883

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-06-01 03:44:43

Modified files:
gcc/fortran: ChangeLog io.c 
gcc/testsuite  : ChangeLog 
gcc/testsuite/gfortran.dg: assign_2.f90 
Added files:
gcc/testsuite/gfortran.dg: assign_4.f90 

Log message:
2005-06-01  Feng Wang  <[EMAIL PROTECTED]>

PR fortran/20883
* fortran/io.c (resolve_tag): Fix error message.

2005-06-01  Feng Wang  <[EMAIL PROTECTED]>

PR fortran/20883
* gfortran/assign_4.f90: New test.
* gfortran/assign_2.f90: Change compile to run.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.446&r2=1.447
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/io.c.diff?cvsroot=gcc&r1=1.24&r2=1.25
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5569&r2=1.5570
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/assign_4.f90.diff?cvsroot=gcc&r1=1.1&r2=1.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/assign_2.f90.diff?cvsroot=gcc&r1=1.1&r2=1.2



-- 


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

[Bug tree-optimization/21858] ICE in compare_values, at tree-vrp.c:301

[john dot carter at tait dot co dot nz]

-- 
   What|Removed |Added

   Keywords||ice-on-valid-code


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

[Bug tree-optimization/21858] ICE in compare_values, at tree-vrp.c:301

[john dot carter at tait dot co dot nz]

--- Additional Comments From john dot carter at tait dot co dot nz  
2005-06-01 03:40 ---
Created an attachment (id=9005)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9005&action=view)
Preprocessed source that triggers ICE

I have tried to trim this down as much as I can, but it is still quite hairy.

-- 


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

[Bug tree-optimization/21858] New: ICE in compare_values, at tree-vrp.c:301

[john dot carter at tait dot co dot nz]

Preprocessed file supplied (bug.i)

This would appear to be related to RESOLVED bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21188 and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21227

As far as I can make out the fixes for those bugs have been checked in, I'm
using gcc tip of CVS mainline as at Wed Jun  1 02:00 UTC 2005 and the bug is
still present. ie. This is either a different bug manifesting in the same place
or the old bug revived. This affects both the arm and the i686 backends, so I
suspect it is before it hits the backend.)

/usr/local/bin/arm-elf-gcc -v
Using built-in specs.
Target: arm-elf
Configured with: ../combined/configure --target=arm-elf --enable-languages=c,c++
--with-gnu-as --with-gnu-ld --with-newlib
Thread model: single
gcc version 4.1.0 20050601 (experimental)

Also...
/opt/gcc4_1/bin/gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c --prefix=/opt/gcc4_1
Thread model: posix
gcc version 4.1.0 20050601 (experimental)

Using gcc -v I can see what gcc is running when it crashes, and hence reproduce
the bug like so...
cd /home/johnc/tmp
/opt/gcc4_1/libexec/gcc/i686-pc-linux-gnu/4.1.0/cc1 -fpreprocessed
/home/johnc/tmp/bug.i  -dumpbase bug.i -auxbase bug -Os -std=c9x -v -o
/home/johnc/tmp/bug.s
ignoring nonexistent directory
"/opt/gcc4_1/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /opt/gcc4_1/include
 /opt/gcc4_1/lib/gcc/i686-pc-linux-gnu/4.1.0/include
 /usr/include
End of search list.
 strcoll
 dsdblm_CreateBlock

/home/johnc/tmp/bug.i: In function 'dsdblm_CreateBlock':
/home/johnc/tmp/bug.i:201: warning: comparison between pointer and integer
 dsdblm_WriteBlock

Analyzing compilation unitPerforming intraprocedural optimizations
Assembling functions:
 dsdblm_CreateBlock

/home/johnc/tmp/bug.i: In function 'dsdblm_CreateBlock':
/home/johnc/tmp/bug.i:196: internal compiler error: in compare_values, at
tree-vrp.c:301


I can then use gdb on cc1 and put a breakpoint on fancy_abort and get a stack
trace...
where
#0  fancy_abort (file=0x12d , line=0,
function=0x12d )
at ../../combined/gcc/diagnostic.c:588
#1  0x08382ab8 in compare_values (val1=0xb7fa8680, val2=0xb7ddfc30) at
../../combined/gcc/tree-vrp.c:410
#2  0x083848bd in compare_range_with_value (comp=LE_EXPR, vr=0xb7dc9840,
val=0xb7ddfc30) at ../../combined/gcc/tree-vrp.c:1234
#3  0x08386e64 in vrp_evaluate_conditional (cond=0xb7d66798) at
../../combined/gcc/tree-vrp.c:1992
#4  0x08387025 in vrp_visit_cond_stmt (stmt=0xb7d6c168, taken_edge_p=0xbf9bec20)
at ../../combined/gcc/tree-vrp.c:2044
#5  0x083874df in vrp_visit_stmt (stmt=0xb7d6c168, taken_edge_p=0x12d,
output_p=0x12d) at ../../combined/gcc/tree-vrp.c:2089
#6  0x08163401 in simulate_stmt (stmt=0xb7d6c168) at
../../combined/gcc/tree-ssa-propagate.c:302
#7  0x08163896 in simulate_block (block=0xb7de2af8) at
../../combined/gcc/tree-ssa-propagate.c:425
#8  0x08164a7d in ssa_propagate (visit_stmt=0x12d, visit_phi=0x12d) at
../../combined/gcc/tree-ssa-propagate.c:667
#9  0x08388526 in execute_vrp () at ../../combined/gcc/tree-vrp.c:2383
#10 0x080d2c02 in execute_one_pass (pass=0x8507600) at
../../combined/gcc/tree-optimize.c:623
#11 0x080d2d28 in execute_pass_list (pass=0x8507600) at
../../combined/gcc/tree-optimize.c:660
#12 0x080d2d48 in execute_pass_list (pass=0x85053c0) at
../../combined/gcc/tree-optimize.c:661
#13 0x080d3008 in tree_rest_of_compilation (fndecl=0xb7de157c) at
../../combined/gcc/tree-optimize.c:793
#14 0x0805d44d in c_expand_body (fndecl=0xb7de157c) at
../../combined/gcc/c-decl.c:6593
#15 0x083adf7a in cgraph_expand_function (node=0xb7de1b64) at
../../combined/gcc/cgraphunit.c:949
#16 0x083ae14b in cgraph_expand_all_functions () at
../../combined/gcc/cgraphunit.c:1013
#17 0x083ae41a in cgraph_optimize () at ../../combined/gcc/cgraphunit.c:1115
#18 0x0834d136 in compile_file () at ../../combined/gcc/toplev.c:1008
#19 0x0834e78b in do_compile () at ../../combined/gcc/toplev.c:2123
#20 0x0834e805 in toplev_main (argc=301, argv=0xbf9bef34) at
../../combined/gcc/toplev.c:2155
#21 0x080b110b in main (argc=301, argv=0x12d) at ../../combined/gcc/main.c:35

-- 
   Summary: ICE in compare_values, at tree-vrp.c:301
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: john dot carter at tait dot co dot nz
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: i486-elf-linux
GCC target triplet: arm-elf && i686-pc-linux-gnu


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

[Bug fortran/20883] unassigned integer used as format

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-06-01 
03:30 ---
Subject: Bug 20883

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-06-01 03:30:25

Modified files:
gcc/fortran: ChangeLog io.c 
gcc/testsuite  : ChangeLog 
gcc/testsuite/gfortran.dg: assign_2.f90 
Added files:
gcc/testsuite/gfortran.dg: assign_4.f90 

Log message:
2005-06-01  Feng Wang  <[EMAIL PROTECTED]>

PR fortran/20883
* fortran/io.c (resolve_tag): Fix error message.

2005-06-01  Feng Wang  <[EMAIL PROTECTED]>

PR fortran/20883
* gfortran/assign_4.f90: New test.
* gfortran/assign_2.f90: Change compile to run.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.335.2.59&r2=1.335.2.60
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/io.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.19.10.4&r2=1.19.10.5
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.213&r2=1.5084.2.214
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/assign_4.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/assign_2.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.1.2.1&r2=1.1.2.2



-- 


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

[Bug libgcj/21753] String.substring sharing heuristic should be improved

[tromey at gcc dot gnu dot org]

--- Additional Comments From tromey at gcc dot gnu dot org  2005-06-01 
03:17 ---
I'm handling this


-- 
   What|Removed |Added

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


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

[Bug target/21854] [4.1 Regression] irix6.5 bootstrap fails due to warning in mips.c

[billingd at gcc dot gnu dot org]

--- Additional Comments From billingd at gcc dot gnu dot org  2005-06-01 
03:08 ---
Fixed by patch to gcc/config/mips/mips-protos.h.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug target/21854] [4.1 Regression] irix6.5 bootstrap fails due to warning in mips.c

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-06-01 
03:05 ---
Subject: Bug 21854

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

Modified files:
gcc/config/mips: mips-protos.h 
gcc: ChangeLog 

Log message:
2005-06-01  David.Billinghurst  <[EMAIL PROTECTED]>

PR target/21854
* config/mips/mips-protos.h: Declare mips_use_ins_ext_p

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/mips/mips-protos.h.diff?cvsroot=gcc&r1=1.85&r2=1.86
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8966&r2=2.8967



-- 


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

[Bug c/21857] New: Command line switches controlling acceptance of main

[neil at gcc dot gnu dot org]

GCC rejects the following with -Wall -pedantic-errors but accepts it with -ansi
-pedantic-errors, which seems odd.

typedef enum { foo } int_t;

int main (int_t argc, char **argv)
{
  return 0;
}

-- 
   Summary: Command line switches controlling acceptance of main
   Product: gcc
   Version: 3.3.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug java/21856] New: null pointer check elimination

[tromey at gcc dot gnu dot org]

Sometimes we emit explicit null pointer checks.  On some platforms we
do this for every member reference; many of these should be trivial to
eliminate.  On x86 Linux, we only do this in one special case, which
is checking the 'this' argument to a final method call with the non-BC
ABI.

Here's a test case:

public class z
{
  public final void m() { System.out.println("m"); }
  public void nothing() { }

  public static void main(String[] args)
  {
z val = new z();
val.nothing();
val.m();
  }
}

When I compile this with -S ("gcj -O0 -S z.java"), I see an explicit
check and conditional call to _Jv_ThrowNullPointerException before the
`val.m()' invocation.  However, we know that this is redundant, as
'val.nothing()' would have thrown if val==null.

The situation here may be complicated by the fact that a java program
can catch NullPointerException.  In this test case, it is invalid to
optimize away the check when val.m() is called:

public abstract class z
{
  public final void m() { System.out.println("m"); }
  public void nothing() { }
  public abstract z get_one();

  public static void main(String[] args)
  {
z val = get_one();
try {
  val.nothing();
} catch (NullPointerException _) {
}
val.m();
  }
}

One more wrinkle in this area is that on some platforms (all the
well-supported ones like x86 Linux), we do not emit explicit null
checks.  Instead we just let them SEGV and at runtime convert this
into an exception.  On these platforms we compile java code with
flag_non_call_exceptions=1.

However, I would expect we could get better optimizations later on if
we could notice that some of these references can never be made via a
null base pointer.  For this to work, I think there would have to be a
way to tell RTL about the difference between a possibly-trapping and a
never-trapping load.  I know basically zero about RTL so I don't know
if this is realistic at this point.

If you compile the two "z.java" test cases for some
less-well-supported target, you will see explicit null pointer checks
at each call site.  I'm not sure if we emit tests for references via
'this' -- I think we have an ad hoc optimization for it.

Another thing we can recognize is that 'new' never returns null.  We
set DECL_IS_MALLOC on the function we use to create objects and
arrays, though I suppose that wouldn't suffice.  These functions are
declared in decl.c, just search for DECL_IS_MALLOC there (there are a
few instances).  I don't know of a way for the front end to inform
later passes about this property of 'new'.

-- 
   Summary: null pointer check elimination
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: java
AssignedTo: dnovillo at redhat dot com
ReportedBy: tromey at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org


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

[Bug java/21855] New: array bounds checking elimination

[tromey at gcc dot gnu dot org]

public class q
{
  public static void main(String[] args)
  {
for (int i = 0; i < args.length; ++i)
  System.out.println(args[i]);
  }
}

Right now you will get an unnecessary array bounds check at 'args[i]'.
BTW we implement this check with an unsigned comparison to also weed
out negative indices.

Also, an array's size is fixed at its creation.  We ought to be
able to constant propagate in code like this:

   int[] array = new int[256];
   for (int i = 0; i < array.length; ++i) { ... }

... but afaik there is no way for the front end of the value of
'array.length'

-- 
   Summary: array bounds checking elimination
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: java
AssignedTo: dnovillo at redhat dot com
ReportedBy: tromey at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org


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

[Bug target/21854] [4.1 Regression] irix6.5 bootstrap fails due to warning in mips.c

[billingd at gcc dot gnu dot org]

--- Additional Comments From billingd at gcc dot gnu dot org  2005-06-01 
01:46 ---
'mips_use_ins_ext_p' is used in mips.md.  Defining it in mips-protos.h seems
to work.  Testing it now.

--- mips-protos.h   27 May 2005 23:08:31 -  1.85
+++ mips-protos.h   1 Jun 2005 01:42:12 -
@@ -222,5 +222,6 @@
 extern void irix_asm_output_align (FILE *, unsigned);
 extern const char *current_section_name (void);
 extern unsigned int current_section_flags (void);
+extern bool mips_use_ins_ext_p (rtx op, rtx size, rtx position);
 
 #endif /* ! GCC_MIPS_PROTOS_H */


-- 


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

[Bug libgcj/21798] Generational garbage collector?

[tromey at gcc dot gnu dot org]

--- Additional Comments From tromey at gcc dot gnu dot org  2005-06-01 
01:45 ---
The Boehm GC has a generational mode, but it would require
some changes to libgcj which nobody has yet attempted.


-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-06-01 01:45:27
   date||


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

[Bug c++/21853] [3.4/4.0/4.1 Regression] constness of pointer to data member ignored

[david dot m dot krauss at intel dot com]

--- Additional Comments From david dot m dot krauss at intel dot com  
2005-06-01 01:44 ---
Subject: RE:  [3.4/4.0/4.1 Regression] constness of pointer to data member 
ignored

Yo Andrew

How's it hangin'?

Sorry to say, my address means what it looks like...

- David


-Original Message-
From: pinskia at gcc dot gnu dot org [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, May 31, 2005 5:12 PM
To: Krauss, David M
Subject: [Bug c++/21853] [3.4/4.0/4.1 Regression] constness of pointer
to data member ignored


--- Additional Comments From pinskia at gcc dot gnu dot org
2005-06-01 00:12 ---
This has been failing since at least 2000-12-31.



-- 


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

[Bug fastjar/21826] fastjar does not look to see if mkdir takes one or two arguments

[tromey at gcc dot gnu dot org]

--- Additional Comments From tromey at gcc dot gnu dot org  2005-06-01 
01:12 ---
Everything in fastjar/ is built for the host, not the target.

-- 


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

[Bug target/21854] [4.1 Regression] irix6.5 bootstrap fails due to warning in mips.c

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|bootstrap   |target
   Keywords||build
Summary|irix6.5 bootstrap fails due |[4.1 Regression] irix6.5
   |to warning in mips.c|bootstrap fails due to
   ||warning in mips.c
   Target Milestone|--- |4.1.0


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

[Bug bootstrap/21854] New: irix6.5 bootstrap fails due to warning in mips.c

[billingd at gcc dot gnu dot org]

mips-sgi-irix6.5 bootstrap of 4.1 fails in stage2 when compiling config/mips.c

cc1: warnings being treated as errors
/disk4/billingd/src/gcc/gcc/config/mips/mips.c:4176: warning: no previous 
prototype for 'mips_use_ins_ext_p'

This function was introduced by

2005-05-26  David Ung  <[EMAIL PROTECTED]>

* config/mips/mips.c (mips_use_ins_ext_p): New helper function
that determines whether the MIPS32/64 R2 ext/ins should be used.
 

Declaring the function as static in mips.c doesn't work, as then we get a 
warning about unused functions.  The patch below enables bootstrap to 
continue, but I don't think it is correct.

--- mips.c  27 May 2005 23:08:31 -  1.507
+++ mips.c  1 Jun 2005 01:07:11 -
@@ -369,6 +369,7 @@
 static rtx mips_expand_builtin_compare (enum mips_builtin_type,
enum insn_code, enum mips_fp_condition,
rtx, tree);
+bool mips_use_ins_ext_p (rtx op, rtx size, rtx position);
 
 /* Structure to be filled in by compute_frame_size with register
save masks, and offsets for the current function.  */

-- 
   Summary: irix6.5 bootstrap fails due to warning in mips.c
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: bootstrap
AssignedTo: davidu at mips dot com
ReportedBy: billingd at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: mips-sgi-irix6.5
  GCC host triplet: mips-sgi-irix6.5
GCC target triplet: mips-sgi-irix6.5


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

[Bug c++/21784] [3.4 Regression] Using vs builtin names

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-01 
00:34 ---
: Search converges between 2003-09-08-trunk (#346) and 2003-09-09-trunk (#347).

-- 
   What|Removed |Added

 Status|REOPENED|ASSIGNED


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

[Bug c++/21210] [4.0/4.1 Regression] Trouble with __complex__ types default construction

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-01 
00:33 ---
: Search converges between 2004-10-19-161001-trunk (#599) and 
2004-10-20-014001-trunk 
(#600).


-- 


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

[Bug c++/21619] [4.0/4.1 regression] __builtin_constant_p(&"Hello"[0])?1:-1 not compile-time constant

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-01 
00:31 ---
: Search converges between 2004-08-30-trunk (#529) and 2004-08-31-trunk (#530).

-- 


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

[Bug c++/21685] [3.4/4.0/4.1 Regression] Internal compiler error on invalid code

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-01 
00:29 ---
: Search converges between 2004-02-01-trunk (#445) and 2004-03-01-trunk (#446).

-- 


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

[Bug middle-end/21728] [4.0/4.1 Regression] Nonlocal gotos between nested functions cause undefined labels in assembler output

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-01 
00:26 ---
This was introduced with the merge of the tree-ssa.

-- 


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

[Bug c++/21383] [3.4/4.0/4.1 Regression] Crash when finding &a_templated_func<>

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-01 
00:20 ---
: Search converges between 2003-08-10-trunk (#319) and 2003-08-11-trunk (#320).

-- 


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

[Bug c++/21627] [3.4/4.0/4.1 Regression] invalid inline warning

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-01 
00:19 ---
: Search converges between 2002-12-14-trunk (#159) and 2002-12-29-trunk (#160).

-- 


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

[Bug c++/21369] [4.0/4.1 Regression] Template function definition rejected if function return type begins with 'struct'

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-01 
00:18 ---
: Search converges between 2004-11-25-014001-trunk (#656) and 
2004-11-25-161001-trunk 
(#657).

-- 


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

[Bug c++/21135] [4.0/4.1 Regression] &a[-2] ICE at the top level

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-01 
00:17 ---
: Search converges between 2004-08-30-trunk (#529) and 2004-08-31-trunk (#530).


-- 


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

[Bug c++/21336] [3.4/4.0/4.1 Regression] Internal compiler error when using custom new operators

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-01 
00:17 ---
The ICE started
: Search converges between 2004-01-17-trunk (#438) and 2004-01-23-trunk (#439).

-- 


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

[Bug c++/21853] [3.4/4.0/4.1 Regression] constness of pointer to data member ignored

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-01 
00:12 ---
This has been failing since at least 2000-12-31.

-- 


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

[Bug c++/21853] [3.4/4.0/4.1 Regression] constness of pointer to data member ignored

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-06-01 00:11:22
   date||


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

[Bug c++/21853] [3.4/4.0/4.1 Regression] constness of pointer to data member ignored

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-01 
00:11 ---
Confirmed, a regression from 2.95.3 where we accepted the code.

-- 
   What|Removed |Added

   Keywords||rejects-valid
  Known to fail||3.3.3 3.4.0 4.0.0 4.1.0
   ||3.0.4 3.2.3
  Known to work||2.95.3
Summary|constness of pointer to data|[3.4/4.0/4.1 Regression]
   |member ignored  |constness of pointer to data
   ||member ignored
   Target Milestone|--- |3.4.5


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

[Bug c++/21853] New: constness of pointer to data member ignored

[david dot m dot krauss at intel dot com]

When casting a pointer to const to a pointer to const pointer to data member
type, the constness of the ptdm is ignored. This breaks ptdm members of
boost::variant union types. Example code:

struct blah {
int a;
};

int main( int argc, char ** argv ) {
int blah::* ptdma = &blah::a;

const void *ptdmv = static_cast< void * >( &ptdma );

int blah::* const ptdmb = * static_cast< int blah::* const * >( ptdmv );

return 0;
}

This code compiles fine on the Comeau web test-drive. GCC 3.1, 3.4.3, and 4.0.0
all choke on the second static_cast. (I'm only filing for 4.0.0.)

More stats:

% /usr/intel/pkgs/gcc/4.0.0/bin/g++ -v -save-temps test2.cpp
Reading specs from
/nfs/site/itools/i386_linux24/pkgs/gcc/4.0.0/bin/../lib/gcc/i686-pc-linux-gnu/4.0.0/specs
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.0/configure --prefix=/usr/intel/pkgs/gcc/4.0.0
--with-as=/usr/intel/pkgs/gcc/4.0.0/bin/gas
--with-ld=/usr/intel/pkgs/gcc/4.0.0/bin/gld --disable-libgcj
--enable-languages=c,c++,objc
Thread model: posix
gcc version 4.0.0
 
/nfs/site/itools/i386_linux24/pkgs/gcc/4.0.0/bin/../libexec/gcc/i686-pc-linux-gnu/4.0.0/cc1plus
-E -quiet -v -iprefix
/nfs/site/itools/i386_linux24/pkgs/gcc/4.0.0/bin/../lib/gcc/i686-pc-linux-gnu/4.0.0/
-D_GNU_SOURCE test2.cpp -mtune=pentiumpro -fpch-preprocess -o test2.ii
ignoring nonexistent directory
"/nfs/site/itools/i386_linux24/pkgs/gcc/4.0.0/bin/../lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../i686-pc-linux-gnu/include"
ignoring duplicate directory
"/usr/intel/pkgs/gcc/4.0.0/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0"
ignoring duplicate directory
"/usr/intel/pkgs/gcc/4.0.0/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/i686-pc-linux-gnu"
ignoring duplicate directory
"/usr/intel/pkgs/gcc/4.0.0/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/backward"
ignoring duplicate directory
"/usr/intel/pkgs/gcc/4.0.0/lib/gcc/i686-pc-linux-gnu/4.0.0/include"
ignoring nonexistent directory
"/usr/intel/pkgs/gcc/4.0.0/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 
/nfs/site/itools/i386_linux24/pkgs/gcc/4.0.0/bin/../lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0
 
/nfs/site/itools/i386_linux24/pkgs/gcc/4.0.0/bin/../lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/i686-pc-linux-gnu
 
/nfs/site/itools/i386_linux24/pkgs/gcc/4.0.0/bin/../lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/backward
 
/nfs/site/itools/i386_linux24/pkgs/gcc/4.0.0/bin/../lib/gcc/i686-pc-linux-gnu/4.0.0/include
 /usr/local/include
 /usr/intel/pkgs/gcc/4.0.0/include
 /usr/include
End of search list.
 
/nfs/site/itools/i386_linux24/pkgs/gcc/4.0.0/bin/../libexec/gcc/i686-pc-linux-gnu/4.0.0/cc1plus
-fpreprocessed test2.ii -quiet -dumpbase test2.cpp -mtune=pentiumpro -auxbase
test2 -version -o test2.s
GNU C++ version 4.0.0 (i686-pc-linux-gnu)
compiled by GNU C version 3.4.2.
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128505
test2.cpp: In function 'int main(int, char**)':
test2.cpp:10: error: static_cast from type 'const void*' to type 'const int
blah::* const* const' casts away constness

-- 
   Summary: constness of pointer to data member ignored
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: david dot m dot krauss at intel dot com
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug target/21852] Need method of changing default CPU for target

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-31 
23:52 ---
(In reply to comment #0)
> I'm sure many people would also find it useful for other platforms, i.e. x86.

X86 already have it in form of --with-cpu= and so does SPARC.

In fact it is documented too:
--with-cpu=cpu
Specify which cpu variant the compiler should generate code for by default. cpu 
will be used as the 
default value of the -mcpu= switch. This option is only supported on some 
targets, including ARM, 
i386, PowerPC, and SPARC. 


-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug target/21852] New: Need method of changing default CPU for target

[aaronw at net dot com]

It would be very useful if I could configure the default target CPU to be an  
ultrasparc instead of the default since this gives a major performance boost to 
 
the target in many cases.  I am sure there's some way of doing this, but if so  
it isn't documented anywhere.  
  
Not only that, but it would also be useful to be able to optimize a compiler  
for a particular processor.  
  
In our case, we don't have anything below an Ultrasparc that we need to support 
 
and I imagine there's many other organizations in the same boat. 
 
I'm sure many people would also find it useful for other platforms, i.e. x86.

-- 
   Summary: Need method of changing default CPU for target
   Product: gcc
   Version: 3.3.6
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aaronw at net dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: sparc-sun-solaris2.8
  GCC host triplet: sparc-sun-solaris2.8
GCC target triplet: sparc-sun-solaris2.8


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

[Bug tree-optimization/21734] [4.1 regression] ICE: -ftree-vectorize, segfault

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-31 
23:28 ---
*** Bug 21851 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||bangerth at dealii dot org


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

[Bug tree-optimization/21851] [4.1 regression] segfault with -ftree-vectorize

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-31 
23:28 ---
This is a dup of bug 21734.

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug tree-optimization/19716] Segfault with -ftree-vectorize

[bangerth at dealii dot org]

--- Additional Comments From bangerth at dealii dot org  2005-05-31 23:28 
---
I can still reproduce this with today's mainline. The segfault still 
happens in a movapd instruction: 
 
0x08048389 <_Z1fv+21>:  movapd %xmm0,(%eax) 
 
(gdb) info registers eax 
eax0xbfffe944   -1073747644 
 
This address is not divisible by 16. I am unsure whether this has something 
to do with the stack alignment that always comes up -- here's my glibc 
version: 
 
home/bangerth> /lib/libc.so.6  
GNU C Library stable release version 2.3.4 (20050218), by Roland McGrath et 
al. 
Copyright (C) 2005 Free Software Foundation, Inc. 
 
 
W. 

-- 


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

[Bug tree-optimization/21851] [4.1 regression] segfault with -ftree-vectorize

[bangerth at dealii dot org]

--- Additional Comments From bangerth at dealii dot org  2005-05-31 23:21 
---
Created an attachment (id=9004)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9004&action=view)
Preprocessed source


-- 


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

[Bug tree-optimization/21851] New: [4.1 regression] segfault with -ftree-vectorize

[bangerth at dealii dot org]

With attached code, I get a segmentation fault: 
 
spec/src> c++ -c -O -march=pentium4m -ftree-vectorize 
auto_derivative_function.ii 
auto_derivative_function.ii:6859: warning: ‘__malloc__’ attribute 
ignored 
auto_derivative_function.ii: In member function ‘Tensor<1, dim> 
AutoDerivativeFunction::gradient(const Point&, unsigned int) const 
[with int dim = 3]’: 
auto_derivative_function.ii:32007: internal compiler error: Segmentation fault 
Please submit a full bug report, 
with preprocessed source if appropriate. 
See http://gcc.gnu.org/bugs.html> for instructions. 
 
Unfortunately, I have no time right now to reduce this code further :-( 
 
W.

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


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

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

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-31 
23:07 ---
Subject: Bug 21817

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-05-31 23:07:26

Modified files:
gcc: ChangeLog tree-ssa-loop-im.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.dg/torture: pr21817-1.c 

Log message:
PR tree-optimization/21817
* tree-ssa-loop-im.c (for_each_index): Handle VECTOR_CST.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8958&r2=2.8959
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop-im.c.diff?cvsroot=gcc&r1=2.42&r2=2.43
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5567&r2=1.5568
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/torture/pr21817-1.c.diff?cvsroot=gcc&r1=1.1&r2=1.2



-- 


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

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

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-31 
23:03 ---
Subject: Bug 21817

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-05-31 23:02:52

Modified files:
gcc: ChangeLog tree-ssa-loop-im.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.dg/torture: pr21817-1.c 

Log message:
PR tree-optimization/21817
* tree-ssa-loop-im.c (for_each_index): Handle VECTOR_CST.

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.269&r2=2.7592.2.270
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop-im.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.28&r2=2.28.2.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.212&r2=1.5084.2.213
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/torture/pr21817-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=21817

[Bug tree-optimization/15459] [meta-bug] there should be a tree combiner like the rtl one

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-31 
22:36 ---
Patch posted here:  
but it has a 
couple of regressions.  First PR 21850.  Second a latent bug in VRP saying the 
CFG will always be 
cleaned which is not true.

-- 


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

[Bug rtl-optimization/21848] [4.1 Regression] load_mems / replace_loop_mems bug causes miscompilation of jcf-io.c / SEGV while processing java/lang/AbstractMethodError

[amylaar at gcc dot gnu dot org]

-- 
   What|Removed |Added

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


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

[Bug tree-optimization/21155] [4.1 Regression] ICE in ssa tree check compiling crafty with -ftree-vectorize -maltivec

[janis at gcc dot gnu dot org]

--- Additional Comments From janis at gcc dot gnu dot org  2005-05-31 22:06 
---
With sources from an hour ago I get the same ICE compiling 176.gcc and 191.fma3d
on powerpc64-linux using "-m64 -O2 -ftree-vectorize -maltivec"; all other SPEC
CPU2000 tests compile and run successfully using those options with the same
compiler.  These sources include both of the patches mentioned in comment #6.

Dorit, can you reproduce these using a powerpc64-linux cross compiler?  To test
an ICE it's only necessary to build cc1; I can send you the script I use.

-- 


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

[Bug target/21721] [4.0 regression] fails to assemble, Use of p0 is not valid in this context

[sje at cup dot hp dot com]

--- Additional Comments From sje at cup dot hp dot com  2005-05-31 21:10 
---
It looks like this is due to code in ia64/ia64.c (ia64_compute_frame_size).
If we need to store any predicate register (before a call I presume), the code
stores them all and sets regs_ever_live[regno] to 1 for all predicate registers.

There are question marks in the comment for this code.  It looks like it was
added in version 1.40 of ia64.c by rth.

-- 


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

[Bug middle-end/21850] misscompiling comparision from vector to integer

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-31 
21:02 ---
The problem is that we are assuming TYPE_PRECISION of the vector is really the 
precision when it is in 
fact the number of elements.

-- 


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

[Bug rtl-optimization/21848] [4.1 Regression] load_mems / replace_loop_mems bug causes miscompilation of jcf-io.c / SEGV while processing java/lang/AbstractMethodError

[amylaar at gcc dot gnu dot org]

--- Additional Comments From amylaar at gcc dot gnu dot org  2005-05-31 
20:56 ---
The problem would not arise if the call was neither const nor pure.

cselib_process_insn has this code:

  if (CALL_P (insn))
{
  for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
if (call_used_regs[i]
|| (REG_VALUES (i) && REG_VALUES (i)->elt
&& HARD_REGNO_CALL_PART_CLOBBERED (i,
  GET_MODE (REG_VALUES (i)->elt->u.val_rtx
  cselib_invalidate_regno (i, reg_raw_mode[i]);

  if (! CONST_OR_PURE_CALL_P (insn))
cselib_invalidate_mem (callmem);
}

So, this explains why ordinary calls work.

There is code in load_mems to take the argument of calls into account, but
it requires CALL_INSN_FUNCTION_USAGE to be set.  So a possible fix would make
sure that CALL_INSN_FUNCTION_USAGE is set correctly, at least for
CONST_OR_PURE_CALL_P functions.

-- 


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

[Bug middle-end/21850] misscompiling comparision from vector to integer

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-31 
20:50 ---
This used to work right before the branch of 4.0.0.

-- 
   What|Removed |Added

OtherBugsDependingO||15459
  nThis||


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

[Bug middle-end/21850] New: misscompiling comparision from vector to integer

[pinskia at gcc dot gnu dot org]

the following code is miscompiled:

extern void abort (void);

typedef int V2SI __attribute__ ((vector_size (8)));

int
main (void)
{
  if (((int)(long long)(V2SI){ 2, 2 })!=2)
abort ();
}


Note this is now blocking my tree combiner to be regression free.

-- 
   Summary: misscompiling comparision from vector to integer
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P2
 Component: middle-end
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=21850

[Bug rtl-optimization/21827] unroll misses simple elimination - works with manual unroll

[tlm at daimi dot au dot dk]

--- Additional Comments From tlm at daimi dot au dot dk  2005-05-31 20:45 
---
(In reply to comment #1)
> The first testcase is fixed in 4.0.0.   I have not looked 
> into the full testcase.

Installed gcc 4.0.0 (a bit hard with the current version)
OK - I was wrong before (so please do not close this). 
The simple situation is fixed - however there is still the same problems 
with the knight-example.

int unrolled_knight_count(unsigned char* board)
{
  int count = 0;
  for (int bp=0;bp<2;bp++) // reduces to 2 just for the example
  {
if (board[bp]==WHITE_KNIGHT)
{
  if (bp%8>1 && bp/8>0) count++;
  if (bp%8>0 && bp/8>1) count++;
  if (bp%8<6 && bp/8>0) count++;
  if (bp%8<7 && bp/8>1) count++;
  if (bp%8>1 && bp/8<7) count++;
  if (bp%8>0 && bp/8<6) count++;
  if (bp%8<6 && bp/8<7) count++;
  if (bp%8<7 && bp/8<6) count++;
}
  }
  return count;
}

is compiled to 
.text
.align 2
.p2align 4,,15
.globl _Z26unrolled_knight_countPh
.type   _Z26auto_unrolled_knight_countPh, @function
_Z26auto_unrolled_knight_countPh:
.LFB2:
pushl   %ebp
.LCFI0:
xorl%eax, %eax
movl%esp, %ebp
.LCFI1:
movl8(%ebp), %edx
cmpb$5, (%edx)
je  .L10
.L6:
cmpb$5, 1(%edx)
je  .L11
popl%ebp
ret
.p2align 4,,7
.L11:
popl%ebp
addl$3, %eax
.p2align 4,,6
ret
.p2align 4,,7
.L10:
movl$2, %eax
.p2align 4,,7
jmp .L6
.LFE2:
.size   _Z26auto_unrolled_knight_countPh, 
.-_Z26auto_unrolled_knight_countPh
.ident  "GCC: (GNU) 4.0.0"
.section.note.GNU-stack,"",@progbits

Now if I (manual) expand the loop before compiling 

int unrolled_knight_count(unsigned char* board)
{
  int count = 0;
//  for (int bp=0;bp<64;bp++) // We expand 2 as before..
if (board[0]==WHITE_KNIGHT)
{
  if (0%8>1 && 0/8>0) count++;
  if (0%8>0 && 0/8>1) count++;
  if (0%8<6 && 0/8>0) count++;
  if (0%8<7 && 0/8>1) count++;
  if (0%8>1 && 0/8<7) count++;
  if (0%8>0 && 0/8<6) count++;
  if (0%8<6 && 0/8<7) count++;
  if (0%8<7 && 0/8<6) count++;
}
if (board[1]==WHITE_KNIGHT)
{
  if (1%8>1 && 1/8>0) count++;
  if (1%8>0 && 1/8>1) count++;
  if (1%8<6 && 1/8>0) count++;
  if (1%8<7 && 1/8>1) count++;
  if (1%8>1 && 1/8<7) count++;
  if (1%8>0 && 1/8<6) count++;
  if (1%8<6 && 1/8<7) count++;
  if (1%8<7 && 1/8<6) count++;
}
  return count;
}

The result is mush better. (Not that I know assemblercode) 

I have WHITE_KNIGT = 5 (as you might have seen from the assemblercode)
and when I timed I had knights on pos 24,44,55,56. And the code is 
400-500% faster - so it will really improve the speed ...

.text
.align 2
.p2align 4,,15
.globl _Z26unrolled_knight_countPh
.type   _Z26auto_unrolled_knight_countPh, @function
_Z26unrolled_knight_countPh:
.LFB2:
pushl   %ebp
.LCFI0:
xorl%eax, %eax
movl%esp, %ebp
.LCFI1:
movl8(%ebp), %edx
cmpb$5, (%edx)
sete%al
addl%eax, %eax
cmpb$5, 1(%edx)
je  .L9
popl%ebp
ret
.p2align 4,,7
.L9:
popl%ebp
addl$3, %eax
ret

Again thanks. I do not want to sound like an unhappy gcc-user 
(I admire the work you are doing). 



-- 


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

[Bug tree-optimization/21849] New: wrong use of sbitmap in tree-ssa-copy.c

[kazu at cs dot umass dot edu]

visited = sbitmap_alloc (num_ssa_names);

does not come with a call to sbitmap_clear.

-- 
   Summary: wrong use of sbitmap in tree-ssa-copy.c
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: tree-optimization
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=21849

[Bug tree-optimization/21584] [4.1 Regression] ICE: verify_flow_sensitive_alias_info failed.

[tobias at yoper dot com]

--- Additional Comments From tobias at yoper dot com  2005-05-31 20:23 
---
can be confirmed while compiling groff-1.19.1

i686-pc-linux-gnu-g++ -v --save-temps -I. -I.
-I/usr/src/yoper/BUILD/groff-1.19.1/src/include
-I/usr/src/yoper/BUILD/groff-1.19.1/src/include -DHAVE_CONFIG_H -O3 -march=i686
-mtune=i686 -m32 -pipe -fomit-frame-pointer -maccumulate-outgoing-args -fPIC
-fvisibility-inlines-hidden  -c ps.cpp
i686-pc-linux-gnu-g++: warning: -pipe ignored because -save-temps specified
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1-20050528/configure --host=i686-pc-linux-gnu
--build=i686-pc-linux-gnu --target=i686-pc-linux-gnu --prefix=/usr
--sysconfdir=/etc --sharedstatedir=/var/com --localstatedir=/var
--libdir=/usr/lib --includedir=/usr/include --infodir=/usr/share/info
--mandir=/usr/share/man --enable-shared --enable-threads=posix --enable-static
--enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++ --enable-nls
--with-system-zlib --disable-multilib
Thread model: posix
gcc version 4.1.0 20050528 (experimental)
 /usr/libexec/gcc/i686-pc-linux-gnu/4.1.0/cc1plus -E -quiet -v -I. -I.
-I/usr/src/yoper/BUILD/groff-1.19.1/src/include
-I/usr/src/yoper/BUILD/groff-1.19.1/src/include -D_GNU_SOURCE -DHAVE_CONFIG_H
ps.cpp -march=i686 -mtune=i686 -m32 -maccumulate-outgoing-args
-fomit-frame-pointer -fPIC -fvisibility-inlines-hidden -O3 -fpch-preprocess -o 
ps.ii
[...]
/usr/libexec/gcc/i686-pc-linux-gnu/4.1.0/cc1plus -fpreprocessed ps.ii -quiet
-dumpbase ps.cpp -march=i686-mtune=i686 -m32 -maccumulate-outgoing-args -auxbase
ps -O3 -version -fomit-frame-pointer -fPIC -fvisibility-inlines-hidden -o ps.s
GNU C++ version 4.1.0 20050528 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.0.0.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: d4ec6a8f635cd5c4155aad0c4d4e580f
ps.cpp: In member function 'void ps_printer::define_encoding(const char*, int)':
ps.cpp:781: error: Pointers with a memory tag, should have points-to sets or
point to malloc
p_27, name memory tag: NMT.942, points-to vars: { }
p, UID 11, char *, type memory tag: TMT.936
ps.cpp:781: internal compiler error: verify_flow_sensitive_alias_info failed.
Please submit a full bug report,




-- 


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

[Bug rtl-optimization/21848] [4.1 Regression] load_mems / replace_loop_mems bug causes miscompilation of jcf-io.c / SEGV while processing java/lang/AbstractMethodError

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

Summary|load_mems / |[4.1 Regression] load_mems /
   |replace_loop_mems bug causes|replace_loop_mems bug causes
   |miscompilation of jcf-io.c /|miscompilation of jcf-io.c /
   |SEGV while processing   |SEGV while processing
   |java/lang/AbstractMethodErro|java/lang/AbstractMethodErro
   |r   |r
   Target Milestone|--- |4.1.0


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

[Bug middle-end/21846] [4.1 Regression] segfault in fold_binary compiling vpr with -O2 -funroll-loops

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-31 
20:09 ---
Only -O2 -funroll-loops is needed to reproduce the bug.

-- 
   What|Removed |Added

Summary|[4.1 Regression] segfault in|[4.1 Regression] segfault in
   |fold_binary compiling vpr   |fold_binary compiling vpr
   |with -O3|with -O2 -funroll-loops


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

[Bug rtl-optimization/21848] New: load_mems / replace_loop_mems bug causes miscompilation of jcf-io.c / SEGV while processing java/lang/AbstractMethodError

[amylaar at gcc dot gnu dot org]

gcc fails to bootstrap on i686-pc-linux-gnu:
./../.././gcc/gcjh -classpath '' -bootclasspath . java/lang/AbstractMethodError
make[2]: *** [java/lang/AbstractMethodError.h] Segmentation fault
make[2]: *** Deleting file `'
make[2]: Leaving directory
`/mnt/scratch/nightly/2005-05-31/i686/i686-pc-linux-gnu/libjava'
make[1]: *** [all-target-libjava] Error 2

gcc/java/jcf-io.c:format_uint is miscompiled.
This is the function:

extern void format_uint (char *, unsigned long long, int);

void
format_uint (char *buffer, unsigned long long value, int base)
{

  char buf[(4 + sizeof(unsigned long long) * 8)];
  char *buf_ptr = buf+(4 + sizeof(unsigned long long) * 8);
  int chars_written;
  int i;



  do {
int digit = value % base;
static const char digit_chars[] = "0123456789abcdefghijklmnopqrstuvwxyz";
*--buf_ptr = digit_chars[digit];
value /= base;
  } while (value != 0);

  chars_written = buf+(4 + sizeof(unsigned long long) * 8) - buf_ptr;
  for (i = 0; i < chars_written; i++)
buffer[i] = *buf_ptr++;
  buffer[i] = 0;
}

compiled with:

stage2/cc1 -fpreprocessed jcf-io.i -quiet -dumpbase jcf-io.c -march=i686
-auxbase-strip trash -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
-Wold-style-definition -Werror -version -fomit-frame-pointer -fno-common -o 
jcf-io.s

compilation with the stage1 compiler shows identical miscompilation.
The parameters for umoddi are not written to the stack.

In jcf-io.c.05.gcse, we have:

(insn 22 21 23 1 jcf-io-0.i:17 (set (mem:DI (plus:SI (reg/f:SI 7 sp)
(const_int 8 [0x8])) [0 S8 A32])
(reg:DI 62 [ pretmp.7 ])) 58 {*movdi_2} (nil)
(insn_list:REG_LIBCALL 25 (nil)))

(insn 23 22 24 1 jcf-io-0.i:17 (set (mem:DI (reg/f:SI 7 sp) [0 S8 A32])
(reg/v:DI 68 [ value ])) 58 {*movdi_2} (nil)
(nil))

(call_insn/u 24 23 25 1 jcf-io-0.i:17 (set (reg:DI 0 ax)
(call (mem:QI (symbol_ref:SI ("__umoddi3") [flags 0x41]) [0 S1 A8])
(const_int 16 [0x10]))) 529 {*call_value_0} (nil)
(expr_list:REG_EH_REGION (const_int -1 [0x])
(nil))
(nil))

(insn 25 24 27 1 jcf-io-0.i:17 (set (reg:DI 76)
(reg:DI 0 ax)) 58 {*movdi_2} (nil)
(insn_list:REG_RETVAL 22 (expr_list:REG_EQUAL (umod:DI (reg/v:DI 68 [ value 
])
(reg:DI 62 [ pretmp.7 ]))
(nil

But in jcf-io.c.06.loop:
(insn 22 21 23 1 jcf-io-0.i:17 (set (reg/v:DI 87 [ pretmp.7 ])
(reg:DI 62 [ pretmp.7 ])) -1 (nil)
(insn_list:REG_LIBCALL 25 (nil)))

(insn 23 22 24 1 jcf-io-0.i:17 (set (reg/v:DI 88 [ value ])
(reg/v:DI 68 [ value ])) -1 (nil)
(nil))

(call_insn/u 24 23 25 1 jcf-io-0.i:17 (set (reg:DI 0 ax)
(call (mem:QI (symbol_ref:SI ("__umoddi3") [flags 0x41]) [0 S1 A8])
(const_int 16 [0x10]))) -1 (nil)
(expr_list:REG_EH_REGION (const_int -1 [0x])
(nil))
(nil))

(insn 25 24 27 1 jcf-io-0.i:17 (set (reg:DI 76)
(reg:DI 0 ax)) -1 (nil)
(insn_list:REG_RETVAL 22 (expr_list:REG_EQUAL (umod:DI (reg/v:DI 68 [ value 
])
(reg:DI 62 [ pretmp.7 ]))
(nil

The SET_SRC of insn 22 is changed here:

Hardware watchpoint 6: *$4

Old value = 0xb5927d14
New value = 0xb591da80
validate_change (object=0xb58b7c08, loc=0xb5927838, new=0xb591da80, in_group=1)
at ../../srcw/gcc/recog.c:203
203   if (num_changes >= changes_allocated)
(gdb) call debug_rtx_find(get_insns(),22)
(insn 22 21 23 jcf-io-0.i:17 (set (reg/v:DI 87)
(reg:DI 62 [ pretmp.7 ])) -1 (nil)
(insn_list:REG_LIBCALL 25 (nil)))

$5 = (struct rtx_def *) 0xb58b7c08
(gdb) frame 1
#1  0x08584119 in replace_loop_mem (mem=0xb5927838, data=0xbfffb480)
at ../../srcw/gcc/loop.c:11374
11374 validate_change (args->insn, mem, args->replacement, 1);
(gdb) bt
#0  validate_change (object=0xb58b7c08, loc=0xb5927838, new=0xb591da80, 
in_group=1) at ../../srcw/gcc/recog.c:203
#1  0x08584119 in replace_loop_mem (mem=0xb5927838, data=0xbfffb480)
at ../../srcw/gcc/loop.c:11374
#2  0x0845797e in for_each_rtx_1 (exp=0xb5927834, n=0, 
f=0x8584097 , data=0xbfffb480)
at ../../srcw/gcc/rtlanal.c:2645
#3  0x084579dc in for_each_rtx_1 (exp=0xb58b7c08, n=5, 
f=0x8584097 , data=0xbfffb480)
at ../../srcw/gcc/rtlanal.c:2660
#4  0x08457b4b in for_each_rtx (x=0xbfffb4a0, f=0x8584097 , 
data=0xbfffb480) at ../../srcw/gcc/rtlanal.c:2741
#5  0x08584155 in replace_loop_mems (insn=0xb58b7c08, mem=0xb5927d14, 
reg=0xb591da80, written=1) at ../../srcw/gcc/loop.c:11388
#6  0x08583470 in load_mems (loop=0x9812738) at ../../srcw/gcc/loop.c:10968
#7  0x08572f66 in scan_loop (loop=0x9812738, flags=0)
at ../../srcw/gcc/loop.c:1543
#8  0x08571321 in loop_optimize (f=0xb58afae0, dumpfile=0x0, flags=0)
at ../../srcw/gcc/loop.c:907
#9  0x084b9495 in rest_of_handle_loop_optimize ()
at ../../srcw/gcc/passes.c:
#10 0x084ba079 in rest_of_compilation () at ../../srcw/gcc/passes.c:1573

-- 

[Bug middle-end/21846] [4.1 Regression] segfault in fold_binary compiling vpr with -O3

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-31 
19:59 ---
Confirmed, we have a SSA_NAME which is in the free list.

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  GCC build triplet|powerpc64-linux |
   GCC host triplet|powerpc64-linux |
 GCC target triplet|powerpc64-linux |powerpc64-*-*
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2005-05-31 19:59:36
   date||
Summary|segfault in fold_binary |[4.1 Regression] segfault in
   |compiling vpr with -O3  |fold_binary compiling vpr
   ||with -O3
   Target Milestone|--- |4.1.0


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

[Bug middle-end/21790] gcc 4.1.0 20050522 segfaults (internal compiler error) on various GNU/Linux builds

[mclinden at informed dot net]

--- Additional Comments From mclinden at informed dot net  2005-05-31 19:48 
---
This problem disappeared after upgrading to gcc-4.1-20050528.

-- 
   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED


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

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

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-31 
19:47 ---
Note if we move the division inside the throw block, this works just fine.

-- 


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

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

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 GCC target triplet||i686-pc-linux-gnu


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

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

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-31 
19:39 ---
DCE removes it even though it can throw.

-- 
   What|Removed |Added

  Component|middle-end  |tree-optimization


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

[Bug middle-end/21847] [4.0/4.1 Regression] misscompiling of the following java code

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.0.0


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

[Bug middle-end/21847] New: [4.0/4.1 Regression] misscompiling of the following java code

[pinskia at gcc dot gnu dot org]

The following java code should print PASS but instead it prints FAIL at -O1 and 
above:
class t
{
public static void test()
{
int i =0;
int j = 1;
int k = j/i;

}
public static void main(String a1[])
{
try {
test();
}catch (ArithmeticException e)
{
  System.out.println("Pass");
  return;
}
  System.out.println("Fail");
}
}

-- 
   Summary: [4.0/4.1 Regression] misscompiling of the following java
code
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P2
 Component: middle-end
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=21847

[Bug middle-end/21846] segfault in fold_binary compiling vpr with -O3

[janis at gcc dot gnu dot org]

--- Additional Comments From janis at gcc dot gnu dot org  2005-05-31 19:34 
---
Created an attachment (id=9003)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9003&action=view)
minimized test case


-- 


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

[Bug middle-end/21846] New: segfault in fold_binary compiling vpr with -O3

[janis at gcc dot gnu dot org]

Mainline GCC gets a seg fault building SPEC CPU2000 test vpr on
powerpc64-linux with "-m64 -O3" starting with this patch from rakdver
on 20050517:

  http://gcc.gnu.org/ml/gcc-cvs/2005-05/msg00814.html

The seg fault is in fold_binary at fold_const.c:8971.

I'll attach a minimized test case.

-- 
   Summary: segfault in fold_binary compiling vpr with -O3
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,rakdver at gcc dot gnu
dot org
 GCC build triplet: powerpc64-linux
  GCC host triplet: powerpc64-linux
GCC target triplet: powerpc64-linux


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

[Bug translation/21364] [translation] %J in translation instead of %H causes ICE in de.po

[pinskia at gcc dot gnu dot org]

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

-- 
   What|Removed |Added

 CC||tobias at yoper dot com


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

[Bug c/21845] ICE when compiling binutils with LANG=de_DE

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-31 
19:15 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c/21845] New: ICE when compiling binutils with LANG=de_DE

[tobias at yoper dot com]

Sorry to send you a german error message, but as I manually switched to LANG=C
to get an English error report and typed make, the build-process proceeded
unexpectedly. This failure got approved during three builts within different
chroots but all using a profiledbootstrapped version of snapshot 20050528 of
gcc-4.1 .

This is the last command while compiling binutils 2.15.97:

gcc -DHAVE_CONFIG_H -I. -I.././binutils -I. -D_GNU_SOURCE -I. -I.././binutils
-I../bfd -I.././binutils/../bfd -I.././binutils/../include
-I.././binutils/../intl -I../intl -DLOCALEDIR="\"/usr/share/locale\""
-Dbin_dummy_emulation=bin_vanilla_emulation  -D_LARGEFILE64_SOURCE -W -Wall
-Wstrict-prototypes -Wmissing-prototypes -O3 -march=i686 -mtune=i686 -m32 -pipe
-fomit-frame-pointer -maccumulate-outgoing-args -fPIC -c wrstabs.c

wrstabs.c: In Funktion »stab_tag_type«:
wrstabs.c:1867: interner Compiler-Fehler: Baumprüfung: Klasse »declaration«
erwartet, haben »type« (qual_union_type) in pp_base_prepare_to_format, bei
pretty-print.c:196

For any further information, ask !

-- 
   Summary: ICE when compiling binutils with LANG=de_DE
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tobias at yoper dot com
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=21845

[Bug testsuite/20772] x86 tests should run on both i?86 and x86_64

[joseph at codesourcery dot com]

--- Additional Comments From joseph at codesourcery dot com  2005-05-31 
18:15 ---
Subject: Re:  x86 tests should run on both i?86 and
 x86_64

There seem to be still a few instances of tests that are only for x86_64 
and should also operate on i?86 -m64:

gcc.dg/torture/pr20314-2.c
gcc.dg/tree-ssa/stdarg-[2345].c
gcc.dg/asm-b.c (has what looks like a typo, i?386-*-*)
gcc.target/i386/amd64-abi-1.c



-- 


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

[Bug java/21844] New: miscompilation of LinkedHashMap

[tromey at gcc dot gnu dot org]

This happens with 4.1 but not with 4.0.x.
It occurs even without -O.

I believe java.util.LinkedHashMap is being miscompiled.
You can see this by trying the test case in PR 20273.
For me, it crashes.

In the debugger I observed that this line from
LinkedHashMap$LinkedHashEntry.access() is incrementing
the 'succ' field and not the modCount field:
  modCount++;

-- 
   Summary: miscompilation of LinkedHashMap
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tromey at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
 GCC build triplet: i686-pc-linux-gnu


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

[Bug testsuite/20772] x86 tests should run on both i?86 and x86_64

[janis at gcc dot gnu dot org]

--- Additional Comments From janis at gcc dot gnu dot org  2005-05-31 18:05 
---
I'm unassigning myself.  I don't have a system on which to test these, and have
no interest in changing them because they work as they are now.

Adding effective targets x86_ilp32 and x86_lp64 is a very reasonable idea and
I'd have no objections to someone else adding them and changing the tests to
use them.

-- 
   What|Removed |Added

 AssignedTo|janis187 at us dot ibm dot  |unassigned at gcc dot gnu
   |com |dot org
 Status|ASSIGNED|NEW


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

[Bug c++/21165] [4.0/4.1 Regression] bogus error on a user-defined conversion in a template

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-31 
18:01 ---
Subject: Bug 21165

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-05-31 18:01:02

Modified files:
gcc/cp : ChangeLog init.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/g++.dg/template: init5.C 

Log message:
cp:
PR c++/21165
* init.c (integral_constant_value): Check the type of the
initializer, not the decl.
testsuite:
PR c++/21165
* g++.dg/template/init5.C: New.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.4648.2.50&r2=1.4648.2.51
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/init.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.412.2.4&r2=1.412.2.5
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.211&r2=1.5084.2.212
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/init5.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=21165

[Bug c++/21165] [4.0/4.1 Regression] bogus error on a user-defined conversion in a template

[nathan at gcc dot gnu dot org]

--- Additional Comments From nathan at gcc dot gnu dot org  2005-05-31 
18:01 ---
2005-05-31  Nathan Sidwell  <[EMAIL PROTECTED]>

PR c++/21165
* init.c (integral_constant_value): Check the type of the
initializer, not the decl.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/21799] [4.1 regression] Spurious ambiguity with pointers to members

[bangerth at dealii dot org]

--- Additional Comments From bangerth at dealii dot org  2005-05-31 17:56 
---
*** Bug 21066 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

Bug 21799 depends on bug 21066, which changed state.

Bug 21066 Summary: [4.1 Regression] template argument deduction finds false 
ambiguity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21066

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||DUPLICATEBug 21799 depends on 
bug 21066, which changed state.

Bug 21066 Summary: [4.1 Regression] template argument deduction finds false 
ambiguity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21066

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

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

[Bug c++/21066] [4.1 Regression] template argument deduction finds false ambiguity

[bangerth at dealii dot org]

--- Additional Comments From bangerth at dealii dot org  2005-05-31 17:56 
---
PR 21799 treats the same problem, but looks a little cleaner and has some 
additional comments. 
 
W. 

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

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug middle-end/21842] [4.1 Regression] 23_containers/bitset/operations/2.cc execution test fails

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 GCC target triplet||i686-pc-linux-gnu


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

[Bug middle-end/21842] [4.1 Regression] 23_containers/bitset/operations/2.cc execution test fails

[joseph at codesourcery dot com]

--- Additional Comments From joseph at codesourcery dot com  2005-05-31 
17:46 ---
Subject: Re:  [4.1 Regression] 23_containers/bitset/operations/2.cc
 execution test fails

On Tue, 31 May 2005, pcarlini at suse dot de wrote:

> Ok, this is by itself absolutely useful, of course. Only, categorizing as
> libstdc++-v3 can be "distracting", you know what I mean? Luckily, we have
> our trusty "bug masters" to take care of that ;)

Indeed, I leave it to the bugmasters to decide if there's a component 
which is a better approximation, or that the bug is the same as another 
one not mentioning the testcase in question, or is an issue fixed without 
mentioning the testcase.  Where the bug doesn't happen on i686-linux I may 
in due course run a binary search to identify the responsible patch.



-- 


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

[Bug c++/21165] [4.0/4.1 Regression] bogus error on a user-defined conversion in a template

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-31 
17:43 ---
Subject: Bug 21165

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

Modified files:
gcc/cp : ChangeLog init.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/g++.dg/template: init5.C 

Log message:
cp:
PR c++/21165
* init.c (integral_constant_value): Check the type of the
initializer, not the decl.
testsuite:
PR c++/21165
* g++.dg/template/init5.C: New.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4766&r2=1.4767
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/init.c.diff?cvsroot=gcc&r1=1.419&r2=1.420
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5566&r2=1.5567
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/init5.C.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug c++/21837] C++/C99 standard violation in for loop

[ahelm at gmx dot net]

--- Additional Comments From ahelm at gmx dot net  2005-05-31 17:41 ---
Subject: Re:  C++/C99 standard violation in for loop

At 12:48 31/05/2005, joseph at codesourcery dot com wrote:
>
>--- Additional Comments From joseph at codesourcery dot com  2005-05-31 
>11:48 ---
>Subject: Re:  New: C++/C99 standard violation in for loop
>
>On Tue, 31 May 2005, ahelm at gmx dot net wrote:
>
>>   for(int i=2;i<4;i++)
>>   {
>> int j = i;
>> int i;
>> i = 555;
>> printf("%d %d\n", i, j);
>>   }
>
>I don't see why you think there's any problem in C99 terms.  The for 
>statement forms a block (6.8.5#5 first sentence); its body forms a block 
>whose scope is a strict subset of that of the for statement (second 
>sentence) and the compound statement is itself a block (whether the same 
>block or a different one from that of the body as body doesn't matter in 
>this case, but if the body is a labeled compound statement then you'd have 
>distinct scopes).  As these are distinct blocks, they are distinct scopes; 
>you can declare i in the block which contains the for statement, and in 
>the declaration part of the for statement, and in the body of the for 
>statement.

I knew I missed something...
The end of scope description in the "for" chapter, "end of the loop" sounded
rather nebulous to me, that's why I wasn't 100% sure about C99.
Thanks for pointing this out.

Regards,

Tony



-- 


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

[Bug target/21719] program using "initgroups()" fails with stack corruption

[sje at cup dot hp dot com]

--- Additional Comments From sje at cup dot hp dot com  2005-05-31 17:38 
---
This seems more likely to be an HP library bug.  I recommend trying the latest
libc patch for HP-UX 11.11, PHCO_31903.  There is a reference to the HP defect
JAGad41604 that may be causing your problem.  I don't know why it wouldn't fail
when compiled with HP'c C.

-- 
   What|Removed |Added

 CC||sje at cup dot hp dot com
  GCC build triplet|hppa2.0w-hp-hpux11.11   |hppa2.0w-hpux11.11


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

[Bug tree-optimization/21839] [4.1 Regression] ICE for missing V_DEFS caused by salias with empty structures

[dberlin at dberlin dot org]

--- Additional Comments From dberlin at gcc dot gnu dot org  2005-05-31 
17:32 ---
Subject: Re:  [4.1 Regression] ICE for missing
V_DEFS caused by salias with empty structures

On Tue, 2005-05-31 at 17:25 +, nathan at gcc dot gnu dot org wrote:
> --- Additional Comments From nathan at gcc dot gnu dot org  2005-05-31 
> 17:25 ---
> Are you sure my changes changed this behaviour? IIRC my changes removed the
> funky behaviour of ignoring the first field's offset. (well, that was the 
> intent
> anyway)  I don't believe I changed the DECL_SIZE check bit.
> 
I looked, and it appears you are right.
Sorry bout that.
:)




-- 


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

[Bug c++/19932] [3.4 Regression] FAIL: g++.old-deja/g++.jason/rfg12.C (test for excess errors)

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  GCC build triplet|hppa2.0w-hp-hpux11.00   |
   GCC host triplet|hppa2.0w-hp-hpux11.00   |


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

[Bug c++/21264] duplicate symbol warnings for complex template class

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  GCC build triplet|powerpc-ibm-aix5.2.0.0  |
   GCC host triplet|powerpc-ibm-aix5.2.0.0  |


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

[Bug tree-optimization/21839] [4.1 Regression] ICE for missing V_DEFS caused by salias with empty structures

[nathan at gcc dot gnu dot org]

--- Additional Comments From nathan at gcc dot gnu dot org  2005-05-31 
17:25 ---
Are you sure my changes changed this behaviour? IIRC my changes removed the
funky behaviour of ignoring the first field's offset. (well, that was the intent
anyway)  I don't believe I changed the DECL_SIZE check bit.

-- 


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

[Bug c++/21799] [4.1 regression] Spurious ambiguity with pointers to members

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-31 
17:22 ---
I think this is a dup of bug 21066.

-- 
   What|Removed |Added

  BugsThisDependsOn||21066


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

[Bug c++/14556] ICE with

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  GCC build triplet|any |
   GCC host triplet|any |
 GCC target triplet|any |
   Keywords||ice-on-valid-code
   Last reconfirmed|2005-01-06 01:55:09 |2005-05-31 17:20:19
   date||


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

[Bug fortran/18283] gfortran: ICE in gfc_conv_string_parameter, trans-expr.c:1982

[cvs-commit at gcc dot gnu dot org]

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

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

Modified files:
gcc/fortran: ChangeLog trans-array.c trans-expr.c 

Log message:
2005-05-30  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/18109
PR fortran/18283
PR fortran/19107
* fortran/trans-array.c (gfc_conv_expr_descriptor): Obtain the
string length from the expression typespec character length value
and set temp_ss->stringlength and backend_decl. Obtain the
tree expression from gfc_conv_expr rather than gfc_conv_expr_val.
Dereference the expression to obtain the character.
* fortran/trans-expr.c (gfc_conv_component_ref): Remove the
dereference of scalar character pointer structure components.
* fortran/trans-expr.c (gfc_trans_subarray_assign): Obtain the
string length for the structure component from the component
expression.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.444&r2=1.445
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-array.c.diff?cvsroot=gcc&r1=1.46&r2=1.47
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-expr.c.diff?cvsroot=gcc&r1=1.47&r2=1.48



-- 


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

[Bug fortran/18109] ICE with explicit array of strings

[cvs-commit at gcc dot gnu dot org]

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

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

Modified files:
gcc/fortran: ChangeLog trans-array.c trans-expr.c 

Log message:
2005-05-30  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/18109
PR fortran/18283
PR fortran/19107
* fortran/trans-array.c (gfc_conv_expr_descriptor): Obtain the
string length from the expression typespec character length value
and set temp_ss->stringlength and backend_decl. Obtain the
tree expression from gfc_conv_expr rather than gfc_conv_expr_val.
Dereference the expression to obtain the character.
* fortran/trans-expr.c (gfc_conv_component_ref): Remove the
dereference of scalar character pointer structure components.
* fortran/trans-expr.c (gfc_trans_subarray_assign): Obtain the
string length for the structure component from the component
expression.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.444&r2=1.445
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-array.c.diff?cvsroot=gcc&r1=1.46&r2=1.47
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-expr.c.diff?cvsroot=gcc&r1=1.47&r2=1.48



-- 


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

[Bug target/19107] regclass.c miscompiled by -ftree-vectorize

[cvs-commit at gcc dot gnu dot org]

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

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

Modified files:
gcc/fortran: ChangeLog trans-array.c trans-expr.c 

Log message:
2005-05-30  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/18109
PR fortran/18283
PR fortran/19107
* fortran/trans-array.c (gfc_conv_expr_descriptor): Obtain the
string length from the expression typespec character length value
and set temp_ss->stringlength and backend_decl. Obtain the
tree expression from gfc_conv_expr rather than gfc_conv_expr_val.
Dereference the expression to obtain the character.
* fortran/trans-expr.c (gfc_conv_component_ref): Remove the
dereference of scalar character pointer structure components.
* fortran/trans-expr.c (gfc_trans_subarray_assign): Obtain the
string length for the structure component from the component
expression.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.444&r2=1.445
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-array.c.diff?cvsroot=gcc&r1=1.46&r2=1.47
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-expr.c.diff?cvsroot=gcc&r1=1.47&r2=1.48



-- 


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

[Bug c++/20629] [4.0/4.1 Regression] internal compiler error: in cp_tree_equal, at cp/tree.c:1552

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-31 
17:15 ---
This was fixed by:
2005-04-14  Dale Johannesen  <[EMAIL PROTECTED]>

* tree.c (cp_tree_equal):  Handle SSA_NAME.


-- 
   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED
Summary|internal compiler error: in |[4.0/4.1 Regression]
   |cp_tree_equal, at   |internal compiler error: in
   |cp/tree.c:1552  |cp_tree_equal, at
   ||cp/tree.c:1552
   Target Milestone|--- |4.0.0


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

[Bug middle-end/21842] [4.1 Regression] 23_containers/bitset/operations/2.cc execution test fails

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-05-31 17:14 
---
> Testing manually it seems to fail with -O2 or -O but not -O0.

Ah, ah, the same happens for the other regression that you just filed, it
seems! Thanks.

> In general when reporting bugs shown up by my regression tester I don't 
> know what part of the compiler they are in; I check enough to make sure 
> they don't appear to be system problems and aren't already reported with 
> reference to the named testcase or discussed on the lists as fixed, but 
> not to determine the exact cause.

Ok, this is by itself absolutely useful, of course. Only, categorizing as
libstdc++-v3 can be "distracting", you know what I mean? Luckily, we have
our trusty "bug masters" to take care of that ;)

-- 


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

[Bug c++/19243] Misleading error message for ill-formed explicit destructor invocation

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  GCC build triplet|all |
   GCC host triplet|all |
 GCC target triplet|all |


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

[Bug c++/21835] compilation of CRTP fails if the ABC is after template

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  GCC build triplet|sparc-sun-solaris2.8|
   GCC host triplet|sparc-sun-solaris2.8|
 GCC target triplet|sparc-sun-solaris2.8|


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

[Bug middle-end/21842] [4.1 Regression] 23_containers/bitset/operations/2.cc execution test fails

[joseph at codesourcery dot com]

--- Additional Comments From joseph at codesourcery dot com  2005-05-31 
17:05 ---
Subject: Re:  [4.1 Regression] 23_containers/bitset/operations/2.cc
 execution test fails

On Tue, 31 May 2005, pcarlini at suse dot de wrote:

> Notice that *nothing* changed in the relevant libstdc++-v3 code. Generally, 
> only
> small, confined changes lately. Either this is a miscompilation or a *very* 
> long
> standing latent problem. Can you attach the *.log excerpt? Even better, take 
> care
> of the obvious checks, like compiling at lower optimization level? (I'm also
> going to do that, anyway: we want to ascertain the miscompilation and 
> recategorize
> as soon as possible, in case)

Executing on host: g++ -g -O2 -D_GLIBCXX_ASSERT -fmessage-length=0 
-DLOCALEDIR="/scratch/gcc/nightly-2005-05-31-mainline/i686-pc-linux-gnu/build_gcc/install/bin/../share/locale"
 
-I/home/gcc/nightlies/src-mainline-2005-05-31/gcc-mainline/libstdc++-v3/testsuite
 
testsuite_abi.o testsuite_allocator.o testsuite_character.o 
testsuite_hooks.o 
/home/gcc/nightlies/src-mainline-2005-05-31/gcc-mainline/libstdc++-v3/testsuite/23_containers/bitset/operations/2.cc

-include bits/stdc++.h  -lm   -o ./2.exe(timeout = 300)
PASS: 23_containers/bitset/operations/2.cc (test for excess errors)
Setting LD_LIBRARY_PATH to 
:/scratch/gcc/nightly-2005-05-31-mainline/i686-pc-linux-gnu/build_gcc/install/lib:/usr/local/tools/gcc-3.4.0/lib
2.exe: 
/home/gcc/nightlies/src-mainline-2005-05-31/gcc-mainline/libstdc++-v3/testsuite/23_containers/bitset/operations/2.cc:33:
 
bool test02(): Assertion `b.count() == 0' failed.
FAIL: 23_containers/bitset/operations/2.cc execution test

(this is installed compiler testing, hence the short command line).  
Testing manually it seems to fail with -O2 or -O but not -O0.

In general when reporting bugs shown up by my regression tester I don't 
know what part of the compiler they are in; I check enough to make sure 
they don't appear to be system problems and aren't already reported with 
reference to the named testcase or discussed on the lists as fixed, but 
not to determine the exact cause.



-- 


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

[Bug middle-end/21842] [4.1 Regression] 23_containers/bitset/operations/2.cc execution test fails

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-05-31 16:59 
---
... well, at least both involve shifts ;)

-- 


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

[Bug libfortran/19481] libgfortran doesn't build -- configure doesn't handle cabs() well

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2005-05-31 
16:58 ---
Then, confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-05-31 16:58:48
   date||


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

[Bug c++/21514] [DR 278] templates and anonymous enum

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-05-31 
16:55 ---
Not specific to sparc-sun-solaris2.8.


-- 
   What|Removed |Added

  GCC build triplet|sparc-sun-solaris2.8|
   GCC host triplet|sparc-sun-solaris2.8|
 GCC target triplet|sparc-sun-solaris2.8|s


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

[Bug libfortran/21547] Unable to build libfortran library

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-05-31 
16:52 ---
Confirmed, but not specific to sparc-sun-solaris2.10.



-- 
   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  GCC build triplet|sparc-sun-solaris2.10   |
   GCC host triplet|sparc-sun-solaris2.10   |
 GCC target triplet|sparc-sun-solaris2.10   |
   Last reconfirmed|-00-00 00:00:00 |2005-05-31 16:52:32
   date||
Summary|Enable to build libfortran  |Unable to build libfortran
   |library |library


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

[Bug middle-end/21843] [4.1 Regression] gcc.c-torture/execute/920501-2.c execution fails

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

OtherBugsDependingO||21842
  nThis||


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

[Bug middle-end/21842] [4.1 Regression] 23_containers/bitset/operations/2.cc execution test fails

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-31 
16:50 ---
I want to say the same patch which broke 920501-2.c also broke this.

-- 
   What|Removed |Added

  BugsThisDependsOn||21843
  Component|libstdc++   |middle-end
   Keywords||wrong-code
   Target Milestone|--- |4.1.0


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