[Bug c++/17743] dependent expressions in attributes

[bkoz at redhat dot com]

--- Additional Comments From bkoz at redhat dot com  2004-10-19 06:23 ---
Subject: Re:  dependent expressions in attributes


>Yes, but how do you force the compiler to ensure that the alignment of char foo
>[] is sufficient to placement-allocate an object of type T into it?

...get __alignof__(T) working?

I don't see any other way, really. 

-benjamin


-- 


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

[Bug target/16482] [4.0 Regression] gcc.c-torture/unsorted/SFset.c fails with "-O2 -m4"

[sanjivkumargupta at yahoo dot com]

--- Additional Comments From sanjivkumargupta at yahoo dot com  2004-10-19 06:06 
---
Anyways, Kaz's method of determining pressure on R0 looks
more correct than what I had written. So, I think we
should keep his patch besides waiting for a fix in lcm.c

Thanks
--Sanjiv

-- 
   What|Removed |Added

 CC||sanjivkumargupta at yahoo
   ||dot com


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

[Bug target/16482] [4.0 Regression] gcc.c-torture/unsorted/SFset.c fails with "-O2 -m4"

[naveen dot sharma at noida dot hcltech dot com]

--- Additional Comments From naveen dot sharma at noida dot hcltech dot com  
2004-10-19 05:57 ---
(In reply to comment #6)
> > I am wondering why this was missed? Was R0 a
> > fixed_reg sometime during pre-3.3 
> > releases, so as to generate (mem (r0) (pesudo))
> > instead of (mem (pseudo) 
> > (pseudo) form?
> The first scheduler has has long been disabled for
> SH.

Thats OK, but the intent of my question was to ask
if internal RTL form has changed?

I will try to confirm your analysis for bug to be in 
lcm.c.

Thanks,
Naveen Sharma.

-- 


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

[Bug tree-optimization/14859] [tree-ssa] integrate identical cases of a switch statement.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19 04:29 
---
And I was right on the tree-cleanup-branch:
addi r3,r3,-14
subfic r3,r3,2
subfe r3,r3,r3
nand r3,r3,r3
andi. r3,r3,123
blr

-- 
   What|Removed |Added

   Target Milestone|--- |4.1.0


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

[Bug middle-end/18005] [4.0 Regression] ICE with simple loop with VLA

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19 04:14 
---
*** Bug 18052 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||phython at gcc dot gnu dot
   ||org


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

[Bug c/18052] segmentation fault compiling ffv1.c from ffmpeg

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19 04:14 
---
Reduces to the testcase in PR 18005 (it obvious does as it is a VLA and crashes in the 
same spot).

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c/18052] segmentation fault compiling ffv1.c from ffmpeg

[phython at gcc dot gnu dot org]

--- Additional Comments From phython at gcc dot gnu dot org  2004-10-19 04:10 
---
Created an attachment (id=7375)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7375&action=view)
small testcase


-- 


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

[Bug c/18052] New: segmentation fault compiling ffv1.c from ffmpeg

[phython at gcc dot gnu dot org]

ffv1.c doesn't compile with gcc 4.0 because cc1 segfaults trying to STRIP_NOPS
compiling the function encode_rgb_frame.

-- 
   Summary: segmentation fault compiling ffv1.c from ffmpeg
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: phython at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: ppc-linux
  GCC host triplet: ppc-linux
GCC target triplet: ppc-linux


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

[Bug target/18051] Internal compiler error in gen_lowpart

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19 03:31 
---
This is not an official FSF port, report the bug to the sourceforge project: .

-- 
   What|Removed |Added

   Severity|critical|normal
 Status|UNCONFIRMED |RESOLVED
  Component|c   |target
 Resolution||WONTFIX


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

[Bug c++/18049] wrong result without -O2 with g++-3.4.2 and completely wrong result with any other g++ version

[bangerth at dealii dot org]

--- Additional Comments From bangerth at dealii dot org  2004-10-19 02:18 ---
You are storing pointers to temporaries. Look here: 
- 
template 
class Constant 
{ 
  public: 
typedef T Type; 
 
  private: 
const T* value_; 
 
  public: 
 
Constant() 
  : value_(0) 
   {} 
 
explicit Constant(const T& value) 
: value_(&value) 
{} 
  ... 
- 
Note how you store the address of the value given to the constructor. 
Then you use class Constant here: 
- 
template 
inline 
FExpr< Mul > > 
operator*(const L& rleft, const typename L::Type& rright) 
{ 
  typedef typename L::Type Type; 
  typedef Mul > expr_t; 
  return FExpr(expr_t(rleft, Constant(rright))); 
} 
- 
so you pass the address of the second argument to this operator 
through to Constant. And you use this operator* in expressions 
like this: 
- 
  X_*2.0 
- 
in which you create a temporary of value 2 and pass it on to the result 
of the template expression. You later evaluate this expression 
template, but of course whatever is in the place where the 2.0 was stored 
is long gone and replaced by something different. 
 
The fact that it may have worked with optimization is just simple chance, 
or the compiler actually doing all the work of constant propagation for 
you. It is not a sign of a compiler bug, though. 
 
This PR is thus invalid. 
 
W. 

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c/18051] Internal compiler error in gen_lowpart

[get at cs dot berkeley dot edu]

--- Additional Comments From get at cs dot berkeley dot edu  2004-10-19 01:29 
---
Created an attachment (id=7374)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7374&action=view)
Preprocessed source that causes this bug


-- 


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

[Bug c/18051] New: Internal compiler error in gen_lowpart

[get at cs dot berkeley dot edu]

Here is the GCC version information, from msp430-gcc:

Reading specs from /cygdrive/c/mspgcc/bin/../lib/gcc-lib/msp430/3.2.3/specs
Configured with: ./configure --target=msp430 --
prefix=/c/daten/mspgcc/build/installed --disable-nls
Thread model: single
gcc version 3.2.3

This is the command line:

msp430-gcc -save-temps -v -B/usr/local/lib/ncc -mmcu=msp430x149 -Os -Wall -
Wshadow -v -o TestMgmtQuery.o -c -fdollars-in-identifiers build/telos/app.c

Here is the output:

Reading specs from /cygdrive/c/mspgcc/bin/../lib/gcc-lib/msp430/3.2.3/specs
Configured with: ./configure --target=msp430 --
prefix=/c/daten/mspgcc/build/installed --disable-nls
Thread model: single
gcc version 3.2.3
 /cygdrive/c/mspgcc/bin/../lib/gcc-lib/msp430/3.2.3/cpp0.exe -lang-c -v -
iprefix /cygdrive/c/mspgcc/bin/../lib/gcc-lib/msp430/3.2.3/ -
isystem /usr/local/lib/ncc/include -D__GNUC__=3 -D__GNUC_MINOR__=2 -
D__GNUC_PATCHLEVEL__=3 -D__GXX_ABI_VERSION=102 -DMSP430 -D__MSP430__ -
D__MSP430 -D__OPTIMIZE_SIZE__ -D__OPTIMIZE__ -D__STDC_HOSTED__=1 -
DMSP430_HAS_HW_MUL -D__MSP430_149__ -DMSP430_HAS_HWMUL -
D__SIZE_TYPE__=unsigned int -D__PTRDIFF_TYPE__=int -D__INT_MAX__=32767 
build/telos/app.c -Wall -Wshadow app.i
ignoring nonexistent directory "/usr/local/lib/ncc/include"
GNU CPP version 3.2.3 (cpplib) (GNU assembler syntax)
ignoring nonexistent directory "/cygdrive/c/mspgcc/msp430/sys-include"
ignoring nonexistent directory "/c/daten/mspgcc/build/installed/include"
ignoring nonexistent directory "/c/daten/mspgcc/build/installed/lib/gcc-
lib/msp430/3.2.3/include"
ignoring nonexistent directory "/c/daten/mspgcc/build/installed/lib/gcc-
lib/msp430/3.2.3/../../../../msp430/sys-include"
ignoring nonexistent directory "/c/daten/mspgcc/build/installed/lib/gcc-
lib/msp430/3.2.3/../../../../msp430/include"
#include "..." search starts here:
#include <...> search starts here:
 /cygdrive/c/mspgcc/lib/gcc-lib/msp430/3.2.3/include
 /cygdrive/c/mspgcc/msp430/include
End of search list.
 /cygdrive/c/mspgcc/bin/../lib/gcc-lib/msp430/3.2.3/cc1.exe -fpreprocessed 
app.i -quiet -dumpbase app.c -mmcu=msp430x149 -Os -Wall -Wshadow -version -
fdollars-in-identifiers -o app.s
GNU CPP version 3.2.3 (cpplib) (GNU assembler syntax)
GNU C version 3.2.3 (msp430)
compiled by GNU C version 3.3.1 (cygming special).

