[Bug other/17991] [4.0 Regression] Two-process fixincludes broken: pz_mn_name_pat undefined

[bonzini at gcc dot gnu dot org]

--- Additional Comments From bonzini at gcc dot gnu dot org  2004-10-27 07:54 
---
I'm going to commit this as obvious in a few hours unless someone screams.

-- 


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

[Bug c/18171] New: Problem with varargs in #define-macro

[ingemar dot fransson at micronic dot se]

The following code fails to compile with GCC 2.95.3, but is OK with GCC 3.3.3 
(and also GCC 2.96 from RedHat):

/* test.c:2: badly punctuated parameter list in `#define' */
#define TRACE(args ...) printf(## args)

#define log(format, args...) printf("<%s:%s:%d>, " format, __FILE__, 
__FUNCTION__, __LINE__, ## args)

int main(void)
{
log("Log %s ...\n", "this");
/* test.c:10: parse error before `)' */
log("Empty log ...\n"); 
}


*  after "args" and before "..." in a macro fails to compile with the 
error:
test.c:2: badly punctuated parameter list in `#define'

* "Macro-call" with empty args fails to compile with the error:
test.c:10: parse error before `)'
A  needs to be inserted at "__LINE__ ,"

-- 
   Summary: Problem with varargs in #define-macro
   Product: gcc
   Version: 2.95.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ingemar dot fransson at micronic dot se
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/18075] [4.0 Regression] #pragma implementation broken in presence of #pragma ident

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-10-27 09:22 
---
> It turns out that #pragma ident is ignored on Solaris, too.

Yes, the bug is fully reproducible anywhere.  That's why I put *-*-* as the
triplets.

> Eric, can you test this patch in your Solaris setup?

It works just fine (libjava builds and gives decent testsuite results).

> I have not tried to build libjava on our Solaris machine before, and in any
> case that machine is appallingly slow.

You certainly meant libjava is appallingly bloated. ;-)  Yes, I confirm.

Thanks for quickly tackling the problem.


-- 


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

[Bug rtl-optimization/7799] Loop bug with optimization flag -Os in gcc

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2004-10-27 09:25 
---
This is fixed on mainline with Zdenek's patch
http://gcc.gnu.org/ml/gcc-cvs/2004-09/msg00234.html

Well, it is probably only papered over, since the RTL optimizer remains
unfixed. However, the testcase doesn't trigger the bug anymore because
of the tree optimizers. At least we have the related testcase
gcc.c-torture/execute/loop-2e.c in the testsuite which hopefully
triggers in case the bug reappears.


-- 
   What|Removed |Added

 CC||reichelt at gcc dot gnu dot
   ||org
 Status|SUSPENDED   |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.0.0


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

[Bug regression/18172] New: execution failure in vect-[20,22].c on ppc-linux

[dorit at il dot ibm dot com]

Getting the following testsuite failures on ppc-linux:
FAIL: gcc.dg/vect/vect-20.c execution test
FAIL: gcc.dg/vect/vect-20.c scan-tree-dump-times vectorized 3 loops 1
FAIL: gcc.dg/vect/vect-22.c execution test

These testcases actually fail even with vectorization disabled - it aborts when 
checking that the results for the code that operates on the char arrays are  
correct (arrays ca, cb). Changing these arrays to "signed char" fixes the 
problem. i.e:

35,46c35,46
<   char ca[N];
<   char cb[N] =
---
>   signed char ca[N];
>   signed char cb[N] =

will submit a patch along these lines shortly.

-- 
   Summary: execution failure in vect-[20,22].c on ppc-linux
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: regression
AssignedTo: dorit at il dot ibm dot com
ReportedBy: dorit at il dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: powerpc-suse-linux
  GCC host triplet: powerpc-suse-linux
GCC target triplet: powerpc-suse-linux


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

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

[davidm at hpl dot hp dot com]

--- Additional Comments From davidm at hpl dot hp dot com  2004-10-27 11:04 ---
(In reply to comment #11)
> Subject: Re:  bad unwind info due to multiple returns
>   (missing epilogue)
> 
> On Tue, 2004-10-26 at 01:49, davidm at hpl dot hp dot com wrote:
> > The compiler seemed to get stuck in an apparent endless loop.  "make check"
> > quickly resulted in timeout failures (and these were real, with the compiler
> > burning CPU cycles for several minutes until the timeout hit).
> 
> Maybe a temporary problem?

It doesn't appear to be for me: I just updated the sources and the compiler
still gets stuck almost immediately.  I did a quick q-syscollect run and got:

Command: /home/davidm/src/gcc/gcc/cc1 -quiet -iprefix /home/davidm/src/gcc/gcc/.
./lib/gcc/ia64-unknown-linux-gnu/4.0.0/ -isystem /home/davidm/src/gcc/gcc/includ
e /r/wailua/usr/src/misc/gcc/gcc/testsuite/gcc.c-torture/compile/20001226-1.c -q
uiet -dumpbase 20001226-1.c -auxbase-strip 20001226-1.o -Os -w -o /tmp/ccR2zJ8h.
s
Flat profile of CPU_CYCLES in cc1-pid1134-cpu0.hist#0:
 Each histogram sample counts as 1.00051m seconds
% time  self cumul calls self/call  tot/call name
 98.38  9.59  9.59  127k 75.8u 75.8u find_insn_list
  0.84  0.08  9.67  130k  631n 74.9u add_forward_dependence
  0.27  0.03  9.70  134k  195n  292n ggc_alloc_stat
  0.16  0.02  9.71  132k  121n  424n rtx_alloc_stat

[snip...]

Call-graph table:
index %time  self  children called name
   
[11]  100.0 11.0m  9.73 -  compute_forward_dependences
82.0m  9.65  130k/130k add_forward_dependence [2
1]

82.0m  9.65  130k  compute_forward_dependenc
es [11]
[21]   99.9 82.0m  9.65  130k  add_forward_dependence
3.00m 58.0m  128k/128k alloc_INSN_LIST [22]
 9.59  0.00  127k/127k find_insn_list [23]

 9.59  0.00  127k  add_forward_dependence [2
1]
[23]   98.4  9.59  0.00  127k  find_insn_list

3.00m 58.0m  128k  add_forward_dependence [2
1]
[22]0.6 3.00m 58.0m  128k  alloc_INSN_LIST
2.00m 56.0m  130k/130k gen_rtx_fmt_ue [27]


[snip..]

I ran configure with:

  $ configure --prefix=/opt/gcc-pre4.0

This was on a Debian/unstable system.  How do you run configure?


-- 


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

[Bug c/18171] Problem with varargs in #define-macro

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-27 11:32 
---
2.95.x is not going to be updated/changed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug regression/18173] New: execution failure in vect-[8,30].c on ppc-linux

[dorit at il dot ibm dot com]

Getting the following testsuite failures on ppc-linux:
FAIL: gcc.dg/vect/vect-30.c execution test
FAIL: gcc.dg/vect/vect-8.c execution test

These failures seem to be related to alignment - when the array types are 
changed from float to afloat:
typedef float afloat __attribute__ ((__aligned__(16)));
the tests pass ok.

When compiling the original version, the vectorizer forces the alignment of 
these arrays:

  if (vect_debug_details (NULL))
fprintf (dump_file, "force alignment");
  DECL_ALIGN (base) = TYPE_ALIGN (vectype);
  DECL_USER_ALIGN (base) = TYPE_ALIGN (vectype);

The tree dump files generated in both cases (float and afloat) looks identical,
as well as the RTL dumps; in both cases we have the following vector load/store 
generated (note the A128): 

(insn:TI 44 43 47 3 (set (reg:V4SF 77 0 [151])
(mem:V4SF (reg/f:SI 11 11 [orig:130 ivtmp.55 ] [130]) [4 S16 A128])) 
482 {altivec_lvx_4sf} (nil)
(expr_list:REG_EQUIV (mem:V4SF (reg/f:SI 9 9 [orig:129 ivtmp.65 ] [129]) [4 
S16 A128])
(nil)))

(insn:TI 45 47 48 3 (set (mem:V4SF (reg/f:SI 9 9 [orig:129 ivtmp.65 ] [129]) [4 
S16 A128])
(reg:V4SF 77 0 [151])) 486 {altivec_stvx_4sf} (insn_list:REG_DEP_TRUE 
44 (nil))
(nil))

Yet the version with afloats runs correctly, and the original version aborts.

Possible places to look into:
- vect_can_force_dr_alignment_p is wrong?
- PREFERRD_STACK_BOUNDARY != STACK_BOUNDARY (not the case here)
- setting DECL_USER_ALIGN/DECL_ALIGN is not enough?
- the decl alignment attribute not propagated to RTL? (looks like it is)
- assembler problem?

This may be related to PR17589.

I can send a patch that changes floats to afloats, as a temporary fix.

-- 
   Summary: execution failure in vect-[8,30].c on ppc-linux
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at il dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: powerpc-suse-linux
  GCC host triplet: powerpc-suse-linux
GCC target triplet: powerpc-suse-linux


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

[Bug libstdc++/18174] New: documentation example for std::priority_queue usage