Here is the error:

C:/PROGRA~1/UCB/cygwin/opt/tinyos-
1.x/contrib/nucleus/tos/lib/Nucleus/MgmtQueryM.nc: In function `received':
C:/PROGRA~1/UCB/cygwin/opt/tinyos-
1.x/contrib/nucleus/tos/lib/Nucleus/MgmtQueryM.nc:122: Internal compiler error 
in gen_lowpart, at emit-rtl.c:1197
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

I will be attaching my .i file.

-- 
   Summary: Internal compiler error in gen_lowpart
   Product: gcc
   Version: 3.2.3
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: get at cs dot berkeley dot edu
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: i686-unknown-unknown
GCC target triplet: msp430


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

[Bug target/18010] bad unwind info due to multiple returns (missing epilogue)

[wilson at specifixinc dot com]

--- Additional Comments From wilson at specifixinc dot com  2004-10-19 01:07 
---
Subject: Re:  New: bad unwind info due to multiple
returns (missing epilogue)

On Fri, 2004-10-15 at 04:14, davidm at hpl dot hp dot com wrote:
> To fix this bug, GCC should be emitting a ".restore sp" directive in front of
> every instruction which pops the stack-pointer.

I'm still sick, four weeks and counting, but this looks like a pretty
easy one.  We just need to copy RTX_FRAME_RELATED_P when we copy
instructions.  The following patch gives the right result for the
testcase.  I have as yet done no other testing of the patch.

--- Additional Comments From wilson at specifixinc dot com  2004-10-19 01:07 
---
Created an attachment (id=7373)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7373&action=view)


-- 


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

[Bug c/17807] [4.0 Regression] No warning/error for undefined local function.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19 00:48 
---
I will see if I can have this rejected in the front-end.

-- 
   What|Removed |Added

   Keywords|patch   |


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

[Bug middle-end/17909] [4.0 Regression] ICE: verifiy_stms failed

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-19 00:46 
---
I am updating the patch per my suggestion and Jason asking for it.

-- 
   What|Removed |Added

   Keywords|patch   |


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

[Bug middle-end/18005] [4.0 Regression] ICE with simple loop with VLA

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-18 22:55 
---
It really has nothing to do with that patch we are losing the TYPE_SIZE of the VLA, 
why?

-- 
   What|Removed |Added

 CC||rth at gcc dot gnu dot org


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

[Bug tree-optimization/17757] [4.0 Regression] emptyif.f90

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-18 22:51 
---
Steven asked me to take care about the patch.

-- 
   What|Removed |Added

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


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

[Bug tree-optimization/18046] Missed jump threading optimization

[stevenb at suse dot de]

--- Additional Comments From stevenb at suse dot de  2004-10-18 22:50 ---
Subject: Re:  Missed jump threading optimization

Hmm, threading the default case sounds interesting, but the real
reason why the RTL threader catches this and the tree threader does
not is because on RTL the test case basically looks like this:

extern void foo (void);
extern int i;
void
bar (void)
{
  if (i == 0)
foo ();

  if (i == 0)
foo ();
}

Hey, I can thread that!  :-)

So perhaps we should consider lowering SWITCH_EXPRs with only two
targets to COND_EXPRs after all...?  That would be quite easy to
do.




-- 


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

[Bug middle-end/18045] [4.0 Regression] signed integer remainder for power of 2 broken

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-10-18 22:47 
---
See http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01571.html


-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c/18050] -Wsequence-point reports false positives

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-18 22:45 
---
Actually the patch will not work when we start warning about full expression, here is 
the patch just to 
give an example of what the final patch would look like:
Index: c-common.c
===

RCS file: /cvs/gcc/gcc/gcc/c-common.c,v
retrieving revision 1.578
diff -u -p -r1.578 c-common.c
--- c-common.c  16 Oct 2004 22:58:45 -  1.578
+++ c-common.c  18 Oct 2004 22:42:30 -
@@ -1358,6 +1358,16 @@ verify_tree (tree x, struct tlist **pbef
add_tlist (pno_sp, t->cache_after_sp, NULL_TREE, 1);
return;
   }
+
+case ADDR_EXPR:
+  {
+   x = TREE_OPERAND (x, 0);
+   if (DECL_P (x))
+ return;
+   writer = 0;
+   goto restart;
+  }
+  return;
 
 default:
   /* For other expressions, simply recurse on their operands.


Here is the test which I was taking about:
struct x
{
  int i;
};
void g(int, int *);
void f(struct x *y)
{
  g(y->i++, &y->i); /* {dg-bogus "undefined" } */
}

Here is another where we should warn:
struct x
{
  int i;
};
void g(int, int *);
void f(struct x *y)
{
  g((y++)->i, &y->i); /* { dg-warning "undefined" } */
}

-- 
   What|Removed |Added

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


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

[Bug middle-end/18045] [4.0 Regression] signed integer remainder for power of 2 broken

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-10-18 22:45 
---
Subject: Bug 18045

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-10-18 22:45:01

Modified files:
gcc: ChangeLog expmed.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.dg: smod-1.c 

Log message:
PR middle-end/18045
* expmed.c (expand_smod_pow2): Handle modes whose size
is greater than that of HOST_WIDE_INT.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.5940&r2=2.5941
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/expmed.c.diff?cvsroot=gcc&r1=1.198&r2=1.199
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4472&r2=1.4473
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/smod-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug target/18032] [4.0.0] SH: wrong code for EH

[kkojima at gcc dot gnu dot org]

--- Additional Comments From kkojima at gcc dot gnu dot org  2004-10-18 22:43 
---
I'm testing a patch you suggest with the usual bootstrap and
regression test.  I'll send it to gcc-patches if it passes.

--- ORIG/gcc/gcc/config/sh/sh.c 2004-10-08 07:46:30.0 +0900
+++ LOCAL/gcc/gcc/config/sh/sh.c2004-10-19 07:20:50.0 +0900
@@ -5828,6 +5828,10 @@ sh_expand_epilogue (bool sibcall_p)
 
   if (frame_pointer_needed)
 {
+  /* We must avoid scheduling the epilogue with previous basic blocks
+when exception handling is enabled.  See PR/18032.  */
+  if (flag_exceptions)
+   emit_insn (gen_blockage ());
   output_stack_adjust (frame_size, frame_pointer_rtx, e, &live_regs_mask);
 
   /* We must avoid moving the stack pointer adjustment past code


-- 


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

[Bug c/18050] -Wsequence-point reports false positives

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-18 22:35 
---
We cannot just ignore ADDR_EXPR outright though (this is undefined):
struct x
{
  int i;
};
void g(struct x*, int *);
void f(struct x *y)
{
  g(y++, &y->i);
}

I think I have a fix will test the fix.

-- 
   What|Removed |Added

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


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

[Bug c/18050] -Wsequence-point reports false positives

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-18 22:25 
---
Oh, you are right I need to look at the test more closely.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||diagnostic
   Last reconfirmed|-00-00 00:00:00 |2004-10-18 22:25:30
   date||


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

[Bug target/17990] [3.4/4.0 Regression] unaligned xmm movaps on the stack with -O2 -msse

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2004-10-18 22:24 
---
Uros, Jan, can you have a look at this bug? It's about an unaligned XMM 
operation to the stack. There is a small testcase and it is a pretty serious 
regression.

-- 
   What|Removed |Added

 CC||uros at kss-loka dot si,
   ||hubicka at gcc dot gnu dot
   ||org


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

gcc-bugs@gcc.gnu.org

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-18 22:17 
---
My patch is wrong, RTH is working on this now.

-- 
   What|Removed |Added

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


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

[Bug c/18050] -Wsequence-point reports false positives

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2004-10-18 22:15 
---
Uh? How can an increment operation change the address of a variable?

-- 
   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug tree-optimization/17757] [4.0 Regression] emptyif.f90

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-18 22:12 
---
Patch here:  which fixes it.

-- 
   What|Removed |Added

 CC||steven at gcc dot gnu dot
   ||org
   Keywords||patch


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

[Bug middle-end/17813] [4.0 regression] ada bootstrap failure on i486-linux

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-10-18 22:10 
---
See http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01562.html

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/17813] [4.0 regression] ada bootstrap failure on i486-linux

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-10-18 22:06 
---
Subject: Bug 17813

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-10-18 22:06:37

Modified files:
gcc: ChangeLog dojump.c expr.h explow.c 

Log message:
PR middle-end/17813
* dojump.c (discard_pending_stack_adjust): New function.
(clear_pending_stack_adjust): Call it.
* expr.h (discard_pending_stack_adjust): Declare it.
* explow.c (emit_stack_save): Emit pending stack adjustments
before saving the stack pointer.
(emit_stack_restore): Discard pending stack adjustments before
restoring the stack pointer.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.5938&r2=2.5939
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/dojump.c.diff?cvsroot=gcc&r1=1.29&r2=1.30
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/expr.h.diff?cvsroot=gcc&r1=1.171&r2=1.172
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/explow.c.diff?cvsroot=gcc&r1=1.139&r2=1.140



-- 


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

[Bug c/18050] -Wsequence-point reports false positives

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-18 22:01 
---
No the warning is correct. ++a could come before or after taking the address of a 
which is why this is 
undefined.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c/18050] New: -Wsequence-point reports false positives

[mitr at volny dot cz]

void f(int a, int *b) { *b = a; } void g(void) { int a = 5; f(++a, &a); }

with -Wall reports
t.c:1: warning: operation on `a' may be undefined.