[Number_42 at caramail dot com]

I just wanted to add an std::priority_queue usage example in the documentations,
since it's not obvious when you don't know how tu use it.

Since there isn't an "html" target in the root Makefile of gcc i didn't check
for validity of the patch, but i think it's ok.

$ uuencode priority_queue-3.4.1.patch.uu < priority_queue-3.4.1.patch  
  
begin 600 priority_queue-3.4.1.patch.uu
M9&EF9B`M<[EMAIL PROTECTED]PHK("[EMAIL PROTECTED]@
M<'5B;&[EMAIL PROTECTED]("[EMAIL PROTECTED]@("`@($EN="AI;G0@:2D**R`@("H@("`@("`@("`@
M.B!I7RAI*0HK("[EMAIL PROTECTED]@("`@('L**R`@("H@("`@("!]"BL@("`J"BL@("`J
M("`@("`@:6YT(&E?.PHK("[EMAIL PROTECTED]@?3L**R`@("H**R`@("H@('-T9#HZ;W-T
M7!E9&5F('-T9#HZ<')I
M;W)I='E?<75E=64\($EN="`J+"!V96-T;W)?='[EMAIL PROTECTED]5]Q=65U95]T>7!E.PHK("[EMAIL PROTECTED]@HK("[EMAIL 
PROTECTED]@=F]I9`HK("[EMAIL PROTECTED]@
M9F]O*"D**R`@("H@('L**R`@("H@("`@("!V96-T;W)?='EP92!V.PHK("`@
[EMAIL PROTECTED]("[EMAIL PROTECTED]@("`@('8N<'5S:%]B86-K*&YE=R!);G0H."DI.PHK("[EMAIL 
PROTECTED]@
M("`@('8N<'5S:%]B86-K*&YE=R!);G0H,2DI.PHK("[EMAIL PROTECTED]@("`@('8N<'5S
M:%]B86-K*&YE=R!);G0H-2DI.PHK("[EMAIL PROTECTED]@HK("[EMAIL PROTECTED]@("`@('!R:6]R:71Y
M7W%U975E7W1Y<&4@<'$H=BYB96=I;[EMAIL PROTECTED]"!V+F5N9"@I*3L**R`@("H**R`@
M("H@("`@("!W:&EL92`H(7!Q+F5M<'1Y*"DI"BL@("`J("`@("`@>PHK("`@
M*B`@("`@("`@("!S=&0Z.F-O=70@/[EMAIL PROTECTED]<"@I(#P\('-T9#HZ96YD
M;#L**R`@("H@("`@("`@("[EMAIL PROTECTED]&5L971E('!Q+G1O<"@I.PHK("[EMAIL PROTECTED]@("`@
M("`@("!P<2YP;W`H*3L**R`@("H@("`@("!]"BL@("`J("!]"BL@("`J("!<
M96YD8V]D90HK("[EMAIL PROTECTED]("[EMAIL PROTECTED]&5M<&QA=&4\='EP96YA;[EMAIL 
PROTECTED]"!T>7!E
H;F%M92!?4V5Q=65N8V4^"B`@("[EMAIL PROTECTED]
+   *  #include 
+   *  #include 
+   *
+   *  class Int
+   *  {
+   *  public:
+   *  Int(int i)
+   *  : i_(i)
+   *  {
+   *  }
+   *
+   *  int i_;
+   *  };
+   *
+   *  std::ostream &
+   *  operator<< (std::ostream & os, const Int & i)
+   *  {
+   *  return os << i.i_;
+   *  }
+   *
+   *  class Int_less
+   *  {
+   *  public:
+   *  // Function operator
+   *  bool operator() (const Int * i1, const Int * i2)
+   *  {
+   *  return i1->i_ < i2->i_;
+   *  }
+   *  };
+   *
+   *  typedef std::vector< Int * > vector_type;
+   *  typedef std::priority_queue< Int *, vector_type, Int_less >
priority_queue_type;
+   *
+   *  void
+   *  foo()
+   *  {
+   *  vector_type v;
+   *
+   *  v.push_back(new Int(8));
+   *  v.push_back(new Int(1));
+   *  v.push_back(new Int(5));
+   *
+   *  priority_queue_type pq(v.begin(), v.end());
+   *
+   *  while (!pq.empty())
+   *  {
+   *  std::cout << *pq.top() << std::endl;
+   *  delete pq.top();
+   *  pq.pop();
+   *  }
+   *  }
+   *  \endcode
+   */
   template
 class queue
 {


HTH

-- 
   Summary: documentation example for std::priority_queue usage
   Product: gcc
   Version: 3.4.1
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P2
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Number_42 at caramail dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: all
  GCC host triplet: all
GCC target triplet: all


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

[Bug other/18172] execution failure in vect-[20,22].c on ppc-linux

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-27 11:42 
---
Confirmed, on most PowerPC targets (except for darwin), char is unsigned by default 
which causes the 
problem.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
  Component|regression  |other
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-10-27 11:42:49
   date||


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

[Bug target/18173] execution failure in vect-[8,30].c on ppc-linux

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|regression  |target
   Keywords||wrong-code


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

[Bug libstdc++/18174] documentation example for std::priority_queue usage

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-27 11:45 
---
Could you send your patch to gcc-patches@ and [EMAIL PROTECTED]  Also could you make 
it off the HEAD (aka 
4.0.0)?

-- 


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

[Bug target/17589] segfault while running code compiled with -ftree-vectorize

[dorit at il dot ibm dot com]

--- Additional Comments From dorit at il dot ibm dot com  2004-10-27 11:48 ---
(In reply to comment #7)
> Can anyone reproduce the problem on i686-linux (P4)?

I wasn't able to reporoduce it on i686-pc-linux-gnu.

This might be related to PR18173.

Is PREFERRED_STACK_BOUNDARY != STACK_BOUNDARY in the platform in question? 
maybe that's the problem? (this deson't seem to be the problem thought in 
PR18173).



-- 


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

[Bug target/18170] m32r-elf-as, m32r-linux-as debug relocation error for c++

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-27 11:54 
---
What version of binutils are you using?

-- 
   What|Removed |Added

  Component|c++ |target


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

[Bug libstdc++/18174] documentation example for std::priority_queue usage

[Number_42 at caramail dot com]

--- Additional Comments From Number_42 at caramail dot com  2004-10-27 12:00 
---

(In reply to comment #1)
> Could you send your patch to gcc-patches@ and [EMAIL PROTECTED]  Also could you make
it off the HEAD (aka 
> 4.0.0)?

I can send it to these mailing lists but i can't download the all gcc CVS, so
not on 4.0.0.


-- 


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

[Bug target/18170] m32r-elf-as, m32r-linux-as debug relocation error for c++

[inaoka dot kazuhiro at renesas dot com]

--- Additional Comments From inaoka dot kazuhiro at renesas dot com  2004-10-27 
12:05 ---
(In reply to comment #1)
> What version of binutils are you using?
GNU assembler version 2.15.94 (m32r-elf) using BFD version 2.15.94 20041022


-- 


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

[Bug java/18175] New: Can't find default package with redundant package import

[phil at mkdoc dot com]

The following class will not compile with GCJ version 3.3.3 (cygwin special), 
succeeds with Sun javac. The workaround is obvious, but not always easy with 
other people's code.

$ gcj -classpath . -C Test.java
Test.java:3: error: Can't find default package `com.example'. Check the CLASSPAT
H environment variable and the access to the archives
1 error

-- Test.java

package com.example;

import com.example.*;

class Test {

}

-- End Test.java

-- 
   Summary: Can't find default package with redundant package import
   Product: gcc
   Version: 3.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: phil at mkdoc dot com
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=18175

[Bug c/17913] [4.0 Regression] ICE jumping into statement expression

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-10-27 12:25 
---
Surely this is not valid?

A statement expression is an _expression_ so any kind of control
flow into or out of a statement expression is just wrong IMHO.
It's like jumping into "a + b", try defining semantics for such
a construct.

Looking at the documentation as an indication of the intent of
this extension, it appears that control flow into and out of
statement expressions is not supposed to happen:

   "   A compound statement enclosed in parentheses may appear as an
   expression in GNU C.  This allows you to use loops, switches, and
   local variables within an expression."

Note, [various control structures] *within* an expression".
So statement expressions are still just expressions, and control
flow is supposed to be within the expression.  Jumping into or
out of statement expressions was apparently not intended to be
supported.

So I think this really should be a hard error.  



-- 
   What|Removed |Added

 CC||loki at inf dot u-szeged dot
   ||hu
   Last reconfirmed|2004-10-09 20:18:31 |2004-10-27 12:25:14
   date||


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

[Bug c/17913] [4.0 Regression] ICE jumping into statement expression

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-10-27 12:42 
---
Proposed patch here.
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg02304.html

Part of the discussion here (broken mailer :-/)
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg02310.html

-- 


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

[Bug c/17913] [4.0 Regression] ICE jumping into statement expression

[jsm at polyomino dot org dot uk]

--- Additional Comments From jsm at polyomino dot org dot uk  2004-10-27 12:55 
---
Subject: Re:  [4.0 Regression] ICE jumping into statement
 expression

On Wed, 27 Oct 2004, steven at gcc dot gnu dot org wrote:

> Surely this is not valid?

The validity is the subject of bug 772 and the long thread linked from 
there.  This bug is for a particular ICE which is a regression; whether 
the code is valid or invalid depends on whether any resolution suggested 
in bug 772 or elsewhere is adopted.

I haven't seen a use for jumps into statement expressions and think we 
should disallow them.  This isn't as simple as making the labels local to 
the statement expression.  First, you need to check for switch statements 
jumping into the statement expression.  Second, if inside a statement 
expression you encounter a reference to an undeclared label, you don't 
know whether it refers to one later within that statement expression or 
one outside in the function (and in an address-of-label context, both 
could reasonably be valid) so don't know in what scope to declare the 
label (or, if there's one outside already seen with that name, whether the 
new one is a reference to that label or to a new local one).  For that 
reason I think it's best to keep the current scoping rules and have a 
separate check for any form of jumps into statement expressions, with 
jumps by computed goto explicitly runtime undefined.  (While jumps in from 
longjmp might be OK.)

Jumps out of statement expressions are or were used in real code 
.  I don't think 
they are well-defined (except for jumps using longjmp), but I believe we 
need a deprecation period before removing them (e.g. deprecate in 4.0, 
remove in 4.1).



-- 


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

[Bug java/18175] Can't find default package with redundant package import

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-27 13:05 
---
Confirmed.  Almost certain that is related to (or even the same bug as) PR 6818.

-- 
   What|Removed |Added

  BugsThisDependsOn||6818
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||rejects-valid
   Last reconfirmed|-00-00 00:00:00 |2004-10-27 13:05:29
   date||


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

[Bug target/17956] [4.0 Regression] ICE in rs6000_emit_minmax, config/rs6000/rs6000.c:11725

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-27 13:06 
---
Yes that fixes the Ada problem also.  Thanks David.

-- 


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

[Bug bootstrap/18176] New: Bootstrap fail at FreeBSD 5.3-RC1 (and FreeBSD 5.1) with --enable-bootstrap configure option

[wanderer at rsu dot ru]

Bootstrap current CVS mainline GCC terminated with errors:
--8X--
/usr/home/wanderer/pkg/build/gcc/obj/prev-gcc/xgcc -
B/usr/home/wanderer/pkg/build/gcc/obj/prev-gcc/ -B/home/wanderer/pkg/gcc/i386-
unknown-freebsd5.3/bin/  -I/home/wanderer/pkg/build/gcc/src/gcc/gcc/libcpp -
I. -I/home/wanderer/pkg/build/gcc/src/gcc/gcc/libcpp/../include -
I/home/wanderer/pkg/build/gcc/src/gcc/gcc/libcpp/include  -O2 -g -fomit-frame-
pointer -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -
Wold-style-definition -pedantic -Wno-long-long -Werror -
I/home/wanderer/pkg/build/gcc/src/gcc/gcc/libcpp -I. -
I/home/wanderer/pkg/build/gcc/src/gcc/gcc/libcpp/../include -
I/home/wanderer/pkg/build/gcc/src/gcc/gcc/libcpp/include  -
c /home/wanderer/pkg/build/gcc/src/gcc/gcc/libcpp/directives.c
cc1: warnings being treated as errors
/home/wanderer/pkg/build/gcc/src/gcc/gcc/libcpp/directives.c: In 
function 'cpp_handle_deferred_pragma':
/home/wanderer/pkg/build/gcc/src/gcc/gcc/libcpp/directives.c:1431: warning: 
pointer targets in passing argument 3 of 'run_directive' differ in signedness
gmake[2]: *** [directives.o] Error 1
gmake[2]: Leaving directory `/usr/home/wanderer/pkg/build/gcc/obj/stage2-
libcpp'
gmake[1]: *** [all-stage2-libcpp] Error 2
gmake[1]: Leaving directory `/usr/home/wanderer/pkg/build/gcc/obj'
gmake: *** [stage2-bubble] Error 2
--X8--

I run configure with options:
/home/wanderer/pkg/build/gcc/src/gcc/gcc/configure --
prefix=/home/wanderer/pkg/gcc --enable-bootstrap --enable-threads=posix --with-
gnu-as --with-gnu-ld --enable-languages=c,c++

For bootstrap used system compiler (gcc version 3.4.2 [FreeBSD] 20040728)

Before upgrade FreeBSD i already see same error with FreeBSD 5.1.

Without --enable-bootstrap option GCC bootstraped without problems (if exclude 
unrelated bug 17526 )

-- 
   Summary: Bootstrap fail at FreeBSD 5.3-RC1 (and FreeBSD 5.1) with
--enable-bootstrap configure option
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wanderer at rsu dot ru
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i386-unknown-freebsd5.3-RC1
  GCC host triplet: i386-unknown-freebsd5.3-RC1
GCC target triplet: i386-unknown-freebsd5.3-RC1


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

[Bug c/772] Statement expressions issues

[bangerth at dealii dot org]

--- Additional Comments From bangerth at dealii dot org  2004-10-27 13:21 ---
A similar problem are jumps via 'break'/'continue' out of statement 
expressions. Here's a place where people have really used this: 
  http://gcc.gnu.org/ml/gcc-patches/2003-05/msg00706.html 
(Isn't the ability of people to come up with really bad ideas amazing?) 
 
W. 

-- 


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

[Bug c/772] Statement expressions issues

[bangerth at dealii dot org]

--- Additional Comments From bangerth at dealii dot org  2004-10-27 13:24 ---
Some more discussion here: 
  http://gcc.gnu.org/ml/gcc-patches/2004-10/msg02310.html 

-- 


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

[Bug java/6818] "Can't find default package" when package has no classes

[rmathew at gcc dot gnu dot org]

--- Additional Comments From rmathew at gcc dot gnu dot org  2004-10-27 13:30 
---
This is not a bug. Using the submitter's test case against
JDK 1.4.2_03 from Sun on Linux:
-- 8< --
~/src/tmp/r1 > java -version
java version "1.4.2_03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-b02)
Java HotSpot(TM) Client VM (build 1.4.2_03-b02, mixed mode)

~/src/tmp/r1 > javac foo/bar/Test.java
foo/bar/Test.java:1: package foo does not exist
import foo.*;
^
1 error

~/src/tmp/r1 > touch foo/Junk.class
~/src/tmp/r1 > javac foo/bar/Test.java

~/src/tmp/r1 > rm foo/Junk.class
~/src/tmp/r1 > javac foo/bar/Test.java
foo/bar/Test.java:1: package foo does not exist
import foo.*;
^
1 error
-- 8< --

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


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

[Bug java/18175] Can't find default package with redundant package import

[rmathew at gcc dot gnu dot org]

-- 
Bug 18175 depends on bug 6818, which changed state.

Bug 6818 Summary: "Can't find default package" when package has no classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6818

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||INVALID

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

[Bug middle-end/14684] [4.0 Regression] -fprofile-use/-fprofile-generate failure because of coverage mismatch

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-10-27 13:35 
---
Subject: Bug 14684

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-10-27 13:35:45

Modified files:
gcc: ChangeLog opts.c 

Log message:
2004-10-27  Andreas Krebbel  <[EMAIL PROTECTED]>
patch originally created by Kelley Cook  <[EMAIL PROTECTED]>

PR middle-end/14684
* opts.c (OPT_fprofile_generate): Default to -funroll-loops
to match -fprofile-use.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6037&r2=2.6038
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/opts.c.diff?cvsroot=gcc&r1=1.83&r2=1.84



-- 


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

[Bug java/18175] Can't find default package with redundant package import

[rmathew at gcc dot gnu dot org]

--- Additional Comments From rmathew at gcc dot gnu dot org  2004-10-27 13:37 
---
Andrew, did you try it with the current mainline? I don't see this bug any more
at all. IMHO, this should be closed.

-- 


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

[Bug java/18175] Can't find default package with redundant package import

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-27 13:41 
---
I used "gcc version 4.0.0 20041026 (experimental)"

-- 


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

[Bug middle-end/14684] [4.0 Regression] -fprofile-use/-fprofile-generate failure because of coverage mismatch

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-27 13:42 
---
Fixed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug other/17991] [4.0 Regression] Two-process fixincludes broken: pz_mn_name_pat undefined

[bkorb at veritas dot com]

--- Additional Comments From bkorb at veritas dot com  2004-10-27 13:46 ---
Subject: Re:  [4.0 Regression] Two-process fixincludes
broken: pz_mn_name_pat undefined

bonzini at gcc dot gnu dot org wrote:
> 
> --- Additional Comments From bonzini at gcc dot gnu dot org  2004-10-27 07:54 
> ---
> I'm going to commit this as obvious in a few hours unless someone screams.
> 
> --
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17991
> 
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.

I'm sorry I didn't see this.  It is _very_ obvious.  If the few
hours haven't elapsed yet, then please wait no longer.  Thanks! - Bruce


-- 


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

[Bug c++/18177] New: [4.0 regression] ICE with const_cast for undeclared variable

[reichelt at gcc dot gnu dot org]

The following invalid code snippet causes an ICE when compiled with mainline:

=
void foo()
{
X;
const_cast(X);
}
=

bug.cc: In function `void foo()':
bug.cc:3: error: 'X' was not declared in this scope
bug.cc:4: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in build_pointer_type_for_mode, at tree.c:4118
Please submit a full bug report, [etc.]

The regression appeared in March 2004:
: Search converges between 2004-03-01-trunk (#446) and 2004-04-01-trunk (#447).

-- 
   Summary: [4.0 regression] ICE with const_cast for undeclared
variable
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, error-recovery, monitored
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/18177] [4.0 regression] ICE with const_cast for undeclared variable

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-27 13:57 
---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-10-27 13:57:53
   date||
   Target Milestone|--- |4.0.0


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

[Bug java/18175] Can't find default package with redundant package import

[rmathew at gcc dot gnu dot org]

--- Additional Comments From rmathew at gcc dot gnu dot org  2004-10-27 14:08 
---
Weird! I don't see this error at all (i686-pc-linux-gnu) with
the current mainline:
-- 8< --
~/src/tmp/r1 > cat com/example/Test.java
package com.example;
import com.example.*;
class Test { }

~/src/tmp/r1 > $MYGCJ -classpath . -C com/example/Test.java

~/src/tmp/r1 > $MYGCJ --version
gcj (GCC) 4.0.0 20041027 (experimental)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-- 8< --

MYGCJ is a variable defined in such a way that I can use
the GCJ built from CVS without having to actually install
it:

~/src/tmp/r1 > echo $MYGCJ
/home/ranmath/src/gcc/build/gcc/gcj -B/home/ranmath/src/gcc/build/gcc/ -B/home/r
anmath/src/gcc/build/i686-pc-linux-gnu/libjava/ -I/home/ranmath/src/gcc/build/i6
86-pc-linux-gnu/libjava/libgcj-4.0.0.jar -L/home/ranmath/src/gcc/build/i686-pc-l
inux-gnu/libjava/.libs

But I don't think that should affect the outcome.

-- 


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

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

[pinskia at gcc dot gnu dot org]

We miss an opportunity to remove the bounds checking code in the following case (this 
shows up a 
huge amount in libjava and other code):
class t
{
  void f(int a[])
  {
 for(int i=0;ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=18178

[Bug java/18175] Can't find default package with redundant package import

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-27 14:13 
---
Note you compiling with the full path to the package/java source where the problem 
comes into play.
If you compile with just gcj -c Test.java, it fails.

-- 


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

[Bug java/18175] Can't find default package with redundant package import

[rmathew at gcc dot gnu dot org]

--- Additional Comments From rmathew at gcc dot gnu dot org  2004-10-27 14:15 
---
Oh! I see.

In that case, I do not see the error with JDK 1.4.2_03 
(Linux), but I do see it with GCJ (mainline, Linux). So
yeah, it is sort of a bug.

But note that it is still not quite the same as PR6818.

The workaround is to compile from the folder containing
"com/example" as is the norm in Java programming.

-- 


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

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

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-27 14:15 
---
The tree level looks like after optimization:
t.f(int[]) (this, a)
{
  int i;
  int D.385;
  unsigned int i.3;
  int D.376;

:
  D.376 = a->length;
  if (D.376 <= 0) goto ; else goto ;

:;
  i = 0;

:;
  i.3 = (unsigned int) i;
  if ((unsigned int) D.376 > i.3) goto ; else goto ;

:;
  D.385 = _Jv_ThrowBadArrayIndex (i);

:;
  *(&a->data[0] + (int *) i.3 * 4B) = 0;

;
  i = (int) (i.3 + 1);
  D.376 = a->length;
  if (i >= D.376) goto ; else goto ;

:;
  return;

}

-- 


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

[Bug c++/18177] [4.0 regression] ICE with const_cast for undeclared variable

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2004-10-27 14:29 
---
Mark, the regression appears with your patch for PR14401:
http://gcc.gnu.org/ml/gcc-cvs/2004-03/msg00427.html

Could you please have a look?


-- 
   What|Removed |Added

 CC||mark at codesourcery dot com


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

[Bug tree-optimization/18179] New: vectorizer: wrong alignment/step/initial-address computed for struct accesses

[dorit at il dot ibm dot com]

The following testcase:

===
struct s{
  int m;
  int n[N][N][N];
};

struct test1{
  struct s a; /* array a.n is unaligned */
  int b;
  int c;
  struct s e[N]; /* array e.n is aligned */
};

int main ()
{
  int i,j;
  struct test1 tmp1;

  for (i = 0; i < N; i++)
for (j = 3; j < N-3; j++)
  {
tmp1.e[i].n[1][2][j] = 8;
  }

  /* check results:  */
  for (i = 0; i < N; i++)
for (j = 3; j < N-3; j++)
{
  if (tmp1.e[i].n[1][2][j] != 8)
  abort ();
}

  /* not consecutive */
  for (i = 0; i < N; i++)
for (j = 3; j < N-3; j++)
  {
tmp1.e[j].n[1][2][j] = 8;
  }

  /* check results:  */
  for (i = 0; i < N; i++)
for (j = 3; j < N-3; j++)
{
  if (tmp1.e[j].n[1][2][j] != 8)
  abort ();
}

  return 0;
}
===

currently produces wrong results. The problem is that only the indexes of the 
last (rightmost) component are analyzed, and the rest are ignored, so we end up 
computing wrong alignment (for the first loop) and wrong step (for the second 
loop, where we conclude that the access is consecutive where it really isn't). 
Both these problems will be addressed soon by the patch that switches to use  
get_inner_reference (http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01140.html).

-- 
   Summary: vectorizer: wrong alignment/step/initial-address
computed for struct accesses
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: irar at il dot ibm dot com
ReportedBy: dorit at il dot ibm dot com
CC: dorit at il dot ibm dot com,gcc-bugs at gcc dot gnu dot
org
 GCC build triplet: powerpc-apple-darwin7.0.0
  GCC host triplet: powerpc-apple-darwin7.0.0
GCC target triplet: powerpc-apple-darwin7.0.0


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

[Bug c/18180] New: Disable special handling of functions with --freestanding

[alex dot neyman at auriga dot ru]

The documentation on GCC states that in freestanding environment, no 
assumptions are made: 
 
 
To make it act as a conforming freestanding 
implementation for a freestanding environment, use the option 
`-ffreestanding'; it will then define `__STDC_HOSTED__' to `0' and not 
make assumptions about the meanings of function names from the standard 
library 
 
 
However, a simple testcase shows that 
- different code is generated for function issuing the setjmp() call and any 
other function call in freestanding env (actually, the code for a function 
using setjmp() is the same both in hosted and freestanding env). 
 
- The 'variable might be clobbered' warning is emitted for setjmp() call even 
in freestanding env 
 
Try compiling the test case with the following flags: 
*1) gcc -DSETJMP=setjmp -ffreestanding -s ff.c 
*2) gcc -DSETJMP=setjmp -fhosted -s ff.c 
*3) gcc -DSETJMP=mysetjmp -ffreestanding -s ff.c 
 
and compare the output. *1 and *2 give the same output, which differs from *3.

-- 
   Summary: Disable special handling of functions with --
freestanding
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alex dot neyman at auriga dot ru
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug c/18180] Disable special handling of functions with --freestanding

[alex dot neyman at auriga dot ru]

--- Additional Comments From alex dot neyman at auriga dot ru  2004-10-27 14:38 
---
Created an attachment (id=7416)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7416&action=view)
The test case


-- 


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

[Bug tree-optimization/18179] vectorizer: wrong alignment/step/initial-address computed for struct accesses

[dorit at il dot ibm dot com]

--- Additional Comments From dorit at il dot ibm dot com  2004-10-27 14:41 ---
Created an attachment (id=7417)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7417&action=view)
testcase.

Forgot to mention - occurs when compiling with '-O2 -ftree-vectorize
-maltivec'.

Attached is the complete testcase.

-- 


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

[Bug other/17991] [4.0 Regression] Two-process fixincludes broken: pz_mn_name_pat undefined

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-10-27 14:43 
---
Subject: Bug 17991

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

Modified files:
fixincludes: ChangeLog configure configure.ac fixincl.c 

Log message:
2004-10-27  Paolo Bonzini  <[EMAIL PROTECTED]>

PR other/17991

* configure.ac: Fix typo.
* configure: Regenerate.
* fixincl.c (fix_with_system): tSCC is not a pointer.  Fix.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/fixincludes/ChangeLog.diff?cvsroot=gcc&r1=1.10&r2=1.11
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/fixincludes/configure.diff?cvsroot=gcc&r1=1.2&r2=1.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/fixincludes/configure.ac.diff?cvsroot=gcc&r1=1.2&r2=1.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/fixincludes/fixincl.c.diff?cvsroot=gcc&r1=1.3&r2=1.4



-- 


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

[Bug other/17991] [4.0 Regression] Two-process fixincludes broken: pz_mn_name_pat undefined

[bonzini at gcc dot gnu dot org]

--- Additional Comments From bonzini at gcc dot gnu dot org  2004-10-27 14:44 
---
Fixed by the above commit.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/17832] [4.0 Regression] Bootstrap broken by fixincludes failures

[bonzini at gcc dot gnu dot org]

-- 
Bug 17832 depends on bug 17991, which changed state.

Bug 17991 Summary: [4.0 Regression] Two-process fixincludes broken: pz_mn_name_pat 
undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17991

   What|Old Value   |New Value

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

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

[Bug target/18141] mips64-none-elf-gcc: Excessive NOPs with -march=r3000

[rsandifo at gcc dot gnu dot org]

--- Additional Comments From rsandifo at gcc dot gnu dot org  2004-10-27 14:48 
---
This is a known problem, and is due to the fact that paired
FP registers can't be treated as separate entities.  This leads
to an internal representation of double loads that appears to
indicate a read-after-write dependency between the first lwc1
and the second.

In many cases, the scheduler will be able to fill the gap between
two lwc1s with something else, so the nop should be avoided more
often than not.

This is something I hope to fix one day, but it's quite low down
my list of priorities.  Marking as suspended/enhancement for now.
I'll assign it to myself later if I think I'll have time to work
on a fix.


-- 
   What|Removed |Added

   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-10-27 14:48:59
   date||


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

[Bug target/18141] mips64-none-elf-gcc: Excessive NOPs with -march=r3000

[rsandifo at gcc dot gnu dot org]

-- 
   What|Removed |Added

 CC||rsandifo at gcc dot gnu dot
   ||org
 Status|NEW |SUSPENDED


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

[Bug libfortran/17748] libgfortran contains undefined references to _environ

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-27 14:49 
---
I basically just posted your patch with an addtional comment:
.

-- 
   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=17748

[Bug c/18180] Disable special handling of functions with --freestanding

[alex dot neyman at auriga dot ru]

--- Additional Comments From alex dot neyman at auriga dot ru  2004-10-27 14:55 
---
Created an attachment (id=7418)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7418&action=view)
Proposed patch

The patch, however, leads to a build failure:
optabs.h and c-common.h have a clash with CTI_MAX enumeration value.
Patch was tested by rename with CTI_MAX in optabs.[ch] renamed to CTI_max.
(not regression-tested, though). The resulting assembly is the same in *2 and
*3, and differs from *1. No "might be clobbered" warnings are generated
in -freestanding mode.

-- 


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

[Bug c/18180] Disable special handling of functions with --freestanding

[alex dot neyman at auriga dot ru]

--- Additional Comments From alex dot neyman at auriga dot ru  2004-10-27 14:56 
---
Just to make it clear: this test case never produces "variable might be 
clobbered" warning, another test case was used for that. 

-- 


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

[Bug c/18180] Disable special handling of functions with --freestanding

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-27 15:00 
---
Try with -fno-builtins.

-- 


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

[Bug tree-optimization/18181] New: vectorizer: problem in the peeling mechanism in the presence of loop invariants that are used after the loop

[dorit at il dot ibm dot com]

The loop peeling mechanism in the vectorizer (which is used to force alignment 
of stores - by peeling the first few iterations, and to support unknown loop 
bound - by peeling te last few iterations) does not handle correctly the case 
where a loop invariant is used after the loop; there are two problems:
- When updating ssa-names the peeling utility assumes that anything that needs 
to be considered has a phi node at the loop header (which is not the case for 
loop invariants).
- The peeling utility creats a path that did not exist before - from the loop 
prolog to the loop exit - and there is no value to assign for this variable on 
this path (as it is only defined inside the loop).

This situation should rarely occur, but it did come up in the following case 
(complete testcase attached in 
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg00981.html):

for i
  for j
a[i][j]= [i+1][j]

This is represented as follows:

outer_loop_start
i = phi (0, i')
inner_loop_start
j = phi (0, j')
k = i + 1
a[i][j] = a[k][j]
j' = j + 1
inner_loop_end
i' = phi (k) 

k is the invariant defined in the inner-loop and used after the inner-loop (it 
was actually moved into the inner loop by PRE...).

This problem does not show up currently because it needs Devang's dependence-
distance patch (without it the vectorizer does not attempt to vectorize this 
loop). But as soon as his patch goes in -
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01046.html, 
the problem in this testcase will show up.

A patch to solve this is in the works.

-- 
   Summary: vectorizer: problem in the peeling mechanism in the
presence of loop invariants that are used after the loop
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: dorit at il dot ibm dot com
ReportedBy: dorit at il dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: powerpc-apple-darwin7.0.0
  GCC host triplet: powerpc-apple-darwin7.0.0
GCC target triplet: powerpc-apple-darwin7.0.0


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

[Bug c/18180] Disable special handling of functions with --freestanding

[alex dot neyman at auriga dot ru]

--- Additional Comments From alex dot neyman at auriga dot ru  2004-10-27 15:09 
---
Tried, the result of "-ffreestanding -fno-builtin" is the same as just 
"-ffreestanding". Also, IIRC -ffreestanding implies -fno-builtin, doesn't it? 

-- 


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

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

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2004-10-27 15:29 
---
Subject: Re:  [3.4/4.0 Regression] unaligned xmm movaps on the stack with -O2 -msse 
because of the frame pointer

uros at kss-loka dot si wrote:

> target/12902: Invalid assembly generated when using SSE / xmmintrin.h
> target/14776: -mfpmath=sse causes movapd from non-16-byte aligned
> address fortran/17930: -mfpmath=sse creates illegal code (movapd with
> misaligned argument)
>
> and perhaps:
> target/10395: [x86] vector types are incorrectly aligned causing
> crash in multi-threaded apps or when using in main
> [this bug has 10 dupes!]

Uros, thanks for the analysys. I have just given you edit access to Bugzilla,
would you please close the dupes as such yourself, but making sure that you
bring over any attacched comments/patches/testcases that you think might
matter?

Thanks,
Giovanni Bajo




-- 


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

[Bug target/17646] [4.0 Regression] xgcc links 64bit objects into a 32bit target

[jgrimm2 at us dot ibm dot com]

--- Additional Comments From jgrimm2 at us dot ibm dot com  2004-10-27 15:38 
---
What I've finally done to get my 64-bit biarch default64 compiler is to first
build a 32-bit biarch default64 compiler.  I can then make bootstrap using this
intermediate compiler as the host compiler to build all stages 64-bit.  I'd
classify my earlier attempts as user error, though still think it should be
possible to do this eventually in one swoop on ppc64.  

Otherwise, i've been able to bootstrap just fine, though obviously I'm
configuring my build a bit differently than below. I just wanted to post back in
case others runs across my comments in sometime in the future and wanted to
close out those comments. 

-- 


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

[Bug c/18180] Disable special handling of functions with --freestanding

[jsm at polyomino dot org dot uk]

--- Additional Comments From jsm at polyomino dot org dot uk  2004-10-27 15:39 
---
Subject: Re:  New: Disable special handling of functions with
 --freestanding

On Wed, 27 Oct 2004, alex dot neyman at auriga dot ru wrote:

> - different code is generated for function issuing the setjmp() call and any 
> other function call in freestanding env (actually, the code for a function 
> using setjmp() is the same both in hosted and freestanding env). 

The bug would be that special_function_p checks function names at all.

We have at least three different methods of applying special properties to 
functions based on their names: built-in functions with attributes, 
special_function_f and cp/cfns.gperf.  We should subsume the latter two in 
the first.  See projects/beginner.html.  The special handling may be 
needed to generate correct code in some cases such as setjmp, so disabling 
the special handling without first having an attribute allowing it to be 
reenabled for particular declarations is not a good solution.

I would advise following the usual procedures for contributing (see 
contribute.html) to discuss the issues on gcc-patches and work through 
getting a patch for bug 14411 into GCC.  That is necessary to solve the 
issues for bug 14411.  It would be best to do a series of patches, one for 
each attribute (discussed and revised as necessary) followed by one 
replacing the special_function_p handling with use of that attribute 
(including fixincludes work as necessary).



-- 


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

[Bug c++/14179] [3.3/3.4/4.0 Regression] out of memory while parsing array with many initializers

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2004-10-27 15:43 
---
Debora, I'm working on a patch which should definitely fix this bug. I hope to 
be able to finish it before 4.0 gets out and/or 3.3 is definitely closed.

-- 


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

[Bug target/15286] ICE cause by reload

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-27 15:56 
---
Patch here: .

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug target/17589] segfault while running code compiled with -ftree-vectorize

[berndtrog at yahoo dot com]

--- Additional Comments From berndtrog at yahoo dot com  2004-10-27 15:56 ---
Hmm, there seems to be a relation between the
version of glibc an this bug:

glibc-2.2 segfault
glibc-2.2.5 NO segfault
glibc-2.3.3 NO segfault

Can anyone try 
make check-gcc RUNTESTFLAGS="vect.exp" 
with an old distribution(glibc-2.2) on a sse2 system?

-- 


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

[Bug c/18180] Disable special handling of functions with --freestanding

[alex dot neyman at auriga dot ru]

--- Additional Comments From alex dot neyman at auriga dot ru  2004-10-27 16:01 
---
The bug 14411 was submitted by me as well, though from a different email 
address. I updated the patch in it to apply to 4.0. 
 
 

-- 


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

[Bug c++/18182] New: Incorrect processing of __attribute__ by the C++ parser

[uweigand at gcc dot gnu dot org]

The C++ parser appears to ignore attributes that apply to nested declarators.

E.g. when trying to define an 'SImode-pointer to int' by 
  typedef int * __attribute__ ((mode (SI))) t;
on s390x-ibm-linux, the C++ parser silently ignores the attribute.

The following test case:

#include 
typedef int * __attribute__ ((mode (SI))) t;

int main (void)
{
  t x;
  printf ("%d %d\n", sizeof (x), sizeof (*x));
}

gives the correct result ("4 4") when compiled with gcc,
but the incorrect result "8 4" when compiled with g++.

[ For a simpler test case on systems without non-Pmode pointers,
try using an invalid mode like:
typedef int * __attribute__ ((mode (TI))) t;
With gcc, this gives an error; g++ accepts the code. ]

See the discussion at 
http://gcc.gnu.org/ml/gcc/2004-10/msg01081.html
for further details.

-- 
   Summary: Incorrect processing of __attribute__ by the C++ parser
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uweigand at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug middle-end/17926] [4.0 Regression] infinite loop in LAPACK test at -Os and -O2

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2004-10-27 16:27 ---
I'll see if I can reduce it a little.

-- 


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

[Bug c/18183] New: Warning when supposedly unused parameters are used

[terra at gnome dot org]

It would be nice to get a warning for the code below when bar is used.
Using something documented as unused is likely a bug.

void
foo (int __attribute__((unused)) bar)
{
  bar++;
}

> gcc-3.4 -W -Wunused -Wall -O2 -c ~/foo.c
>

-- 
   Summary: Warning when supposedly unused parameters are used
   Product: gcc
   Version: 3.4.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: terra at gnome dot org
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=18183

[Bug c/18183] Warning when supposedly unused parameters are used

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-27 16:34 
---
I think there was another bug about this and it was closed because we use unused to 
mean it might be 
unused not that it is just unused.

-- 


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

[Bug tree-optimization/18184] New: Tree optimizers ignore pointer modes

[uweigand at gcc dot gnu dot org]

Using pointers of non-default mode via __attribute__ ((mode)) 
produces incorrect code in many cases as the tree optimizers
treat an __attribute__ ((mode) qualified pointer type as 
equivalent to the corresponding non-qualified type.
(This is a regression over 3.4 introduced by the tree-ssa merge.)

As an example, the follow code ICEs on s390x-ibm-linux,
because the tree optimizers have removed the required type
conversion as 'useless':

struct test;
typedef int * __attribute__ ((mode (SI))) test_ptr32;
typedef struct test *test_ptr64;

int
test (test_ptr32 *a, test_ptr64 *b)
{
  return *a == *b;
}

See the discussion at:
http://gcc.gnu.org/ml/gcc/2004-10/msg00775.html
for more details.

-- 
   Summary: Tree optimizers ignore pointer modes
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uweigand at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug tree-optimization/18184] [4.0 Regression] Tree optimizers ignore pointer modes

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-27 16:46 
---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2004-10-27 16:46:37
   date||
Summary|Tree optimizers ignore  |[4.0 Regression] Tree
   |pointer modes   |optimizers ignore pointer
   ||modes
   Target Milestone|--- |4.0.0


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

[Bug tree-optimization/18184] [4.0 Regression] Tree optimizers ignore pointer modes

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-27 16:58 
---
Patch here: .

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug target/18117] [4.0 Regression] Bootstrap fails on i386-k*bsd-gnu

[robertmh at gnu dot org]

--- Additional Comments From robertmh at gnu dot org  2004-10-27 16:59 ---
I've been sending patches to maintain k*bsd-gnu support since it was started
in GCC, but have no commit rights.  I would gladly become the official
maintainer for that system if you like.

OTOH, if one of the GCC maintainers wants to make a "committment" with
k*bsd-gnu support, that'd be even better.  I encourage you to try the
experimental (but fully functional) distribution we provide at the Debian
project (see below in my signature) for that matter.

In the short term, though, it is most important to apply this patch since
bootstrap will be broken in 4.0 otherwise.

Thanks!

-- 


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

[Bug target/18117] [4.0 Regression] Bootstrap fails on i386-k*bsd-gnu

[robertmh at gnu dot org]

--- Additional Comments From robertmh at gnu dot org  2004-10-27 17:01 ---
Erm, I forgot my mail signature is not quoted here ;)  Please refer to 
http://www.debian.org/ports/kfreebsd-gnu

-- 


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

[Bug preprocessor/18176] Bootstrap fail at FreeBSD 5.3-RC1 (and FreeBSD 5.1) with --enable-bootstrap configure option

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-27 17:03 
---
This is just caused by the fact that there are warnings in libcpp still.

-- 
   What|Removed |Added

  Component|bootstrap   |preprocessor
   Keywords||build


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

[Bug c/18180] Disable special handling of functions with --freestanding

[jsm at polyomino dot org dot uk]

--- Additional Comments From jsm at polyomino dot org dot uk  2004-10-27 17:05 
---
Subject: Re:  Disable special handling of functions with
 --freestanding

On Wed, 27 Oct 2004, alex dot neyman at auriga dot ru wrote:

> The bug 14411 was submitted by me as well, though from a different email 
> address. I updated the patch in it to apply to 4.0. 

You will need to *send the patch to gcc-patches* for reviewers to look at 
it, and iterate as necessary until a version is approved.  See the full 
instructions at  first.  You will need 
to include testcases in the patch, and I suggest naming the setjmp 
attribute something like returns_twice - make it general so it can handle 
vfork as well.  If you don't have the copyright assignment paperwork on 
file yet, start getting it in now.  I don't know whether the present patch 
will require it, but a series of successive patches along those lines 
will.

++ @code{unused}, @code{deprecated}, @code{weak}, @code{malloc}, @code{setjmp},
++ @code{longjmp}, @code{alias}, and @code{nonnull}.  Several other attributes
++ are defined for functions on particular target systems.  Other attributes,
++ including @code{section} are supported for variables declarations

in your patch looks wrong; why add the lines beginning with an extra "+"?

You need two spaces after a "." at the end of a sentence in Texinfo.

K&R-style function definitions are no longer used in GCC.

When adding flags to tree_decl you need to update the comment lower down 
about how many spare bits there are (before another 32-bit word would be 
used).  Note the flags are listed grouped into bytes in the declaration.

`%s' quoting is no longer used in GCC; you should use %qs instead.



-- 


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

[Bug c++/18075] [4.0 Regression] #pragma implementation broken in presence of #pragma ident

[zack at gcc dot gnu dot org]

--- Additional Comments From zack at gcc dot gnu dot org  2004-10-27 17:18 ---
(From update of attachment 7415)
fix mime type, mark as patch


-- 
   What|Removed |Added

   Attachment #7415|text/x-patch|text/plain
  mime type||
Attachment #7415 is|0   |1
  patch||


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

[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-27 17:19 ---

Jason, this is the bug I talked about briefly. Do you think the Redmond offsetof
work is also applicable here?

-- 
   What|Removed |Added

 CC||jason at redhat dot com


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

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

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-10-27 17:22 
---
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg02358.html 

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/18075] [4.0 Regression] #pragma implementation broken in presence of #pragma ident

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-10-27 17:29 
---
Subject: Bug 18075

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-10-27 17:29:31

Modified files:
libcpp : ChangeLog directives.c 

Log message:
PR 18075
* directives.c (do_pragma): Do not defer pragmas which are unknown.
(cpp_handle_deferred_pragma): Add cast to silence warning.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libcpp/ChangeLog.diff?cvsroot=gcc&r1=1.35&r2=1.36
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libcpp/directives.c.diff?cvsroot=gcc&r1=1.7&r2=1.8



-- 


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

[Bug c++/18075] [4.0 Regression] #pragma implementation broken in presence of #pragma ident

[zack at gcc dot gnu dot org]

--- Additional Comments From zack at gcc dot gnu dot org  2004-10-27 17:31 ---
fixed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug java/17265] [4.0 Regression] Libjava doesn't build

[zack at gcc dot gnu dot org]

-- 
Bug 17265 depends on bug 18075, which changed state.

Bug 18075 Summary: [4.0 Regression] #pragma implementation broken in presence of 
#pragma ident
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18075

   What|Old Value   |New Value

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[Bug tree-optimization/18179] vectorizer: wrong alignment/step/initial-address computed for struct accesses

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-27 17:44 
---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2004-10-27 17:44:19
   date||


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

[Bug java/17265] [4.0 Regression] Libjava doesn't build

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-10-27 17:45 
---
Libjava builds for me now on sparc64-sun-solaris2.9 and sparc-sun-solaris2.8. 
Testsuite results are decent (42 and 24 failures respectively).


-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug java/17574] [meta-bug] gcj and libgcj 4.0 tracking PR

[ebotcazou at gcc dot gnu dot org]

-- 
Bug 17574 depends on bug 17265, which changed state.

Bug 17265 Summary: [4.0 Regression] Libjava doesn't build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17265

   What|Old Value   |New Value

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

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

[Bug tree-optimization/17133] [4.0 Regression] wrong code with -ftree-lim

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-10-27 17:45 
---
Subject: Bug 17133

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-10-27 17:45:25

Modified files:
gcc: ChangeLog tree-cfg.c tree-dfa.c 
 tree-flow-inline.h tree-flow.h tree-into-ssa.c 
 tree-optimize.c tree-pass.h tree-pretty-print.c 
 tree-ssa-ccp.c tree-ssa-dce.c 
 tree-ssa-loop-im.c tree-ssa-loop-manip.c 
 tree-ssa-operands.c tree-ssa-operands.h 
 tree-ssa.c tree-vectorizer.c 

Log message:
2004-10-27  Daniel Berlin <[EMAIL PROTECTED]>

Fix PR tree-optimization/17133

* tree-cfg.c (rewrite_to_new_ssa_names_bb): Also rewrite must
def kill operand.

* tree-flow-inline.h: V_MUST_DEF_OP became V_MUST_DEF_RESULT.
(get_v_must_def_result_ptr): Modify for new structure of
v_must_defs array.
(get_v_must_def_kill_ptr): New.
(op_iter_next_use): Add support for the kill that occurs in V_MUST_DEFs.
(op_iter_next_tree): Ditto. Also V_MAY_DEF_OP became V_MAY_DEF_RESULT.
(op_iter_next_def): V_MAY_DEF_OP became V_MAY_DEF_RESULT.
(op_iter_init): Initialize new mustu members.
(op_iter_next_mustdef): New function.
(op_iter_init_mustdef): Ditto.

* tree-flow.h (rewrite_def_def_chains): New function.

* tree-into-ssa.c (mark_def_sites): Handle mustdefkill operands.
(ssa_mark_def_sites): Ditto.
(rewrite_stmt): Ditto.
(ssa_rewrite_stmt): Ditto.
(rewrite_blocks): Factor out from rewrite_into_ssa.
(mark_def_block_sites): Ditto.
(rewrite_def_def_chains): New function, just rewrites def-def
chains without phi node insertion.

* tree-pass.h (TODO_fix_def_def_chains): New todo flag.

* tree-optimize.c (execute_todo): Handle TODO_fix_def_def_chains.

* tree-pretty-print.c (dump_vops): Print out MUST_DEF's so that
they include the rhs now.

* tree-ssa-ccp.c (visit_assignment): V_MUST_DEF_OP became
V_MUST_DEF_RESULT.

* tree-ssa-dce.c (mark_operand_necessary): Add phionly argument.
Update callers.
(mark_really_necessary_kill_operand_phis): New function.
(perform_tree_ssa_dce): Call it.
(pass_dce): Add TODO_fix_def_def_chains.
(pass_cd_dce): Ditto.

* tree-ssa-loop-im.c (determine_max_movement): Look at kills as
well.
(rewrite_mem_refs): Ditto.

* tree-ssa-loop-manip.c (find_uses_to_rename_stmt): Look at kills
as well.

* tree-ssa-operands.c (allocate_v_may_def_optype):
v_may_def_operand_type_t became v_def_use_operand_type_t.
(allocate_v_must_def_optype) Ditto.
(finalize_ssa_v_must_defs): Update for new operand type, as well
as setting the use portion as well.
(copy_virtual_operands): Copy the kill operand as well.
(create_ssa_artficial_load_stmt): V_MUST_DEF_OP became
V_MUST_DEF_RESULT.

* tree-ssa-operands.h (v_may_def_operand_type): Renamed to
v_def_use_operand_type.
(v_must_def_optype_d): Use v_def_use_operand_type.
(V_MUST_DEF_OP_*): Renamed to V_MUST_DEF_RESULT_*
(V_MUST_DEF_KILL_*): New macros.
(struct ssa_operand_iterator_d): Add num_v_mustu and v_mustu_i
members.
Rename existing must_i and num_v_must members to mustd_i and
num_v_mustd.
(SSA_OP_VMUSTDEFKILL): New flag.
(SSA_OP_VIRTUAL_KILLS): New flag.
(SSA_OP_ALL_OPERANDS): Add in SSA_OP_ALL_KILLS.
(SSA_OP_ALL_KILLS): New flag.
(FOR_EACH_SSA_MUSTDEF_OPERAND): New macro.

* tree-ssa.c (verify_ssa): Verify virtual kills as well.

* tree-vectorizer.c (vect_create_data_ref_ptr): V_MUST_DEF_OP
became V_MUST_DEF_RESULT.
(rename_variables_in_bb): Rename kill pointer as well.

* tree-dfa.c (compute_immediate_uses_for_stmt): Add kills into the
immediate uses.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6047&r2=2.6048
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-cfg.c.diff?cvsroot=gcc&r1=2.89&r2=2.90
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-dfa.c.diff?cvsroot=gcc&r1=2.40&r2=2.41
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-flow-inline.h.diff?cvsroot=gcc&r1=2.24&r2=2.25
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-flow.h.diff?cvsroot=gcc&r1=2.54&r2=2.55
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-into-ssa.c.diff?cvsroot=gcc&r1=2.25&r2=2.26
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-optimize.c.diff?cvsroot=gcc&r1=2.57&r2=2.58
http://gcc.gn

[Bug c++/15172] [3.3/3.4 regression] Copy constructor optimization in aggregate initialization

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-10-27 17:59 
---
Reproducible on x86 too.


-- 
   What|Removed |Added

 CC|ebotcazou 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=15172

[Bug preprocessor/18176] Bootstrap fail at FreeBSD 5.3-RC1 (and FreeBSD 5.1) with --enable-bootstrap configure option

[wanderer at rsu dot ru]

--- Additional Comments From wanderer at rsu dot ru  2004-10-27 18:01 ---
Warning fixed in patch for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18075

But now bootstrap terminate with errors:
---8X---
/usr/home/wanderer/pkg/build/gcc/obj/prev-gcc/xgcc -
B/usr/home/wanderer/pkg/build/gcc/obj/prev-gcc/ -B/home/wanderer/pkg/gcc/i386-
unknown-freebsd5.3/bin/  -I/home/wanderer/pkg/build/gcc/src/gcc/gcc/libcpp -
I. -I/home/wanderer/pkg/build/gcc/src/gcc/gcc/libcpp/../include -
I/home/wanderer/pkg/build/gcc/src/gcc/gcc/libcpp/include  -O2 -g -fomit-frame-
pointer -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -
Wold-style-definition -pedantic -Wno-long-long -Werror -
I/home/wanderer/pkg/build/gcc/src/gcc/gcc/libcpp -I. -
I/home/wanderer/pkg/build/gcc/src/gcc/gcc/libcpp/../include -
I/home/wanderer/pkg/build/gcc/src/gcc/gcc/libcpp/include  -
c /home/wanderer/pkg/build/gcc/src/gcc/gcc/libcpp/macro.c
cc1: warnings being treated as errors
/home/wanderer/pkg/build/gcc/src/gcc/gcc/libcpp/macro.c: In 
function 'padding_token':
/home/wanderer/pkg/build/gcc/src/gcc/gcc/libcpp/macro.c:913: warning: 
assignment discards qualifiers from pointer target type
/home/wanderer/pkg/build/gcc/src/gcc/gcc/libcpp/macro.c: In 
function 'create_iso_definition':
/home/wanderer/pkg/build/gcc/src/gcc/gcc/libcpp/macro.c:1422: warning: 
assignment from incompatible pointer type
gmake[2]: *** [macro.o] Error 1
gmake[2]: Leaving directory `/usr/home/wanderer/pkg/build/gcc/obj/stage2-
libcpp'
gmake[1]: *** [all-stage2-libcpp] Error 2
gmake[1]: Leaving directory `/usr/home/wanderer/pkg/build/gcc/obj'
gmake: *** [stage2-bubble] Error 2
---X8---


-- 


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

[Bug libstdc++/18185] New: Unhandled exceptions leak

[velco at fadata dot bg]

When a thread is terminated from within an exception handling block, exception
object(s) (__cxa_exeption) are leaked, as the TSD destructor for __cxa_eh_globals
instance does delete them.  The following program demonstrates the leak.  A patch
and a ChangeLog entry follows.

#include 

static void *
foo (void *p)
{
  try
{
  throw 0;
}
  catch (int)
{
  pthread_exit (0);
}
}

int
main ()
{
  pthread_t t;
  void *p;

  pthread_create (&t, 0, foo, 0);
  pthread_join (t, &p);
  return 0;
}


--- /home/velco/src/gcc-4.0/libstdc++-v3/libsupc++/eh_globals.cc.~1.6.~ Tue Aug
 3 09:45:54 2004
+++ /home/velco/src/gcc-4.0/libstdc++-v3/libsupc++/eh_globals.ccWed Oct 27
20:50:17 2004
@@ -48,7 +48,19 @@
 get_globals_dtor (void *ptr)
 {
   if (ptr)
-std::free (ptr);
+{
+  __cxa_exception *exn, *next;
+
+  exn = ((__cxa_eh_globals *) ptr)->caughtExceptions;
+  while (exn)
+   {
+ next = exn->nextException;
+ _Unwind_DeleteException (&exn->unwindHeader);
+ exn = next;
+   }
+
+  std::free (ptr);
+}
 }
 
 static void

2004-10-27  Momchil Velikov  <[EMAIL PROTECTED]>

* libsupc++/eh_globals.cc (get_globals_dtor): Delete unhandled
exceptions.

-- 
   Summary: Unhandled exceptions leak
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: velco at fadata dot bg
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug other/18186] New: Spelling error

[christophe dot jaillet at wanadoo dot fr]

In option.c, optionlist and common.opt the word "parameter" is 
written "paramter" (e between m and t is missing).

It shows up on the first lines when doing a "cc1 --version | less"

-- 
   Summary: Spelling error
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P2
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: christophe dot jaillet at wanadoo dot fr
CC: gcc-bugs at gcc dot gnu dot org


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

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

[mark at gcc dot gnu dot org]

--- Additional Comments From mark at gcc dot gnu dot org  2004-10-27 19:07 ---
Got another report for this on powerpc-apple-darwin7.5.0, gcj 3.4.2.
I have added a workaround for it in GNU Classpath CVS

--- java/security/cert/X509Certificate.java 20 Oct 2004 07:11:40 - 1.7
+++ java/security/cert/X509Certificate.java 27 Oct 2004 19:03:07 -
@@ -135,7 +135,9 @@
  * @author Mark Benvenuto
  * @author Casey Marshall ([EMAIL PROTECTED])
  */
-public abstract class X509Certificate extends Certificate implements X509Extension
+public abstract class X509Certificate
+  extends java.security.cert.Certificate  // XXX workaround for gcj bug #17845
+  implements X509Extension
 {
   private static final long serialVersionUID = -2491127588187038216L;

-- 
   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WORKSFORME  |


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

[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-27 19:14 ---
Does this mean that you've actually been able to duplicate the bug?

Can you at least let me have a backtrace?

Surely it's better to fix the bug than install a workaround in Classpath.


-- 


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

[Bug libgcj/18187] New: ava.util.WeakHashMap$WeakEntrySet.next() throws NoSuchElementException during GC

[ovidr at users dot sourceforge dot net]

During garbage collection, the WeakHashMap will throw a NoSuchElementException 
when performing the methods: 

.keySet().toArray()
.clear();

and maybe more.  Sun's java does not.

Here is an example:

gcc version 4.0.0 20041014 (experimental)
gcj -main=WH WH.java

import java.util.*;

public class WH {

  public static void main(String[] s) {

Thread t = new Thread() {
  public void run() {
while (true) {
  System.gc();
  try {
Thread.sleep(1000);
  } catch (Exception e) {
  }
}
  }
};

WeakHashMap w = new WeakHashMap();
for (int i = 0; i < 1; i++)
  w.put(new WH(), null);

t.setDaemon(true);
t.start();

try {
  w.clear();
} catch (NoSuchElementException n) {
  System.out.println("From .clear(): ");
  n.printStackTrace();
}

for (int i = 0; i < 1; i++)
  w.put(new WH(), null);

try {
for (int i = 0; i < 1000; i++)
  System.out.print("["+w.keySet().toArray().length+"]");

} catch (NoSuchElementException n) {
  System.out.println("iFrom .toArray():");
  n.printStackTrace();
}

  }

}

-- 
   Summary: ava.util.WeakHashMap$WeakEntrySet.next() throws
NoSuchElementException during GC
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ovidr at users dot sourceforge dot net
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=18187

[Bug libgcj/18187] ava.util.WeakHashMap$WeakEntrySet.next() throws NoSuchElementException during GC

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-27 19:46 
---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug libgcj/16998] WeakHashMap iterator can throw NoSuchElementException unexpectedly

[pinskia at gcc dot gnu dot org]

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

-- 
   What|Removed |Added

 CC||ovidr at users dot
   ||sourceforge dot net


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

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

[wilson at tuliptree dot org]

--- Additional Comments From wilson at tuliptree dot org  2004-10-27 19:50 ---
Subject: Re:  bad unwind info due to multiple returns
(missing epilogue)

On Wed, 2004-10-27 at 04:05, davidm at hpl dot hp dot com wrote:
> This was on a Debian/unstable system.  How do you run configure?

I just use ../gcc/configure most of the time.  I have libunwind 0.98
installed, but then you likely have it or a more recent version
installed also.

You are configuring in the source directory?  That is supposed to work,
but no gcc developers ever do that, so it is often broken.  Usually this
gives some kind of obvious build failure though.  It seems unlikely that
this would result in an infinite loop in the compiler.   FYI The
preferred way to build gcc is something like
  mkdir objdir
  cd objdir
  ../gcc/configure ...

I don't know when I last ran apt-get.  I can try updating and doing
another build.  Also, I have debian/unstable on an alternate partition. 
I can try booting it, running apt-get, and trying a build there, in case
it is debian/unstable specific.

Right now, I am testing the patch for 13158.  I need to wait for this to
finish first.



-- 


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

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

[mark at gcc dot gnu dot org]

--- Additional Comments From mark at gcc dot gnu dot org  2004-10-27 20:06 ---
> Does this mean that you've actually been able to duplicate the bug?
> Can you at least let me have a backtrace?
> Surely it's better to fix the bug than install a workaround in Classpath.

I have seen the bug occur on a cygwin machine to which I don't have access
anymore. I thought it was related to the file system being case-insensitive so
jikes was used to do the source to byte code compilation.

Chris is now seeing it on his powerpc machine.
The workaround at least makes it possible to keep working on GNU Classpath. We
have a policy that GNU Classpath (releases) need to be able to be build with the
latest GCC release (and possibly older versions or CVS).

There isn't a backtrace since it just gives this error messages:

../../classpath/java/security/cert/X509Certificate.java:143: error: Class
`java.security.cert.X509Certificate' can't subclass interface
`java.security.Certificate'.
   public abstract class X509Certificate extends Certificate implements
X509Extension
 ^
../../classpath/java/security/cert/X509Certificate.java:0: confused by earlier
errors, bailing out

Is there a trick to get you the backtrace you need to further analyze why this
is happening?

-- 
   What|Removed |Added

 CC||dog at gnu dot org


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

[Bug bootstrap/17832] [4.0 Regression] Bootstrap broken by fixincludes failures

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-10-27 20:14 
---
Subject: Bug 17832

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-10-27 20:13:58

Modified files:
fixincludes: ChangeLog fixfixes.c 

Log message:
PR bootstrap/17832

* fixfixes.c (main): Check for _PC_NAME_MAX.
--

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/fixincludes/ChangeLog.diff?cvsroot=gcc&r1=1.11&r2=1.12
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/fixincludes/fixfixes.c.diff?cvsroot=gcc&r1=1.2&r2=1.3



-- 


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

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

[tromey at gcc dot gnu dot org]

-- 
   What|Removed |Added

 CC||tromey at gcc dot gnu dot
   ||org


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

[Bug bootstrap/17832] [4.0 Regression] Bootstrap broken by fixincludes failures

[aaronavay62 at aaronwl dot com]

--- Additional Comments From aaronavay62 at aaronwl dot com  2004-10-27 20:17 
---
Fixed on mainline.  I think this is the end of fixincludes problems for Windows.


-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug other/17462] Cannot compile fixincl.c on windows hosts

[aaronavay62 at aaronwl dot com]

-- 
Bug 17462 depends on bug 17832, which changed state.

Bug 17832 Summary: [4.0 Regression] Bootstrap broken by fixincludes failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17832

   What|Old Value   |New Value

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

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

[Bug bootstrap/18107] [4.0 Regression] Bootstrap fails on i686-pc-mingw32

[aaronavay62 at aaronwl dot com]

-- 
Bug 18107 depends on bug 17832, which changed state.

Bug 17832 Summary: [4.0 Regression] Bootstrap broken by fixincludes failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17832

   What|Old Value   |New Value

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

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

[Bug target/17956] [4.0 Regression] ICE in rs6000_emit_minmax, config/rs6000/rs6000.c:11725

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-10-27 20:19 
---
Subject: Bug 17956

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-10-27 20:18:46

Modified files:
gcc: ChangeLog 
gcc/config/rs6000: rs6000.md 

Log message:
PR target/17956
* config/rs6000/rs6000.md (maxsf3): Add !flag_trapping_math to
final condition.
(minsf3): Same.
(maxdf3): Same.
(mindf3): Same.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6051&r2=2.6052
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000.md.diff?cvsroot=gcc&r1=1.326&r2=1.327



-- 


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