This is with the following gcc versions:
[I realize they are all Red Hat versions, not official releases, but
I think that this happening on three different release branches
provides sufficient argument that this is very likely an upstream bug.]

Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --disable-libunwind-exceptions --with-system-zlib
--enable-__cxa_atexit --host=i386-redhat-linux
Thread model: posix
gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)

and

Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.1/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux
Thread model: posix
gcc version 3.4.1 20040831 (Red Hat 3.4.1-10)

and

Reading specs from /usr/lib/gcc/i386-redhat-linux/3.5.0/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --with-gxx-include-dir=/usr/include/c++/3.4.1
--enable-languages=c,c++,f99 --disable-libgcj --host=i386-redhat-linux
Thread model: posix
gcc version 3.5.0 20040818 (Red Hat 3.5.0-0.9)

-- 
   Summary: -Wsequence-point reports false positives
   Product: gcc
   Version: 3.3.3
Status: UNCONFIRMED
  Severity: minor
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mitr at volny dot cz
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/18049] wrong result without -O2 with g++-3.4.2 and completely wrong result with any other g++ version

[bangerth at dealii dot org]

--- Additional Comments From bangerth at dealii dot org  2004-10-18 21:22 ---
I'm working on a reduced testcase. I'll have to leave now but will report 
back when I'm back online later tonight. 
 
W. 

-- 


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

[Bug c++/18049] wrong result without -O2 with g++-3.4.2 and completely wrong result with any other g++ version

[bangerth at dealii dot org]

--- Additional Comments From bangerth at dealii dot org  2004-10-18 20:32 ---
Actually, the typedef has nothing to do with it. Here's a modified FEMmain.cc 
file: 
- 
#include  
#include "Elements.h" 
 
int main() 
{ 
  Container2D Vec(6,6,1.0); 
  FiniteElement SP2(&Vec); 
  Mesh mesh; 
  AssemblyTerm<0, Simplex, _2D, P2> u(mesh, &Vec); 
  AssemblyTerm<0, Simplex, _2D, P2> v(mesh, &Vec); 
 
  // Give Vec its final values 
  for (size_t i = 0; i < 6; i++) 
for (unsigned int j=0; j<6; ++j) 
  Vec[j][i] += j; 
 
  R x = 1.0; 
  R y = 0.0; 
  R z = 2.0; 
 
  AssemblyTerm<1, Simplex, _2D, P2> vdx(mesh, &Vec); 
  std::cout << "Before:  " << vdx(0,x,y,z) << "\n"; 
  std::cout << "After:   " << vdx(0,x,y,z) << "\n"; 
} 
-- 
The typedef is gone, and I output only the first element. What I get is this: 
 
g/x> /home/bangerth/bin/gcc-3.4.3-pre/bin/c++ *.cc -o x ; ./x 
Before:  3 
After:   -0.994019 
 
In other words, the output changes if I call the same function vdx(0,x,y,z) 
twice. I will have to see what's going on in the function. 
 
W. 

-- 


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

[Bug c++/18049] wrong result without -O2 with g++-3.4.2 and completely wrong result with any other g++ version

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-18 20:31 
---
Also I cannot compile this on ppc-darwin because you are using _X which is in the 
reserved 
identifier space for implementors (darwin defines it to be something).

-- 


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

[Bug c++/18049] wrong result without -O2 with g++-3.4.2 and completely wrong result with any other g++ version

[bangerth at dealii dot org]

--- Additional Comments From bangerth at dealii dot org  2004-10-18 20:24 ---
Just for the reference, here's what I get: 
 
g/x> /home/bangerth/bin/gcc-3.4.3-pre/bin/c++ *.cc -o x ; ./x 
*** Before Declaration of typedef *** 
3 
-1.98746 
12.1079 
16.1439 
20.1799 
24.2159 
*** After Declaration of typedef *** 
1 
-1.98746 
12.1079 
16.1439 
20.1799 
24.2159 
*** What the result should be *** 
3 
6 
9 
12 
15 
18 
 
g/x> /home/bangerth/bin/gcc-3.4.3-pre/bin/c++ -O2 *.cc -o x ; ./x 
*** Before Declaration of typedef *** 
3 
6 
9 
12 
15 
18 
*** After Declaration of typedef *** 
3 
6 
9 
12 
15 
18 
*** What the result should be *** 
3 
6 
9 
12 
15 
18 
 
 
With -O2, the change in result is obvious. In the first data set (no -O2), 
the first line of the *before* and *after* markers is different. 
 
 
Drosos: we're not particularly fond of these larger multi-file testcases. 
Do you think you could come up with a smaller testcase that is in only 
one file? 
W. 

-- 


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

[Bug c++/18049] wrong result without -O2 with g++-3.4.2 and completely wrong result with any other g++ version

[dkouroun at mailbox dot gr]

--- Additional Comments From dkouroun at mailbox dot gr  2004-10-18 20:07 ---
Created an attachment (id=7371)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7371&action=view)
source code(important files: FEMmain.cc, Elements.h )

This is the source code. It uses expression templates.
typedef typeof(dx(u)*dx(v)) dxType
dxType A = dx(u)*dx(v) influences the output of an object 
which has nothing to do with A;


-- 


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

[Bug c++/18049] New: wrong result without -O2 with g++-3.4.2 and completely wrong result with any other g++ version

[dkouroun at mailbox dot gr]

Only g++-3.4.2 performs well and gives correct results if and only if it is
compiled with -O2. 
Basically dx function takes an argument of type
***AssemblyTerm<0, Simplex, _2D, P2>,***
and returns 
***AssemblyTerm<1, Simplex, _2D, P2>.*** 
Then in the main I declare

AssemblyTerm<0, Simplex, _2D, P2> v(mesh, &Vec);
and
AssemblyTerm<1, Simplex, _2D, P2> vdx(mesh, &Vec);
just to compare the output of dx(v)(i,x,y,z) with
vdx(i,x,y,z) which should both give the same result.

Unfortunately although the output is the same (only with g++ --all versions--
-O2) before the declaration of

typedef typeof(dx(u)*dx(v)) dxType;
dxType A=dx(u)*dx(v);

after that declaration the output changes; I do not
know for what reason. g++-3.4.2 has no problem if with(-O2) but the other
compilers fail to give correct result when we do not comment out 
the typedef declaration.

-- 
   Summary: wrong result without -O2 with g++-3.4.2 and completely
wrong result with any other g++ version
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P1
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dkouroun at mailbox dot gr
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: GCC-4.0-20041017
  GCC host triplet: GCC-3.3.1 SuSE Linux 9.0


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

[Bug middle-end/16973] [4.0 Regression] Differences between addresses of labels broken

[pinskia at gcc dot gnu dot org]

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

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/16973] [4.0 Regression] Differences between addresses of labels broken

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-10-18 19:38 
---
Subject: Bug 16973

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-10-18 19:38:47

Modified files:
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.dg: pr16973.c 

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

PR middle-end/16973
* gcc.dg/pr16973.c: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4469&r2=1.4470
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr16973.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug middle-end/16973] [4.0 Regression] Differences between addresses of labels broken

[pinskia at gcc dot gnu dot org]

-- 
Bug 16973 depends on bug 15014, which changed state.

Bug 15014 Summary: [4.0 regression] labels after are removed even though they are used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15014

   What|Old Value   |New Value

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

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

[Bug middle-end/15014] [4.0 regression] labels after are removed even though they are used

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-18 19:30 
---
Fixed, since the testcases are already there, there is no need to apply any more.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/15014] [4.0 regression] labels after are removed even though they are used

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-10-18 19:29 
---
Subject: Bug 15014

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-10-18 19:29:53

Modified files:
gcc: ChangeLog tree-cfg.c 

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

PR middle-end/15014
PR middle-end/16973
* tree-cfg.c (remove_bb): If we have a label expression in the
basic block and the label we have taken the address, move the
label expression to the basic block which is previous in the
linked list.
(tree_verify_flow_info): Fix printing out the label name of the
problematic label expression.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.5932&r2=2.5933
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-cfg.c.diff?cvsroot=gcc&r1=2.79&r2=2.80



-- 


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

[Bug middle-end/16973] [4.0 Regression] Differences between addresses of labels broken

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-10-18 19:29 
---
Subject: Bug 16973

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-10-18 19:29:53

Modified files:
gcc: ChangeLog tree-cfg.c 

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

PR middle-end/15014
PR middle-end/16973
* tree-cfg.c (remove_bb): If we have a label expression in the
basic block and the label we have taken the address, move the
label expression to the basic block which is previous in the
linked list.
(tree_verify_flow_info): Fix printing out the label name of the
problematic label expression.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.5932&r2=2.5933
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-cfg.c.diff?cvsroot=gcc&r1=2.79&r2=2.80



-- 


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

[Bug tree-optimization/18048] [4.0 Regression] mgrid loop performance regression with ivopts

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 CC||rakdver at gcc dot gnu dot
   ||org
   Keywords||missed-optimization
Summary|mgrid loop performance  |[4.0 Regression] mgrid loop
   |regression with ivopts  |performance regression with
   ||ivopts
   Target Milestone|--- |4.0.0


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

[Bug tree-optimization/18048] New: mgrid loop performance regression with ivopts

[dje at gcc dot gnu dot org]

172.mgrid performance degraded after ivopts were introduced.  The patch to 
improve iv selection did not improve the performance.  This is separate from 
the register pressure problems.  The tree loop optimization appears to be 
leaving unnecessary computations in loops.

-- 
   Summary: mgrid loop performance regression with ivopts
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dje at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: *-*-*
  GCC host triplet: *-*-*
GCC target triplet: *-*-*


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

[Bug c++/17743] dependent expressions in attributes

[bkoz at gcc dot gnu dot org]

--- Additional Comments From bkoz at gcc dot gnu dot org  2004-10-18 18:57 ---
Giovanni, this is applicable to TR1 via 

4.5.5 Other transformations [tr.meta.trans.other] template  struct aligned_storage { typedef unspecified type ; }; 1
type: an implementation defined POD type with size Len and alignment Align, and
suitable for use as uninitialized storage for any object of a type whose size is
Len and whose alignment is Align.

-- 


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

[Bug rtl-optimization/18002] [3.4/4.0 Regression] 'while' loop performace regression on avr target

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-10-18 18:47 
---
Subject: Bug 18002

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-10-18 18:47:40

Modified files:
gcc: ChangeLog 

Log message:
Note PR rtl-optimization/18002.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.5931&r2=2.5932



-- 


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

[Bug c++/18047] [4.0 Regression] Wrong precedence between equality (==, !=) and < operators

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-18 18:36 
---
Paolo since now I have been convinced that your patch caused this regression, could 
you look into it?

-- 
   What|Removed |Added

 CC||bonzini at gcc dot gnu dot
   ||org


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

[Bug regression/17919] [4.0 Regression] ICE at cgraphunit.c:2907

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

Summary|[4.0 Regression] ICE at |[4.0 Regression] ICE at
   |/cgraphunit.c:2907  |cgraphunit.c:2907


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

[Bug middle-end/17967] [4.0 Regression] Expand is considered slower? (remove_useless_stmts is considered part of expand)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-18 18:31 
---
I am testing a new patch which this time I fully tested it (it only removes the 
fold_stmt from the 
COND_EXPR as that is not needed at all).

-- 


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

[Bug tree-optimization/18046] Missed jump threading optimization

[law at redhat dot com]

--- Additional Comments From law at redhat dot com  2004-10-18 18:31 ---
Subject: Re:  Missed jump threading
optimization

On Mon, 2004-10-18 at 11:30, steven at gcc dot gnu dot org wrote:
> --- Additional Comments From steven at gcc dot gnu dot org  2004-10-18 17:30 
> ---
> Diego told me to bug Law.  Obedient as I always am, I hereby 
> do so :-) 
>  
> Jeff, this is a missed jump threading opportunity, the default 
> case can be threaded here.  Any ideas how to fix this? 
I don't see a good way to fix this.  There's lots of interconnected
issues that would need to be addressed.

Clearly we need better range information so that we can determine
that i != 0 on the default case leaving the first switch statement
(or we would need to avoid collapsing empty cases to the default
label until expansion).

Second, we need to rewrite the jump threading selection code; that's
on the queue.  Specifically we need to drop the requirement that
the statements at the start of the intermediate block are nops.
The SSA update code is already prepared to handle this change, so
it really ought to be isolated in the jump threading selection
code.


Given those two improvements we'd have a chance of threading the
default case out of the first switch statement.

jeff





-- 


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

[Bug tree-optimization/17656] [4.0 Regression] internal compiler error: in replace_immediate_uses, at tree-ssa.c:1041

[dnovillo at gcc dot gnu dot org]

--- Additional Comments From dnovillo at gcc dot gnu dot org  2004-10-18 18:05 
---
Fix: http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01502.html

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/17656] [4.0 Regression] internal compiler error: in replace_immediate_uses, at tree-ssa.c:1041

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-10-18 17:39 
---
Subject: Bug 17656

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-10-18 17:39:47

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

Log message:
PR tree-optimization/17656
* tree-ssa.c (replace_immediate_uses): When replacing a
constant, if the call to fold_stmt produced a different
statement, get an appropriate statement pointer by scanning
STMT's basic block.

PR tree-optimization/17656
* testsuite/gcc.c-torture/compile/pr17656.c: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.5928&r2=2.5929
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa.c.diff?cvsroot=gcc&r1=2.47&r2=2.48
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4468&r2=1.4469
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/pr17656.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug tree-optimization/17841] table lookups vs binary search in switch-statements

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-18 17:32 
---
We already get much better code on the mainline for this testcase as the constant for 
x is progated into 
the case statements so we only get the storing of the value into g.
I have a fix for 4.x, there is an off by one error in the loop to combine the case and 
the default case.

-- 
   What|Removed |Added

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


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

[Bug tree-optimization/18046] Missed jump threading optimization

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-10-18 17:30 
---
Diego told me to bug Law.  Obedient as I always am, I hereby 
do so :-) 
 
Jeff, this is a missed jump threading opportunity, the default 
case can be threaded here.  Any ideas how to fix this? 

-- 
   What|Removed |Added

 CC||law at redhat dot com


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

[Bug c++/16564] g++ seems to go into an infinite loop after errors

[bangerth at dealii dot org]

--- Additional Comments From bangerth at dealii dot org  2004-10-18 17:14 ---
Ah, never mind. I had misread my own example in that I thought that the 
instantiation of S only required instantiation of A, but in 
fact it also requires S > which requires S > >, etc, so we 
do have in fact an infinite list of instantiations. 
 
In that case, I don't even know whether we should consider this a bug: I 
would say the compiler is clearly doing something useful with your testcase 
(and with mine as well) in that it tries to go down the list of instantiations 
that the code clearly prescribes. Your testcase has no problem except the 
infinite list of instantiations, so there isn't very much the compiler can 
do differently apart from throttling the limit somewhat. 
 
So, what are we supposed to do? As mentioned in the patch you cite, 
-ftemplate-depth-50 is not enough, so 500 seems a reasonable choice.  
What value would you suggest instead? 
 
W. 

-- 


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

[Bug other/17464] The newly built gcc shared libraries aren't used for bootstap and check

[pinskia at gcc dot gnu dot org]

-- 
Bug 17464 depends on bug 17684, which changed state.

Bug 17684 Summary: [3.4/4.0 Regression] /usr/ccs/bin/ld: Can't create libgcc_s.sl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17684

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug bootstrap/17684] [3.4/4.0 Regression] /usr/ccs/bin/ld: Can't create libgcc_s.sl

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-18 17:00 
---
Fixed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/17529] [4.0 Regression] ICE in get_indirect_ref_operands

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2004-10-18 16:48 
---
Looks like you reverted the patch but not the testcase which now fails.

-- 


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

[Bug c++/17743] dependent expressions in attributes

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2004-10-18 16:38 
---
(In reply to comment #15)

> I guess I don't see why/how alignof should be different than sizeof
> here (which works):
>  template 
>  struct A 
>  {
>char foo[sizeof(T)];
>  };

Yes, but how do you force the compiler to ensure that the alignment of char foo
[] is sufficient to placement-allocate an object of type T into it?


-- 


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

[Bug java/17845] can't build GNU Classpath

[aph at gcc dot gnu dot org]

--- Additional Comments From aph at gcc dot gnu dot org  2004-10-18 16:13 ---
I can't duplicate this problem, nor can anyone else duplicate it on any machine
to which I have access.


-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||WORKSFORME


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

[Bug rtl-optimization/17752] Hot/cold basic block partitioning optimization has problems

[ctice at apple dot com]

--- Additional Comments From ctice at apple dot com  2004-10-18 16:06 ---
Subject: Re:  Hot/cold basic block partitioning optimization has problems


Actually, I had some private communication with Zack Weinberg, Mark  
Mitchell, and Richard
Henderson about the hot/cold patches.  The decision was that these are  
too intrusive to go
into stage 3, so I created a branch ('hot-cold-branch') to hold onto  
the patches until
stage 1 opens up again.

Thanks for  pursuing this Andrew.

--  Caroline Tice
[EMAIL PROTECTED]

On Oct 17, 2004, at 9:21 PM, pinskia at gcc dot gnu dot org wrote:

>
> --- Additional Comments From pinskia at gcc dot gnu dot org   
> 2004-10-18 04:21 ---
> I pinged them, hopefully someone will look into them soon :).
>
> --  
>What|Removed |Added
> --- 
> -
>Target Milestone|--- |4.0.0
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17752
>
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.



-- 


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

[Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding

[bkorb at veritas dot com]

--- Additional Comments From bkorb at veritas dot com  2004-10-18 16:06 ---
Subject: Re:  Bug in vendor /usr/include/net/if.h needs
fixincluding

skunk at iskunk dot org wrote:
> 
> --- Additional Comments From skunk at iskunk dot org  2004-10-18 15:16 ---
> The build still fails ...


  /*
+  *  Fix missing semicolon on Alpha OSF/4 in 
+  */
+ fix = {
+ hackname  = alpha_if_semicolon;
+ files = "if.h";
+ select= "(struct[ \t]+sockaddr[ \t]+vmif_paddr)([ \t])([ \t]+/\*)";
+ c_fix = format;
+ c_fix_arg = "%1;%2%3";
+ test_text = ' struct  sockaddr vmif_paddr /* protocol address */';
+ };
+ 
+ 
+ /*
   * Remove erroneous parentheses in sym.h on Alpha OSF/1.
   */
  fix = {

The select clause requires two white space characters
between "vmif_paddr" and "/*".  Eliminate the unnecessary
subexpression stuff, thus:

  /*
+  *  Fix missing semicolon on Alpha OSF/4 in 
+  */
+ fix = {
+ hackname  = alpha_if_semicolon;
+ files = "if.h";
+ select= "struct[ \t]+sockaddr[ \t]+vmif_paddr[ \t]+/\*";
+ c_fix = format;
+ c_fix_arg = "struct sockaddr vmif_paddr;\t/*";
+ test_text = ' struct  sockaddr vmif_paddr /* protocol address */';
+ };


-- 


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

[Bug c++/16564] g++ seems to go into an infinite loop after errors

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2004-10-18 16:04 
---
I don't quite agree.
The error about the hosed typedef is issued almost at once by the compiler.
But since the compiler doesn't give up after the first error, it tries
to instantiate the template without the broken typedef. That's what takes
ages and what can be demonstrated with my reduced example.


-- 


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

[Bug bootstrap/17684] [3.4/4.0 Regression] /usr/ccs/bin/ld: Can't create libgcc_s.sl

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-10-18 16:01 
---
Subject: Bug 17684

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED]   2004-10-18 16:00:53

Modified files:
gcc: ChangeLog Makefile.in mklibgcc.in 
gcc/config : t-libunwind-elf t-slibgcc-darwin 
 t-slibgcc-elf-ver t-slibgcc-sld 
gcc/config/alpha: t-osf4 
gcc/config/arm : t-netbsd 
gcc/config/mips: t-iris5-6 
gcc/config/pa  : t-hpux-shlib 
gcc/config/sh  : t-linux 

Log message:
2004-11-18  H.J. Lu  <[EMAIL PROTECTED]>

PR bootstrap/17684
* Makefile.in (clean): Remove libgcc_s$(SHLIB_EXT).1.stage?.
(stage1-start): Remove and copy libunwind.a and
libunwind*$(SHLIB_EXT) instead of libunwind*.
(stage2-start): Likewise.
(stage3-start): Likewise.
(stage4-start): Likewise.
(stageprofile-start): Likewise.
(stagefeedback-start): Likewise.

* config/alpha/t-osf4 (SHLIB_LINK): Use a temporary file for
the shared library to be created and don't remove the existing
shared library.
* config/arm/t-netbsd (SHLIB_LINK): Likewise.
* config/mips/t-iris5-6 (SHLIB_LINK): Likewise.
* config/pa/t-hpux-shlib (SHLIB_LINK): Likewise.
* config/sh/t-linux (SHLIB_LINK): Likewise.
* config/t-libunwind-elf (SHLIBUNWIND_LINK): Likewise.
* config/t-slibgcc-darwin (SHLIB_LINK): Likewise.
* config/t-slibgcc-elf-ver (SHLIB_LINK): Likewise.
* config/t-slibgcc-sld (SHLIB_LINK): Likewise.

* mklibgcc.in (libgcc-stage-start): Also move "*${objext}s"
files.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.665&r2=2.2326.2.666
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/Makefile.in.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.1223.2.19&r2=1.1223.2.20
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/mklibgcc.in.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.67.4.2&r2=1.67.4.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/t-libunwind-elf.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.1.4.1&r2=1.1.4.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/t-slibgcc-darwin.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.2&r2=1.2.10.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/t-slibgcc-elf-ver.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.5.20.1&r2=1.5.20.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/t-slibgcc-sld.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.4&r2=1.4.20.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/alpha/t-osf4.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.7&r2=1.7.10.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/arm/t-netbsd.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.7&r2=1.7.10.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/mips/t-iris5-6.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3&r2=1.3.20.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/pa/t-hpux-shlib.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.2&r2=1.2.20.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/sh/t-linux.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.9.10.2&r2=1.9.10.3



-- 


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

[Bug bootstrap/17684] [3.4/4.0 Regression] /usr/ccs/bin/ld: Can't create libgcc_s.sl

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-10-18 15:53 
---
Subject: Bug 17684

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-10-18 15:52:52

Modified files:
gcc: ChangeLog Makefile.in mklibgcc.in 
gcc/config : t-libunwind-elf t-slibgcc-darwin 
 t-slibgcc-elf-ver t-slibgcc-sld 
gcc/config/alpha: t-osf4 
gcc/config/arm : t-netbsd 
gcc/config/i386: t-nwld 
gcc/config/mips: t-slibgcc-irix 
gcc/config/pa  : t-hpux-shlib 
gcc/config/sh  : t-linux 

Log message:
2004-11-18  H.J. Lu  <[EMAIL PROTECTED]>

PR bootstrap/17684
* Makefile.in (clean): Remove libgcc_s$(SHLIB_EXT).1.stage?.
(stage1-start): Remove and copy libunwind.a and
libunwind*$(SHLIB_EXT) instead of libunwind*.
(stage2-start): Likewise.
(stage3-start): Likewise.
(stage4-start): Likewise.
(stageprofile-start): Likewise.
(stagefeedback-start): Likewise.

* config/alpha/t-osf4 (SHLIB_LINK): Use a temporary file for
the shared library to be created and don't remove the existing
shared library.
* config/arm/t-netbsd (SHLIB_LINK): Likewise.
* config/i386/t-nwld (SHLIB_LINK): Likewise.
* config/mips/t-slibgcc-irix (SHLIB_LINK): Likewise.
* config/pa/t-hpux-shlib (SHLIB_LINK): Likewise.
* config/sh/t-linux (SHLIB_LINK): Likewise.
* config/t-libunwind-elf (SHLIBUNWIND_LINK): Likewise.
* config/t-slibgcc-darwin (SHLIB_LINK): Likewise.
* config/t-slibgcc-elf-ver (SHLIB_LINK): Likewise.
* config/t-slibgcc-sld (SHLIB_LINK): Likewise.

* mklibgcc.in (libgcc-stage-start): Also move "*${objext}s"
files.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.5925&r2=2.5926
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/Makefile.in.diff?cvsroot=gcc&r1=1.1412&r2=1.1413
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/mklibgcc.in.diff?cvsroot=gcc&r1=1.71&r2=1.72
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/t-libunwind-elf.diff?cvsroot=gcc&r1=1.1&r2=1.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/t-slibgcc-darwin.diff?cvsroot=gcc&r1=1.3&r2=1.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/t-slibgcc-elf-ver.diff?cvsroot=gcc&r1=1.7&r2=1.8
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/t-slibgcc-sld.diff?cvsroot=gcc&r1=1.5&r2=1.6
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/alpha/t-osf4.diff?cvsroot=gcc&r1=1.7&r2=1.8
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/arm/t-netbsd.diff?cvsroot=gcc&r1=1.7&r2=1.8
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/t-nwld.diff?cvsroot=gcc&r1=1.1&r2=1.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/mips/t-slibgcc-irix.diff?cvsroot=gcc&r1=1.1&r2=1.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/pa/t-hpux-shlib.diff?cvsroot=gcc&r1=1.2&r2=1.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/sh/t-linux.diff?cvsroot=gcc&r1=1.13&r2=1.14



-- 


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

[Bug c++/18047] [4.0 Regression] Wrong precedence between equality (==, !=) and < operators

[bangerth at dealii dot org]

--- Additional Comments From bangerth at dealii dot org  2004-10-18 15:50 ---
Well, in any case it's definitely a critical regression! 
W. 

-- 
   What|Removed |Added

   Severity|normal  |critical


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

[Bug target/18032] [4.0.0] SH: wrong code for EH

[amylaar at gcc dot gnu dot org]

--- Additional Comments From amylaar at gcc dot gnu dot org  2004-10-18 15:49 
---
We don't emit call frame information for the epilogue.  If we did, than any
basic blocks that happen to come after the epilogue due to block reordering
would end up with incorrect cfi information, since we don't have any machinery
for writing compensating cfi when we skip over an epilogue.

Thus, the only way we have to make this work with the current infrastructure
is to avoid scheduling the epilogue with previous basic blocks when exception
handling is enabled (this also affects debugging information, but I'd say we
shouldn't pessimize -O2 code to get better debugging information).

There is already code in sh.c:sh_expand_epilogue to emit a blockage instruction
before the stack adjustments.  However, if a frame pointer is needed, the
initial adjustment of the frame pointer isn't adjusted, since this doesn't
matter for interrupts:
 
  if (frame_pointer_needed)
{
  output_stack_adjust (frame_size, frame_pointer_rtx, e, &live_regs_mask);

  /* We must avoid moving the stack pointer adjustment past code
 which reads from the local frame, else an interrupt could
 occur after the SP adjustment and clobber data in the local
 frame.  */
  emit_insn (gen_blockage ());
  emit_insn (GEN_MOV (stack_pointer_rtx, frame_pointer_rtx));
}

So, if flag_exceptions is set, we should emit this blockage before the frame
pointer adjustment.

-- 
   What|Removed |Added

 CC||amylaar at gcc dot gnu dot
   ||org


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

[Bug c++/16564] g++ seems to go into an infinite loop after errors

[bangerth at dealii dot org]

--- Additional Comments From bangerth at dealii dot org  2004-10-18 15:47 ---
I think your testcase isn't very good. After all, you really try to 
instantiate A>> and the compiler only gives up after its 
500 nested instantiations. Your testcase is really badly constructed 
since it necessarily requires the 500 instantiations, whereas mine 
from comment #3 only requires 2 or so (a finite number if the instantiation 
depth would be infinite, whereas yours is really infinite). 
 
W. 

-- 


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

[Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding

[skunk at iskunk dot org]

--- Additional Comments From skunk at iskunk dot org  2004-10-18 15:16 ---
The build still fails with the patched inclhack.def (same error, same place).
fixincludes does not appear to have patched the header in question; there is no
if.h present in the build tree.

-- 


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

[Bug target/16482] [4.0 Regression] gcc.c-torture/unsorted/SFset.c fails with "-O2 -m4"

[joern dot rennecke at superh-support dot com]

--- Additional Comments From joern dot rennecke at superh-support dot com  
2004-10-18 15:16 ---
Subject: Re:  [4.0 Regression] gcc.c-torture/unsorted/SFset.c fails with "-O2 -m4"

> The patch submitted by Kaz looks OK to me.

The bug is in lcm.c, so it should be fixed there.

> I am wondering why this was missed? Was R0 a
> fixed_reg sometime during pre-3.3 
> releases, so as to generate (mem (r0) (pesudo))
> instead of (mem (pseudo) 
> (pseudo) form?

The first scheduler has has long been disabled for
SH.


-- 


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

[Bug tree-optimization/17656] [4.0 Regression] internal compiler error: in replace_immediate_uses, at tree-ssa.c:1041

[dnovillo at gcc dot gnu dot org]

--- Additional Comments From dnovillo at gcc dot gnu dot org  2004-10-18 15:13 
---

Testing patch.

-- 


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

[Bug c++/18047] [4.0 Regression] Wrong precedence between equality (==, !=) and < operators

[zack at codesourcery dot com]

--- Additional Comments From zack at codesourcery dot com  2004-10-18 15:02 ---
Subject: Re:  [4.0 Regression] Wrong precedence between equality (==, !=) and < 
operators


I doubt that.  I'd be inclined to point fingers at the
operator-precedence parser patch, myself.

zw


-- 


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

[Bug libgcj/18036] Bad interaction between interpreter and Class.forName()

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-18 14:39 
---
Fixed.

-- 
   What|Removed |Added

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


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

[Bug libgcj/18036] Bad interaction between interpreter and Class.forName()

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-10-18 14:26 
---
Subject: Bug 18036

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcj-abi-2-dev-branch
Changes by: [EMAIL PROTECTED]   2004-10-18 14:26:27

Modified files:
libjava: ChangeLog interpret.cc 
libjava/gnu/gcj/runtime: natStackTrace.cc 

Log message:
2004-10-18  Andrew Haley  <[EMAIL PROTECTED]>

PR java/18036:
* gnu/gcj/runtime/natStackTrace.cc (fillInStackTrace): Reorganize
and correct logic used to find interpreter.

2004-10-13  Andrew Haley  <[EMAIL PROTECTED]>

* interpret.cc (_Jv_InterpMethod::run): Initialize
_Jv_StartOfInterpreter.
(_Jv_StartOfInterpreter, _Jv_EndOfInterpreter): Functions removed.
(_Jv_StartOfInterpreter, _Jv_EndOfInterpreter): New variables.
* gnu/gcj/runtime/natStackTrace.cc (fillInStackTrace): Use
_Unwind_FindEnclosingFunction to discover whether PC is within the
interpreter.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcj-abi-2-dev-branch&r1=1.2729.2.37&r2=1.2729.2.38
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/interpret.cc.diff?cvsroot=gcc&only_with_tag=gcj-abi-2-dev-branch&r1=1.40.18.7&r2=1.40.18.8
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/gnu/gcj/runtime/natStackTrace.cc.diff?cvsroot=gcc&only_with_tag=gcj-abi-2-dev-branch&r1=1.6&r2=1.6.20.1



-- 


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

gcc-bugs@gcc.gnu.org

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-18 14:25 
---
Patch here: .

-- 
   What|Removed |Added

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


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

[Bug libgcj/18036] Bad interaction between interpreter and Class.forName()

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-10-18 14:07 
---
Subject: Bug 18036

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-10-18 14:07:42

Modified files:
libjava: ChangeLog 
libjava/gnu/gcj/runtime: natStackTrace.cc 

Log message:
2004-10-18  Andrew Haley  <[EMAIL PROTECTED]>

PR java/18036:
* gnu/gcj/runtime/natStackTrace.cc (fillInStackTrace): Reorganize
and correct logic used to find interpreter.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&r1=1.3137&r2=1.3138
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/gnu/gcj/runtime/natStackTrace.cc.diff?cvsroot=gcc&r1=1.7&r2=1.8



-- 


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

[Bug middle-end/17549] [4.0 Regression] 15% increase in codesize with C code

[dberlin at dberlin dot org]

--- Additional Comments From dberlin at dberlin dot org  2004-10-18 14:06 ---
Subject: Re:  [4.0 Regression] 15% increase in codesize with C code


On Oct 18, 2004, at 9:55 AM, giovannibajo at libero dot it wrote:

>
> --- Additional Comments From giovannibajo at libero dot it  
> 2004-10-18 13:55 ---
> Yes, also on x86, we save approx 2k:
>
> 212134.0.0 -Os
> 191584.0.0 -Os -fno-tree-pre
> 184664.0.0 -Os -fno-tree-pre -fno-ivopts
> 201724.0.0 -Os -fno-ivopts
> 179713.4.1 -Os
>
> Daniel?

Tree PRE (but not FRE)  should probably be disabled at -Os, since it 
will replicate code for speed reasons.
I'm happy to accept a patch to do this, it should be a  simple setting 
of flag_tree_pre to 0 when -Os is turned on.



-- 


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

[Bug c++/18047] [4.0 Regression] Wrong precedence between equality (==, !=) and < operators

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-18 14:06 
---
Confirmed, the regression showed up on 2004-09-23 (between 01:40:01 and 16:10:02 
EST/EDT).
Since this effects only the C++ front-end, the patch which looks the most likely is:
2004-09-23  Zack Weinberg  <[EMAIL PROTECTED]>

* decl.c (grokfndecl): If ::main is found not to return int,
correct it after issuing a diagnostic.
(grokdeclarator): If the incoming type was error_mark_node, do
not complain about declaring something with no type.
(start_function): Change check for ::main not returning int to
an assertion, as grokfndecl now catches this when the user did it.
* init.c (perform_member_init, sort_mem_initializers)
(emit_mem_initializers): Make most diagnostics be issued on
the line of current_function_decl, not whatever the current
input line is.
.



-- 
   What|Removed |Added

 CC||zack at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||wrong-code
  Known to fail||4.0.0
  Known to work||3.4.0
   Last reconfirmed|-00-00 00:00:00 |2004-10-18 14:06:18
   date||
Summary|Wrong precedence between|[4.0 Regression] Wrong
   |equality (==, !=) and < |precedence between equality
   |operators   |(==, !=) and < operators
   Target Milestone|--- |4.0.0


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

[Bug middle-end/17549] [4.0 Regression] 15% increase in codesize with C code

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2004-10-18 13:55 
---
Yes, also on x86, we save approx 2k:

212134.0.0 -Os
191584.0.0 -Os -fno-tree-pre
184664.0.0 -Os -fno-tree-pre -fno-ivopts
201724.0.0 -Os -fno-ivopts
179713.4.1 -Os

Daniel?

-- 
   What|Removed |Added

 CC||dberlin at gcc dot gnu dot
   ||org


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

[Bug c++/18047] New: Wrong precedence between equality (==, !=) and < operators

[veksler at il dot ibm dot com]

gcc-4.0 gives operator== higher precedence than operator<, which is against
5.10 paragraph 1:
  "Note: ahttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=18047

[Bug middle-end/18045] [4.0 Regression] signed integer remainder for power of 2 broken

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-10-18 13:44 
---
Thanks for confirming (I think -mtune=i486 is sufficient).  Patch in testing.

-- 
   What|Removed |Added

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


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

[Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2004-10-18 13:37 
---
Subject: Re:  Bug in vendor /usr/include/net/if.h needs   fixincluding

Bruce Korb wrote:

>> I can only fix things about which I get feedback so it
>> incrementally gets better.  I'm sorry you found it difficult.

Sure, I did not want to sound offensive.


>> Also, it does not explain if it is possible (and how) to use the
>> test_text to
>> verify the correctness of the fix. When I run 'make check' I don't
>> understand
>> if my new hack is being tested or not, and if it is correct or not.
>
> "test-text" should contain one or more examples of broken text that
> needs to be fixed.  "make check" will spin a file with that text in it
> and run the "fixinc" program, then run a recursive "diff" between the
> patched files and a set of example files.  Any differences are
> highlighted.

I still do not understand. The diff is being performed between the patched file
and what example files? If I add a new fix, should I also put a patched
(correct) version in the set of example files (where are they)?


> So, when you make a fix, you should pretty well understand how the
> broken text ought to be transformed.  In the "make check", you ought
> to see a diff that includes that new transform in the new output and
> not in the sample output.

Now I am confused. I do not understand which of the following holds true:

- The diff shows what fixinclude did. It shows the different between the
original version (extracted from test-text) and the version that fixinclude
produced by applying your diff.
- The diff shows the mistakes of fixinclude, if any. It shows the different
between what fixinclude produced as output (by applying your fix to the
test-text) and what it is the expected result (which you have to put in a
different file -- where? how?).


>> 4.  Rebuild the compiler and check the header causing the issue.
>> Make sure it is now properly handled.  Add tests to the
>> "test_text" entry(ies) that validate your fix.  This will
>> help ensure that future fixes won't negate your work.
>
> That means first, ensure the header you want fixed is fixed.
> Then, incorporate the brokenness in the "text-text" field.
> Then, ensure it is fixed in the sample output.
> Then, add the fixed result into the baseline sample files.

This process can be done if you have physical access to the host with the
broken header. In my case, I was developing a fixinclude for a broken header
for another system. I have the broken header as a file (attacched to the bug).
How can I test my fix in this situation?

BTW: "rebuild the compiler" is a tad too much as first quick test for a
fixinclude (e.g. check that the regulard expression does not have a typo or
so). Even assuming access to the host, would you please explain if there is a
quicker wasy to just run fixincludes without rebuilding everything? Of course,
a full bootstrap would be still required as a final check.


> That means send me email if you are still having problems.

Thanks
Giovanni Bajo




-- 


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

[Bug middle-end/17549] [4.0 Regression] 15% increase in codesize with C code

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-18 13:35 
---
Turning off GVN-PRE at least on PPC gets back to what it was for 3.3:
5704 temp.s
5796 temp1.s
   11500 total

-- 


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

[Bug tree-optimization/18046] Missed jump threading optimization

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-10-18 13:22 
---
Might I propose we don't deal with this as an enhancement
request but as a "normal" bug?  Killing the jump threader
in cfgcleanup.c would be a mighty feat, it's one of the
slowest parts of the cfgcleanup on RTL (and IIRC it's one
of the quadratic bottleneckt).

Otherwise, perhaps I should (have) add(ed) the compile
time hog keyword...

-- 


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

[Bug regression/17919] [4.0 Regression] ICE at /cgraphunit.c:2907

[dave at hiauly1 dot hia dot nrc dot ca]

--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  2004-10-18 
13:17 ---
Subject: Re:  [4.0 Regression] ICE at /cgraphunit.c:2907

> --- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-18
> 04:31 ---
> I see that this looks fixed:
>  except 
> that the testsuite looks in bad shape.

I don't think the problem is fixed but it's not consistently reproducible.
It comes and goes with changes to the distribution tree.  I've seen it
both on hiauly6 and gsyprf11.

Regarding the large number of libstdc++ fails, these are all PCH fails.
I think they are caused by the testsuite using a different libstdc++
instead of the just built one.  On the other system that I do
hppa-unknown-linux-gnu testing on (gsyprf11), I have been testing a
patch to consolidate the setting of LD_LIBRARY_PATH into one module.
I don't see the PCH errors there.  See
.

Dave


-- 


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

[Bug middle-end/18045] [4.0 Regression] signed integer remainder for power of 2 broken

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-18 12:56 
---
Confirmed (-march=i486 will show the bug on i686-*).

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  Known to fail||4.0.0
  Known to work||3.4.0
   Last reconfirmed|-00-00 00:00:00 |2004-10-18 12:56:35
   date||


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

[Bug tree-optimization/18046] Missed jump threading optimization

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-18 12:52 
---
Confirmed. To summarize what the code should look like:
extern void foo (void);
extern int i;
void
bar (void)
{
  switch (i)
{
case 0:
  foo ();
  break;
default:
   goto other_block;
}
   

  switch (i)
{
case 0:
  foo ();
  break;
default:
other_block:
  break;
}
}

-- 
   What|Removed |Added

   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-10-18 12:52:47
   date||
Summary|Missed jump threading   |Missed jump threading
   |optimization|optimization


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

[Bug middle-end/18045] [4.0 Regression] signed integer remainder for power of 2 broken

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 CC||roger at eyesopen dot com
   Keywords||wrong-code
Summary|Wrong code for signed   |[4.0 Regression] signed
   |integer remainder   |integer remainder for power
   ||of 2 broken
   Target Milestone|--- |4.0.0


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

[Bug target/15286] ICE cause by reload

[uweigand at gcc dot gnu dot org]

--- Additional Comments From uweigand at gcc dot gnu dot org  2004-10-18 12:47 
---
On s390, CANNOT_CHANGE_MODE_CLASS does indeed return false for such
superclasses:

#define CANNOT_CHANGE_MODE_CLASS(FROM, TO, CLASS)   \
  (GET_MODE_SIZE (FROM) != GET_MODE_SIZE (TO)   \
   ? reg_classes_intersect_p (FP_REGS, CLASS) : 0)

This appears to be working fine ...

As I understand, regclass does indeed avoid widening the classs to one
for which CANNOT_CHANGE_MODE_CLASS returns true; it does not check sub-
classes.

-- 


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

[Bug tree-optimization/18046] New: Missed jump threading optimization

[steven at gcc dot gnu dot org]

Filed under unknown since there is no version tag for the
tree-cleanup-branch.
The problem probably also exists on mainline, but I have
not tried it there.

Consider this code,

-
extern void foo (void);
extern int i;
void
bar (void)
{
  switch (i)
{
case 0:
  foo ();
  break;
case 1:
  break;
}
   

  switch (i)
{
case 0:
  foo ();
  break;
case 1:
  break;
}
}
-

This gives the following .dse2 dump:

;; Function bar (bar)
   

bar ()
{
  int i.0;
   

:
  #   VUSE ;
  i.0_3 = i;
  switch (i.0_3)
{
  case 0: goto ;
  default : goto ;
}
   

:;
  #   i_6 = V_MAY_DEF ;
  foo ();
   

  # i_1 = PHI ;
:;
  #   VUSE ;
  i.0_4 = i;
  switch (i.0_4)
{
  case 0: goto ;
  default : goto ;
}
   

:;
  #   i_5 = V_MAY_DEF ;
  foo ();
   

:;
  return;
   

}

If the first switch goes through the default case, the
switch condition "i" is not call clobbered by the call
to "foo ()" so in the second switch "i" is unchanged and
we can thread the jump.

We don't catch this jump threading opportunity on trees,
but we *do* catch it on RTL.  This is *the* major source
of missed jump threads on the tree-cleanup-branch (we
catch rougly a thousand of these on the cc1-i file set).

If we teach the tree optimizers to catch this case, we
can almost certainly kill the RTL thread_jump junk on the
tree-cleanup-branch.

-- 
   Summary: Missed jump threading optimization
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: missed-optimization, alias, TREE
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
CC: dnovillo at redhat dot com,gcc-bugs at gcc dot gnu dot
org


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

[Bug c++/16564] g++ seems to go into an infinite loop after errors

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2004-10-18 12:14 
---
Upon closer inspection, gcc does not enter an infinite loop, it just
takes a while to finish.

The point is that the default for -ftemplate-depth used to be 17 in older
compilers. This was changed to 50 quite some tuime ago. And now it's 500,
see http://gcc.gnu.org/ml/gcc-patches/2002-01/msg00542.html

And that's why new versions keep iterating for a while.

The patch mentioned above states:
! The comment above the default sais it is just an arbitrary value, is
! there some reason to keep it that low?

Maybe 500 is too high on the other hand.


-- 
   What|Removed |Added

   Keywords|error-recovery, ice-on- |compile-time-hog
   |invalid-code|
Summary|g++ goes into an infinite   |g++ seems to go into an
   |loop after errors   |infinite loop after errors


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

[Bug libstdc++/17755] Can't compile djgpp cross-compiler

[psychonaut at nothingisreal dot com]

--- Additional Comments From psychonaut at nothingisreal dot com  2004-10-18 12:09 
---
Is it possible you're jumping the gun again, Andris?  I tried recompiling with
the sys-include directory created as you indicated, and the build still fails. 
However, it does fail at a different point than before; here's the error message
I get.  Any advice would be greatly appreciated.

/home/psy/software/cross-compiler/cross/gnu/gcc-3.4.2/gcc/xgcc -shared-libgcc
-B/home/psy/software/cross-compiler/cross/gnu/gcc-3.4.2/gcc/ -nostdinc++
-L/home/psy/software/cross-compiler/cross/gnu/gcc-3.4.2/i586-pc-msdosdjgpp/libstdc++-v3/src
-L/home/psy/software/cross-compiler/cross/gnu/gcc-3.4.2/i586-pc-msdosdjgpp/libstdc++-v3/src/.libs
-B/usr/local/compiler/cross/djgpp/i586-pc-msdosdjgpp/bin/
-B/usr/local/compiler/cross/djgpp/i586-pc-msdosdjgpp/lib/ -isystem
/usr/local/compiler/cross/djgpp/i586-pc-msdosdjgpp/include -isystem
/usr/local/compiler/cross/djgpp/i586-pc-msdosdjgpp/sys-include
-I/var/software_backup/cross-compiler/cross/gnu/gcc-3.4.2/i586-pc-msdosdjgpp/libstdc++-v3/include/i586-pc-msdosdjgpp
-I/var/software_backup/cross-compiler/cross/gnu/gcc-3.4.2/i586-pc-msdosdjgpp/libstdc++-v3/include
-I/var/software_backup/cross-compiler/cross/gnu/gcc-3.4.2/libstdc++-v3/libsupc++
-O2 -g -O2 -g -O2 -fno-implicit-templates -Wall -W -Wwrite-strings-Wcast-qual
-fdiagnostics-show-location=once -c basic_file.cc -o basic_file.o
basic_file.cc: In function `std::streamsize __gnu_internal::xwritev(int, const
char*, std::streamsize, const char*, std::streamsize)':
basic_file.cc:142: error: elements of array `__gnu_internal::iovec __iov[2]'
have incomplete type
basic_file.cc:142: error: storage size of `__iov' isn't known
basic_file.cc:151: error: `writev' undeclared (first use this function)
basic_file.cc:151: error: (Each undeclared identifier is reported only once
foreach function it appears in.)
make[3]: *** [basic_file.lo] Error 1
make[3]: Leaving directory
`/var/software_backup/cross-compiler/cross/gnu/gcc-3.4.2/i586-pc-msdosdjgpp/libstdc++-v3/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/var/software_backup/cross-compiler/cross/gnu/gcc-3.4.2/i586-pc-msdosdjgpp/libstdc++-v3'
make[1]: *** [all] Error 2
make[1]: Leaving directory
`/var/software_backup/cross-compiler/cross/gnu/gcc-3.4.2/i586-pc-msdosdjgpp/libstdc++-v3'
make: *** [all-target-libstdc++-v3] Error 2


-- 


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

[Bug middle-end/18045] New: Wrong code for signed integer remainder

[ebotcazou at gcc dot gnu dot org]

The following testcase:

extern void abort(void);

long long smod16(long long x)
{
  return x % 16;
}

int main(void)
{
  if (smod16 (0x) != 0xF)
abort ();

  return 0;
}

distilled from ada/uintp.adb:UI_From_Dint is miscompiled on i486 because of

2004-06-27  Roger Sayle  <[EMAIL PROTECTED]>

* expmed.c (expand_smod_pow2): New function to expand signed
remainder by a constant power of 2, such as "x % 16".
(expand_divmod): Call new expand_smod_pow2 when appropriate.
Minor corrections to comments, e.g. splitting long lines.


The second part of expand_smod_pow2 cannot handle modes whose size is greater
than that of HOST_WIDE_INT.

-- 
   Summary: Wrong code for signed integer remainder
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ebotcazou at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i486-*-*
  GCC host triplet: i486-*-*
GCC target triplet: i486-*-*


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

[Bug target/16482] [4.0 Regression] gcc.c-torture/unsorted/SFset.c fails with "-O2 -m4"

[naveen dot sharma at noida dot hcltech dot com]

--- Additional Comments From naveen dot sharma at noida dot hcltech dot com  
2004-10-18 12:03 ---
The patch submitted by Kaz looks OK to me. 
There are some heuristics in sh.c that were written to disable 
ready queue reordering when R0 is under pressure. But (mem (pseudo) (pseudo)) 
is an indirect implicit reference to R0.
I am wondering why this was missed? Was R0 a fixed_reg sometime during pre-3.3 
releases, so as to generate (mem (r0) (pesudo)) instead of (mem (pseudo) 
(pseudo) form?

-- 
   What|Removed |Added

 CC||naveens at noida dot hcltech
   ||dot com


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

[Bug c++/18044] method signatures with argument overloading does not work across class boundaries

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-18 11:36 
---
Invalid, test in Bar hides test in Foo.
Either use:
  using Foo::test;
in front of the declaration of test in Bar.
Or use the full name of test in Foo:
class Foo
{
public:
  void test(char *x)
  {
  }
};

class Bar : public Foo
{
public:
  void test(double t)
  {
Foo::test("x");
  }
};

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug libgcj/18036] Bad interaction between interpreter and Class.forName()

[aph at gcc dot gnu dot org]

-- 
   What|Removed |Added

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


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

[Bug c++/16564] g++ goes into an infinite loop after errors

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2004-10-18 10:36 
---
> That's likely the smallest possible testcase:

No, it isn't ;-)

===
template struct A
{
A a;
};

A a;
===

This example is even worse, since the compiler goes into an infinite loop
without issuing an error first.


-- 
   What|Removed |Added

 CC||reichelt at gcc dot gnu dot
   ||org
   Keywords||monitored


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

[Bug c++/18044] New: method signatures with argument overloading does not work across class boundaries

[oyvind dot harboe at zylin dot com]

This does not compile:

class Foo
{
public:
  void test(char *x)
  {
  }
};

class Bar : public Foo
{
public:
  void test(double t)
  {
test("x");
  }
};


$ g++ -c test2.cc
test2.cc: In member function `void Bar::test(double)':
test2.cc:14: error: no matching function for call to `Bar::test(const char[2])'
test2.cc:13: error: candidates are: void Bar::test(double)

To make it compile, change to:

class Foo
{
public:
  void testy(char *x)
  {
  }
};

class Bar : public Foo
{
public:
  void test(double t)
  {
testy("x");
  }
};

-- 
   Summary: method signatures with argument overloading does not
work across class boundaries
   Product: gcc
   Version: 3.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oyvind dot harboe at zylin dot com
CC: gcc-bugs at gcc dot gnu dot org


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