[Bug libgcj/20775] Crash in libgcj.so on linux alpha

[tsv at solvo dot ru]

--- Additional Comments From tsv at solvo dot ru  2005-04-06 07:11 ---
No, it is UP machine. Yes - it crashes at the same place all the time.

-- 


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

[Bug bootstrap/20783] New: [4.1 Regression] Bootstrapping 4.1 takes 50% longer than 4.0

[Thomas dot Koenig at online dot de]

I just ran two parallel bootstraps of mainline and 4.0,
on a single-processor Athlon XP 2600+.

Configuration was with --prefix=$HOME --enable-languages=c,f95
in both cases.

The 4.0 build, which finished earlier, used

real58m0.437s
user25m1.021s
sys 1m36.735s

The 4.1 build used

real67m24.663s
user38m19.830s
sys 1m41.125s

The compiler used for boostrapping was

$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1/configure --prefix=/home/ig25 
--enable-languages=c,f95
Thread model: posix
gcc version 4.1.0 20050402 (experimental)

$ cat /proc/cpuinfo
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 6
model   : 8
model name  : AMD Athlon(TM) XP 2600+
stepping: 1
cpu MHz : 2083.203
cache size  : 256 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmovpat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow
bogomips: 4128.76

-- 
   Summary: [4.1 Regression] Bootstrapping 4.1 takes 50% longer than
4.0
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux-gnu


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

[Bug target/11787] always call memcpy for block move in mips16

[stephane dot mutz at philips dot com]

--- Additional Comments From stephane dot mutz at philips dot com  
2005-04-06 08:07 ---
I understand your point. However, this sometimes results in a significant drop 
of performance forcing to revert to MIPS2 / MIPS32. This partly spoils the 
usefulness of MIPS16. I think the option of forcing memcpy calls iso inline in 
function calls should be left to the developer and not a defacto choice of the 
compiler.


-- 


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

[Bug target/17824] Hard-coded AS and LD in c4x.h

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-06 
08:11 ---
Subject: Bug 17824

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

Modified files:
gcc: ChangeLog 
gcc/config/c4x : c4x.h 

Log message:
2005-04-06  Ralf Corsepius  <[EMAIL PROTECTED]>

PR target/17824
* config/c4x/c4x.h (ASM_PROG, LD_PROG): Remove.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8163&r2=2.8164
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/c4x/c4x.h.diff?cvsroot=gcc&r1=1.152&r2=1.153



-- 


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

[Bug target/17824] Hard-coded AS and LD in c4x.h

[ralf dot corsepius at rtems dot org]

--- Additional Comments From ralf dot corsepius at rtems dot org  
2005-04-06 08:15 ---
OK to apply this patch to 4.0, too?

-- 


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

[Bug libfortran/20108] incorrect run time error on formatted read

[fxcoudert at gcc dot gnu dot org]

--- Additional Comments From fxcoudert at gcc dot gnu dot org  2005-04-06 
08:45 ---
I'm not sure, but I guess this one should go away with Thomas' patches for EOR
handling (see PR 20131, comment 5 for a link).

-- 
   What|Removed |Added

   Last reconfirmed|2005-02-21 21:44:19 |2005-04-06 08:45:11
   date||


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

[Bug c/20784] New: Impossible to mute warning: imaginary constants are a GCC extension

[aaronavay62 at aaronwl dot com]

float complex c = 1.if;  // warning: imaginary constants are a GCC extension

This warning is generated when -pedantic is specified.  This creates problems 
with perfectly valid standard C99 code such as the following.

double complex d = I;

No particular placement of __extension__ seems to be able to make this warning 
go away.

-- 
   Summary: Impossible to mute warning: imaginary constants are a
GCC extension
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: minor
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aaronavay62 at aaronwl dot com
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug libstdc++/20758] operator-(const T&, const complex&) vs operator-(const complex&, const complex

[gdr at integrable-solutions dot net]

--- Additional Comments From gdr at integrable-solutions dot net  
2005-04-06 08:59 ---
Subject: Re:  operator-(const T&, const complex&) vs operator-(const 
complex&, const complex&)

"pcarlini at suse dot de" <[EMAIL PROTECTED]> writes:

| Gaby, what do you think about this issue? In fact, it seems to me that an
| implementation strictly following the standard (26.2.6/6), or complex1.patch
| here, doesn't not incur in this problem...

I think we need more careful analysis and tracking of both C99, C++ and
LIA-3.  Coming to think about it, Bruce I still own you a reply about
the logarithm ; I'll send you all references I have in a separate
mail.

-- Gaby


-- 


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

[Bug c/20785] New: Pragma STDC CX_LIMITED_RANGE unimplemented

[aaronavay62 at aaronwl dot com]

#pragma STDC CX_LIMITED_RANGE off

is currently unimplemented, and generates the warning:

warning: ignoring #pragma STDC CX_LIMITED_RANGE

-- 
   Summary: Pragma STDC CX_LIMITED_RANGE unimplemented
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aaronavay62 at aaronwl dot com
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug libstdc++/20758] operator-(const T&, const complex&) vs operator-(const complex&, const complex

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-04-06 09:17 
---
> I think we need more careful analysis and tracking of both C99, C++ and
> LIA-3.

Ok, thanks, I will start on such analysis (in particulat wrt LIA-3). A minor
issue with complex1.patch is that probably unary operator- is cheaper than
a full subtraction, still, at the end, probably something similar will be
needed. I should also remark that this is definitely not a regression and
that, indeed, the current C++ standard, completely ignores signed zero, NAN,
INF, etc...

-- 


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

[Bug libstdc++/20758] operator-(const T&, const complex&) vs operator-(const complex&, const complex

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2005-04-06 09:27 
---
By the way, about the log, now that you mention it, it's really a pity that we
cannot enable and use the builtin due to the namespace issues with the clog
stream. We should really figure out a way to resolve this annoying issue, humpf!

-- 


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

[Bug fortran/20786] New: Can't use AINT intrinsic with KIND parameter

[fxcoudert at gcc dot gnu dot org]

The following code is valid:

$ cat aint_mismatch.f 
  implicit none
  real(4) r
  r = aint (r,kind=8)
  end
$ gfortran aint_mismatch.f
aint_mismatch.f: In function ‘MAIN__’:
aint_mismatch.f:3: internal compiler error: in emit_move_insn, at expr.c:3085

The ICE disappears if kind=4 or if r is a real(8). This should be easy to fix,
since other similar intrinsics (such as ANINT) doesn't exhibit such ICE.

-- 
   Summary: Can't use AINT intrinsic with KIND parameter
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
OtherBugsDependingO 19292
 nThis:


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

[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran

[fxcoudert at gcc dot gnu dot org]

-- 
   What|Removed |Added

  BugsThisDependsOn||20786


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

[Bug fortran/20279] gfortran: ICE on valid code, in gfc_get_symbol_decl

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2005-04-06 
09:55 ---
This got fixed today.

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

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug fortran/15959] ICE and assertion failure in trans-decl.c with character initialization

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2005-04-06 
09:55 ---
*** Bug 20279 has been marked as a duplicate of this bug. ***

-- 


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

[Bug fortran/20279] gfortran: ICE on valid code, in gfc_get_symbol_decl

[reichelt at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.0.0


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

[Bug libstdc++/20787] New: Implement resolution of DR 130 [Ready] in v7-branch

[pcarlini at suse dot de]

Just an internal reminder. A couple of notes:
1- I'm pretty sure cannot be implemented in v6, but would be happy to be wrong.
2- Maybe a similar fix is needed also for .

-- 
   Summary: Implement resolution of DR 130 [Ready] in v7-branch
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libstdc++
AssignedTo: pcarlini at suse dot de
ReportedBy: pcarlini at suse dot de
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug libstdc++/20787] Implement resolution of DR 130 [Ready] in v7-branch

[pcarlini at suse dot de]

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-04-06 10:50:57
   date||


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

[Bug bootstrap/20783] [4.1 Regression] Bootstrapping 4.1 takes 50% longer than 4.0

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2005-04-06 
10:51 ---
mainline has checking enabled by default. Try bootstrapping it with --disable-
checking before comparing numbers.

Plus there is a regression we already know of, see:
http://gcc.gnu.org/ml/gcc/2005-04/msg00184.html

-- 
   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug libstdc++/20787] Implement resolution of DR 130 [Ready] in v7-branch

[pcarlini at suse dot de]

-- 
   What|Removed |Added

   Severity|normal  |enhancement


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

[Bug c/20784] Impossible to mute warning: imaginary constants are a GCC extension

[jsm28 at gcc dot gnu dot org]

--- Additional Comments From jsm28 at gcc dot gnu dot org  2005-04-06 11:15 
---


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

-- 
   What|Removed |Added

 CC||jsm28 at gcc dot gnu dot org
 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants

[jsm28 at gcc dot gnu dot org]

--- Additional Comments From jsm28 at gcc dot gnu dot org  2005-04-06 11:15 
---
*** Bug 20784 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||aaronavay62 at aaronwl dot
   ||com


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

[Bug c/20785] Pragma STDC CX_LIMITED_RANGE unimplemented

[jsm28 at gcc dot gnu dot org]

--- Additional Comments From jsm28 at gcc dot gnu dot org  2005-04-06 11:21 
---
We know.  I'm not sure how much use there is opening PRs for major points listed
as Missing at  unless there are particular
subtle points which might be missed in implementation which would be better
noted in a PR.

Stephen Moshier started a C99 pragma implementation some time ago.  I have his
code (version of June 2001, not a complete implementation, only does anything
with FENV_ACCESS) and at least the testcases might be useful; I'll attach the
files to this bug as we may as well use the bug now it's open.


-- 
   What|Removed |Added

 CC||jsm28 at gcc dot gnu dot org
OtherBugsDependingO||16989
  nThis||
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-04-06 11:21:42
   date||


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

[Bug target/17245] [3.3 regression] ICE compiling gsl-1.5 statistics/lag1.c

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-06 
11:54 ---
Subject: Bug 17245

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

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

Log message:
PR target/17245
* config/sparc/sparc.c (legitimate_address_p): Remove 'imm2'.
Revert 2004-10-08 patch.  Reject TFmode LO_SUM in 32-bit mode.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8167&r2=2.8168
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/sparc/sparc.c.diff?cvsroot=gcc&r1=1.360&r2=1.361



-- 


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

[Bug target/17245] [3.3 regression] ICE compiling gsl-1.5 statistics/lag1.c

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-06 
11:56 ---
Subject: Bug 17245

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-04-06 11:56:34

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

Log message:
PR target/17245
* config/sparc/sparc.c (legitimate_address_p): Remove 'imm2'.
Revert 2004-10-08 patch.  Reject TFmode LO_SUM in 32-bit mode.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.138&r2=2.7592.2.139
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/sparc/sparc.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.354.8.2&r2=1.354.8.3



-- 


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

[Bug target/17245] [3.3 regression] ICE compiling gsl-1.5 statistics/lag1.c

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-06 
11:59 ---
Subject: Bug 17245

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

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

Log message:
PR target/17245
* config/sparc/sparc.c (legitimate_address_p): Remove 'imm2'.
Revert 2004-10-08 patch.  Reject TFmode LO_SUM in 32-bit mode.

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.833&r2=2.2326.2.834
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/sparc/sparc.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.271.4.23&r2=1.271.4.24



-- 


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

[Bug c/20785] Pragma STDC CX_LIMITED_RANGE unimplemented

[aaronavay62 at aaronwl dot com]

--- Additional Comments From aaronavay62 at aaronwl dot com  2005-04-06 
12:13 ---
I opened the PR so I would have a tangible place to point to in a FIXME in some
code, saying "when this bug is fixed, uncomment this."  Perhaps though, for
things of this sort, it would be better to point to the status page.  However,
one can add oneself to the CC list for a bug much easier than he can add himself
to the "CC list" for a webpage.


-- 


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

[Bug fortran/20788] New: Loading libgfortran.so clobbers C redirection of stdin

[ripley at stats dot ox dot ac dot uk]

When using a C main program that has in any way loaded libgfortran.so,
redirected C stdin is broken.  This is used by the R project
 to run scripts, and even occurs even if
the main (C) program has dlopen-ed a DSO with compiled Fortran code
linked against libgfortran.so.

There is separate bug that stops GFORTRAN_STDIN_UNIT being set to a 
negative value to avoid the initialization that causes the problem.

-- 
   Summary: Loading libgfortran.so clobbers C redirection of stdin
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ripley at stats dot ox dot ac dot uk
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=20788

[Bug fortran/20788] Loading libgfortran.so clobbers C redirection of stdin

[ripley at stats dot ox dot ac dot uk]

--- Additional Comments From ripley at stats dot ox dot ac dot uk  
2005-04-06 12:27 ---
Created an attachment (id=8547)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8547&action=view)
Reproduction details, partial fix.


-- 


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

[Bug target/20781] 64 bit shift by non-constant implemented as libcall on PPC32

[dberlin at dberlin dot org]

--- Additional Comments From dberlin at gcc dot gnu dot org  2005-04-06 
12:34 ---
Subject: Re:  64 bit shift by non-constant implemented as
libcall on PPC32

On Wed, 2005-04-06 at 06:46 +, pinskia at gcc dot gnu dot org wrote:
> --- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-06 
> 06:46 ---
> Hmm on powerpc-darwin on the mainline I get:

So apparently it's implemented, but not for ppc linux?
Weird.




-- 


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

[Bug target/20781] 64 bit shift by non-constant implemented as libcall on PPC32

[dberlin at dberlin dot org]

--- Additional Comments From dberlin at gcc dot gnu dot org  2005-04-06 
12:35 ---
Subject: Re:  64 bit shift by non-constant implemented as
libcall on PPC32

On Wed, 2005-04-06 at 06:46 +, pinskia at gcc dot gnu dot org wrote:
> --- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-06 
> 06:46 ---
> Hmm on powerpc-darwin on the mainline I get:

Oh, forget it, i was trying an older compiler.
Sigh.
Damn you PATH
e



-- 


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

[Bug c++/20789] New: segv

[igodard at pacbell dot net]

 

-- 
   Summary: segv
   Product: gcc
   Version: 3.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/20789] segv

[igodard at pacbell dot net]

--- Additional Comments From igodard at pacbell dot net  2005-04-06 12:37 
---
Created an attachment (id=8548)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8548&action=view)
compiler output


-- 


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

[Bug c++/20789] segv

[igodard at pacbell dot net]

--- Additional Comments From igodard at pacbell dot net  2005-04-06 12:37 
---
Created an attachment (id=8549)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8549&action=view)
source code (compressed)


-- 


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

[Bug fortran/17229] parser confused by arithmetic if inside an if

[fxcoudert at gcc dot gnu dot org]

--- Additional Comments From fxcoudert at gcc dot gnu dot org  2005-04-06 
12:38 ---
But then, some scientific libraries are using it (I was about to report the same
bug when a search pointed to this one). And since it works on any compiler I
could find (including g77), I'd change that into a bug (and not enhancement).

-- 
   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
   Severity|enhancement |normal
   Last reconfirmed|2004-11-11 05:26:38 |2005-04-06 12:38:33
   date||


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

[Bug AWT/20790] New: libjawt.so must be renamed

[fitzsim at redhat dot com]

libjawt.so needs to be renamed "libgcj-jawt.so".  Because it is installed in the
standard library prefix and has the same name as Sun's AWT Native Interface
implementation library, proprietary JVMs pick up libgcj's libjawt.so and not
Sun's.  We can install a symlink in java-gcj-compat so that applications
building against libjawt.so will not see the difference between libgcj-jawt.so
and libjawt.so.

-- 
   Summary: libjawt.so must be renamed
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: AWT
AssignedTo: fitzsim at redhat dot com
ReportedBy: fitzsim at redhat 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=20790

[Bug fortran/17229] parser confused by arithmetic if inside an if

[prthomas at drfccad dot cea dot fr]

--- Additional Comments From prthomas at drfccad dot cea dot fr  2005-04-06 
13:22 ---
Subject: RE:  parser confused by arithmetic if inside a
n if


> But then, some scientific libraries are using it (I was about 
> to report the same
> bug when a search pointed to this one). And since it works on 
> any compiler I
> could find (including g77), I'd change that into a bug (and 
> not enhancement).
> 

Neither Tobi not Andrew said that it is not a bug..

Paul


-- 


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

[Bug other/20791] New: visibilty options don't work

[oliverst at online dot de]

When compiling a source file with "-fvisibility=hidden" and/or
"-fvisibility-inlines-hidden" I get the following error for each function in the
file (happens with C and C++ front-end):

C:/DOKUME~1/OSTOEN~2/LOKALE~1/Temp/ccCC.s: Assembler messages:
C:/DOKUME~1/OSTOEN~2/LOKALE~1/Temp/ccCC.s:5: Error: unknown pseudo-op: 
`.hidden'

I am using a MinGW32 build of GCC, so I am not quite sure, if thise feature is
for MinGW32, but if it won't work for MinGW32, it should be disabled.

Here is my specs:

Using built-in specs.
Target: i686-pc-mingw32
Configured with: /datal/gcc/gcc/configure --prefix=/datal/gcc/build/wingcc
--build=i686-pc-linux-gnu --host=i686-pc-mingw32 --target=i686-pc-mingw32
--enable-languages=c,c++,java --with-gcc --with-gnu-as --with-gnu-ld
--enable-threads=win32 --disable-nls --disable-win32-registry --disable-shared
--disable-debug --without-newlib --enable-libgcj --disable-java-awt --without-x
--enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter
--enable-hash-synchronization --enable-sjlj-exceptions --enable-libgcj-multifile
--enable-libgcj-mingw-osapi=ansi
Thread model: win32
gcc version 4.0.0 20050324 (prerelease)

-- 
   Summary: visibilty options don't work
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oliverst at online dot de
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug other/20791] visibilty options don't work

[oliverst at online dot de]

-- 
   What|Removed |Added

   GCC host triplet||i686-pc-mingw32


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

[Bug fortran/17229] parser confused by arithmetic if inside an if

[fxcoudert at gcc dot gnu dot org]

--- Additional Comments From fxcoudert at gcc dot gnu dot org  2005-04-06 
13:52 ---
Paul: Before I changed the severity field, it was "enhancement".

All: I was a patch for this one, I will polish the testcase a bit and post it in
a few days.

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |fxcoudert at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-04-06 12:38:33 |2005-04-06 13:52:39
   date||


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

[Bug other/20792] New: [4.1 Regression] target.opt messages missing from gcc.pot

[jsm28 at gcc dot gnu dot org]

If gcc.pot is regenerated on mainline, the help information for options moved to
.opt files, other than those for the current target, are missing from the
generated gcc.pot file.  A special version of options.c with the messages for
all languages and targets may need generating for the use of exgettext.

The same problem applies for lang.opt files on the 4.0 branch - messages for
languages which aren't enabled are missing from gcc.pot - though it can be
worked around by enabling all languages, if the system used has all the
prerequisites for all languages.  If there is a safe fix, I think it should be
applied to 4.0 branch as well to avoid problems with missing messages there.

-- 
   Summary: [4.1 Regression] target.opt messages missing from
gcc.pot
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsm28 at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,rsandifo at gcc dot gnu
dot org


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

[Bug target/20726] gcc-4.0.0_beta20050326 failed to build

[selecter at spray dot se]

--- Additional Comments From selecter at spray dot se  2005-04-06 14:01 
---
Fixincludes is running on compilation, but I had to patch pthread manually. It's
gentoo problem - they do not support gcc-4.0.0 yet.

-- 
   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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

[Bug c++/57] [DR 325] GCC can't parse a non-parenthesized comma in a template-id within a default argument

[liu_gw at 163 dot com]

--- Additional Comments From liu_gw at 163 dot com  2005-04-06 14:10 ---
(From update of attachment 8546)
gcc v3.4.3:
gcc/parser.c


-- 


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

[Bug tree-optimization/20076] [3.3/3.4 Regression] __builtin_return(__builtin_apply()) inlined incorrectly

[jsm28 at gcc dot gnu dot org]

--- Additional Comments From jsm28 at gcc dot gnu dot org  2005-04-06 14:18 
---
gcc.dg/builtin-apply4.c execution test is failing on mainline on ia64-hpux. 
gcc-testresults also shows it failing on 4.0 branch on ia64-linux.

-- 
   What|Removed |Added

 CC||jakub at gcc dot gnu dot
   ||org, jsm28 at gcc dot gnu
   ||dot org


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

[Bug bootstrap/20783] [4.1 Regression] Bootstrapping 4.1 takes 50% longer than 4.0

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2005-04-06 
14:21 ---
This goes away when --disable-checking is specified for 4.0
and 4.1.

Closing as invalid.

-- 
   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


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

[Bug other/20792] [4.1 Regression] target.opt messages missing from gcc.pot

[rsandifo at gcc dot gnu dot org]

--- Additional Comments From rsandifo at gcc dot gnu dot org  2005-04-06 
14:28 ---
Thanks for the heads-up.  Will try to fix this ASAP.


-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rsandifo at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-04-06 14:28:26
   date||


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

[Bug middle-end/20793] New: allocate_initial_values does not adjust register liveness information

[amylaar at gcc dot gnu dot org]

When ALLOCATE_INITIAL_VALUE, allocate_initial_values will replace
a pseudo with a machine-defined value, but it won't update the
register liveness information.  This can lead to incorrect global
allocations.
An incomplete conflict list can be observed compiling execute/pr17377.c
at -O2 for sh64-elf.  If this leads to an actual execution failure
depends on details of if-conversion, the machine description and
register allocation, which are subject to change.

-- 
   Summary: allocate_initial_values does not adjust register
liveness information
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P2
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c/20794] New: [4.0/4.1 Regression] Miscompilation with __attribute ((aligned))

[jakub at gcc dot gnu dot org]

extern void abort (void);

typedef int T __attribute__((aligned));
struct S { T a[2]; } s;
void *p[2];

int
main (void)
{
  p[0] = &s.a[0];
  p[1] = &s.a[1];
  if (p[0] == p[1])
abort ();
  return 0;
}

is miscompiled on at least i386, x86_64, ppc32 and ppc64, at all optimization
levels.  Works correctly in C++.

-- 
   Summary: [4.0/4.1 Regression] Miscompilation with __attribute
((aligned))
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug middle-end/20794] [4.0/4.1 Regression] Miscompilation with __attribute ((aligned))

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-06 
14:52 ---
I want to say this is a middle-end problem as the trees look ok:
  p[0] = &s.a[0]{lb: 0 sz: 0};
  D.1140 = &s.a[1]{lb: 0 sz: 0};
  p[1] = D.1140;
  D.1141 = p[0];
  D.1142 = p[1];
  if (D.1141 == D.1142) goto ; else goto ;

Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|c   |middle-end
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-04-06 14:52:28
   date||
   Target Milestone|--- |4.0.0


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

[Bug c++/20795] New: ICE in assign_parms

[jakub at gcc dot gnu dot org]

struct S { union {} a; } __attribute__((aligned));
void check (struct S arg)
{
}

ICEs on x86-64 at any optimization level.  Works fine in C.

-- 
   Summary: ICE in assign_parms
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: x86_64-linux


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

[Bug fortran/17229] parser confused by arithmetic if inside an if

[fxcoudert at gcc dot gnu dot org]

--- Additional Comments From fxcoudert at gcc dot gnu dot org  2005-04-06 
14:57 ---
Patch proposed here: http://gcc.gnu.org/ml/fortran/2005-04/msg00104.html

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug middle-end/20795] ICE in assign_parms

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-06 
14:57 ---
Even though this is only seen with the C++ front-end, I would almost think this 
is a middle-end 
problem.

-- 
   What|Removed |Added

  Component|c++ |middle-end
   Keywords||ice-on-valid-code


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

[Bug c++/20796] New: -Wunused warns for variable passed to constructor via function-style cast

[timb at bluearc dot com]

With -Wunused, this:

struct A { A(int); };
struct S { S(A); };
void f()
{
int i = 0;
S s(A(i));
}

generates a spurious warning:

test.cpp: In function `void f()':
test.cpp:5: warning: unused variable `int i'

(Happens in Debian's 3.3.5-12, 3.4.3-12, 4.0-0pre9)

-- 
   Summary: -Wunused warns for variable passed to constructor via
function-style cast
   Product: gcc
   Version: 3.3.5
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: timb at bluearc dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i486-linux
  GCC host triplet: i486-linux
GCC target triplet: i486-linux


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

[Bug other/20791] visibilty options don't work

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-06 
15:03 ---
Did you build GCC your self?  If not, did you get the version of binutils that 
the person was offering.  
And yes we have a check while configuring to enable/disabling visiblity.

-- 


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

[Bug middle-end/20794] [4.0/4.1 Regression] Miscompilation with __attribute ((aligned))

[jakub at gcc dot gnu dot org]

--- Additional Comments From jakub at gcc dot gnu dot org  2005-04-06 15:05 
---
Doesn't need to be in struct, and the requested alignment must be bigger
than sizeof (int) to reproduce.
extern void abort (void);

typedef int T __attribute__((aligned (8)));
T a[2];
void *p[2];

int
main (void)
{
  p[0] = &a[0];
  p[1] = &a[1];
  if (p[0] == p[1])
abort ();
  return 0;
}
fails as well.

Note that the requested alignment is apparently honored by neither GCC 3.4 and
earlier in C, nor in G++ (3.4 as well as 4.0) for the individual array members,
only the whole array is aligned as if the attribute was present on the array
itself, not on the member type.

So we probably first need to answer whether that layout is correct or if we want
an ABI change here.

-- 


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

[Bug middle-end/20793] allocate_initial_values does not adjust register liveness information

[amylaar at gcc dot gnu dot org]

--- Additional Comments From amylaar at gcc dot gnu dot org  2005-04-06 
15:09 ---
Created an attachment (id=8550)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8550&action=view)
proposed patch


-- 


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

[Bug fortran/20786] Can't use AINT intrinsic with KIND parameter

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-06 
15:11 ---
Confirmed, the problem is most likely we are missing a fold_convert somewhere 
converting from 
double down to float (sorry for using C types but it makes it easier sometimes).

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-04-06 15:11:53
   date||


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

[Bug middle-end/20606] ICE in make_edges, at cfgbuild.c:327 on x86_64 (with O2 - not with no optimizations)

[aph at gcc dot gnu dot org]

--- Additional Comments From aph at gcc dot gnu dot org  2005-04-06 15:13 
---
This only happens with -O2.  -O is a reasonable workaround for the time being.

-- 
   What|Removed |Added

   Last reconfirmed|2005-03-23 19:29:03 |2005-04-06 15:13:38
   date||


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

[Bug c++/57] [DR 325] GCC can't parse a non-parenthesized comma in a template-id within a default argument

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-06 
15:18 ---
(In reply to comment #26)
> (From update of attachment 8546)
> gcc v3.4.3:
> gcc/parser.c

I should note this bug is suspended.  This is because the standard is unclear 
at what is the correct 
behavior.  See DR 325 for all the details.

-- 
   What|Removed |Added

 CC||liu_gw at 163 dot com


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

[Bug AWT/20790] libjawt.so must be renamed

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-06 
15:19 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-04-06 15:19:49
   date||


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

[Bug target/20781] 64 bit shift by non-constant implemented as libcall on PPC32

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-06 
15:24 ---
This was fixed in 4.0.0.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Keywords||missed-optimization
  Known to fail||3.4.4
  Known to work||4.0.0 4.1.0
 Resolution||FIXED
   Target Milestone|--- |4.0.0


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

[Bug c++/20796] -Wunused warns for variable passed to constructor via function-style cast

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-06 
15:31 ---
The following expression does not do what you think it does:
S s(A(i));

It declares a function which returns S as the type and takes an A which is 
named i.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/19312] [3.4 Regression] ICE in stabilize_call when throwing a copy

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-06 
15:35 ---
Subject: Bug 19312

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED]   2005-04-06 15:35:33

Modified files:
gcc/cp : ChangeLog tree.c 

Log message:
PR c++/19312
* tree.c (stabilize_init): Don't bother trying to stabilize
something with no side-effects.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3892.2.210&r2=1.3892.2.211
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/tree.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.360.4.10&r2=1.360.4.11



-- 


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

[Bug ada/20797] New: Code gen creating out-of-bounds addresses on legit code

[nick at sqrt dot co dot uk]

Looking at GCC 4.0 20050318, and configuring as a cross-compiler for ARM/Linux
thusly:
 
$ mkdir arm-linux ; cd arm-linux
$ ../configure --prefix=/opt/gcc-linux --target=arm-linux-elf
--enable-languages=c,ada

Once the gnat1 binary is built, just type this from the gcc/ada directory.

$ ../../arm-linux/gcc/gnat1 nlists.adb -O2 -o nlists.s -gnatpg

Turning off optimisation makes no difference to the resulting problem.


The compiled version of Nlists::First() results in:

nlists__first:
@ args = 0, pretend = 0, frame = 0, outgoing = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
cmp r0, #0
ldrne   r2, .L320
mov r1, #1191182336
ldrne   r3, [r2, #0]
add ip, r0, r0, asl #1
add r1, r1, #8781824
add r1, r1, #35840
addne   r3, r3, ip, asl #2
ldrne   r0, [r3, r1]
@ lr needed for prologue
bx  lr
.L320:
.word   nlists__lists__tableX

The problem I see is an out-of-bounds memory access here:
ldrne   r0, [r3, r1]

FYI, on my machine:
   R1 == 0x47868c00
   R3 == 0xb97d3a9c

Here, R3 points to a legitimate memory address
Surely R1 is a little large ?

-- 
   Summary: Code gen creating out-of-bounds addresses on legit code
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nick at sqrt dot co dot uk
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: arm-linux-elf


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

[Bug c++/20789] segv

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Attachment #8548|application/octet-stream|text/plain
  mime type||


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

[Bug c++/20212] [4.0/4.1 Regression] attribute unused vs. member function template

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-06 
15:52 ---
Subject: Bug 20212

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED]   2005-04-06 15:52:24

Modified files:
gcc/cp : ChangeLog pt.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/g++.dg/warn: Wunused-11.C 

Log message:
PR c++/20212
* pt.c (regenerate_decl_from_template): Copy attributes for
parameters from the pattern to the instantiation.

PR c++/20212
* g++.dg/warn/Wunused-11.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.4648.2.27&r2=1.4648.2.28
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.978.2.5&r2=1.978.2.6
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.109&r2=1.5084.2.110
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/warn/Wunused-11.C.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1



-- 


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

[Bug c++/20789] segv

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-06 
15:53 ---
This is related to PR 17323.

-- 
   What|Removed |Added

  BugsThisDependsOn||17323


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

[Bug c++/20212] [4.0/4.1 Regression] attribute unused vs. member function template

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-06 
15:55 ---
Subject: Bug 20212

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-04-06 15:55:00

Modified files:
gcc/cp : ChangeLog pt.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/g++.dg/warn: Wunused-11.C 

Log message:
PR c++/20212
* pt.c (regenerate_decl_from_template): Copy attributes for
parameters from the pattern to the instantiation.

PR c++/20212
* g++.dg/warn/Wunused-11.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4692&r2=1.4693
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&r1=1.990&r2=1.991
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5295&r2=1.5296
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/warn/Wunused-11.C.diff?cvsroot=gcc&r1=1.1&r2=1.2



-- 


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

[Bug c++/20212] [4.0/4.1 Regression] attribute unused vs. member function template

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2005-04-06 
15:56 ---
Fixed in 4.0.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libfortran/20788] Loading libgfortran.so clobbers C redirection of stdin

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Severity|critical|normal
  Component|fortran |libfortran


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

[Bug target/20781] 64 bit shift by non-constant implemented as libcall on PPC32

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-06 
16:26 ---
This was fixed by:
http://www.linux-mips.org/archives/linux-mips/2004-08/msg00176.html

-- 


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

[Bug target/20795] ICE in assign_parms

[jakub at gcc dot gnu dot org]

--- Additional Comments From jakub at gcc dot gnu dot org  2005-04-06 16:46 
---
It actually looks like a x86-64 target bug.
FUNCTION_ARG returns (parallel:BLK [])


-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
  Component|middle-end  |target
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-04-06 16:46:48
   date||


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

[Bug middle-end/16172] simple function generates an memmove() call instead of inlining

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-06 
17:31 ---
Note I don't think it is an inappropiate call to memmove.

-- 
   What|Removed |Added

Summary|simple function generates an|simple function generates an
   |inappropriate memmove() call|memmove() call instead of
   ||inlining


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

[Bug tree-optimization/19794] [meta-bug] Jump threading related bugs

[law at redhat dot com]

--- Additional Comments From law at redhat dot com  2005-04-06 17:41 ---
Subject: Re:  [meta-bug] Jump threading
related bugs

On Wed, 2005-04-06 at 06:38 +, pinskia at gcc dot gnu dot org wrote:
> --- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-06 
> 06:38 ---
> (In reply to comment #7)
> > They don't even bear-out on other x86 platforms -- my older P3 and AMD
> > boxes don't show the same kind of big improvement (they show a small
> > improvements).  However, both of my P4s show big improvements.
> 
> Huh, both of those targets are still x86.
And my point was that the improvement from everything I've managed to
gather so far is either specific to the P4 or possibly specific to the
size of the cache on the P4.




>  So what about on say Power4 or PowerPC 970?
I don't have either of those.  My non-x86 boxes are all, err, old.  My
PPC I think is a 233MHZ PPC750.  It'd probably take more than I day to
get things built and running on that ancient box.  I only use it to 
diagnose PPC specific problems.

jeff




-- 


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

[Bug ada/20515] "stdcall" imports are not handled correctly

[p dot obry at wanadoo dot fr]

--- Additional Comments From p dot obry at wanadoo dot fr  2005-04-06 18:14 
---
(In reply to comment #5)

Ok, the documentation is missing the part where Stdcall is equivalent to
C on UNIX. This is a feature implemented some time ago. Will fix the doc.

So, what about the proposal on #4 ?

Pascal.


-- 


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

[Bug bootstrap/20780] gcc 4.0 from cvs head fails to build

[federico dot carminati at cern dot ch]

--- Additional Comments From federico dot carminati at cern dot ch  
2005-04-06 18:17 ---
Builds now succeeds with the new cctools. Thanks a lot.

-- 
   What|Removed |Added

 Status|RESOLVED|VERIFIED


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

[Bug web/16384] http://gcc.gnu.org/gcc-3.3/changes.html changelog for gcc-3.3.4 missing

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-06 
18:23 ---
This has been fixed for a while now.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug fortran/20798] New: Valid program fails to assemble

[federico dot carminati at cern dot ch]

I am linking with gfortran the following valid program

  program bug
  CHARACTER*2 KSHAP(3)
  DATA KSHAP/'A', 2*' '/
  end

and I obtain

[/Users/fca] /opt/gcc-4_0/bin/gfortran bug.f -o bug
/var/tmp//ccNLauLD.s:5:Bad Absolute Expression, absolute 0 assumed.
/var/tmp//ccNLauLD.s:5:Repeat < 0, .space ignored

-- 
   Summary: Valid program fails to assemble
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: federico dot carminati at cern dot ch
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: powerpc-apple-darwin7.8.0
  GCC host triplet: powerpc-apple-darwin7.8.0
GCC target triplet: powerpc-apple-darwin7.8.0


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

[Bug rtl-optimization/12837] The mod vpt does not work on PPC

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-06 
18:26 ---
Fixed in 4.1.0 by:
2005-03-29  Dale Johannesen <[EMAIL PROTECTED]>

* Makefile.in (value-prof.o): New dependencies on $(DIAGNOSTIC_H)
$(TREE_H) and $(COVERAGE_H).
* coverage.c (compute_checksum): Use DECL_NAME not DECL_ASSEMBLER_NAME.
* opts.c (common_handle_option): Enable tree-based value transforms.
* toplev.c (process_options): Ditto.
* value-prof.h (struct histogram_value_t): Redefine. "Adjust" below
refers to references to this type.
* tree-flow.h: (struct stmt_ann_d): Add histograms field.
* rtl-profile.c (rtl_gen_interval_profiler): Adjust. Remove checks
for may_be_more, may_be_less.
(rtl_gen_pow2_profiler): Adjust.
(rtl_gen_one_value_profiler_no_edge_manip): Adjust.
(rtl_gen_one_value_profiler): Adjust.
(rtl_gen_const_delta_profiler): Adjust.
* tree-profile.c (tree_gen_interval_profiler): Implement.
(tree_gen_pow2_profiler): Ditto.
..

-- 
   What|Removed |Added

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


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

[Bug fortran/20798] Valid program fails to assemble

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-06 
18:27 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug fortran/20063] n*'xxxx' disables padding

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-06 
18:27 ---
*** Bug 20798 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||federico dot carminati at
   ||cern dot ch


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

[Bug target/18421] ICE in reload_cse_simplify_operands, at postreload.c:391

[joel at gcc dot gnu dot org]

--- Additional Comments From joel at gcc dot gnu dot org  2005-04-06 18:29 
---
I can confirm this for m68k-rtems with gcc 4.0.0 20050303.  This looks like the
ICE that happens for us in our pppd stack on the Coldfire.   

I also confirm that the small test case in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18421#c7 occurs.



-- 
   What|Removed |Added

   Last reconfirmed|2004-11-14 13:53:05 |2005-04-06 18:29:51
   date||


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

[Bug fortran/16939] Pointers not passed as subroutine arguments

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-06 
18:37 ---
This looks to me (a non fortran person) a duplicate of bug 17192.

-- 
   What|Removed |Added

  BugsThisDependsOn||17192


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

[Bug other/20791] visibilty options don't work

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug tree-optimization/20656] No strength reduction for a simple testcase

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-06 
18:50 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-04-06 18:50:25
   date||


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

[Bug target/11787] always call memcpy for block move in mips16

[echristo at redhat dot com]

--- Additional Comments From echristo at redhat dot com  2005-04-06 18:57 
---
There's also the problem that the current mechanism for doing unaligned
loads/stores are not valid mips16 instructions, and therefore we couldn't rely
upon the patterns unless we knew that the addresses were aligned. If we get
support in gcc to not generate ldl/ldr instructions then this could be
revisited. I think until then I'm going to suspend this.

-- 
   What|Removed |Added

 Status|ASSIGNED|SUSPENDED


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

[Bug other/20792] [4.1 Regression] target.opt messages missing from gcc.pot

[rsandifo at gcc dot gnu dot org]

--- Additional Comments From rsandifo at gcc dot gnu dot org  2005-04-06 
19:02 ---
Patch posted here:

http://gcc.gnu.org/ml/gcc-patches/2005-04/msg00708.html


-- 
   What|Removed |Added

   Keywords||patch


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

[Bug target/20670] IA-64 exception mechanism erase $f29

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-06 
19:11 ---
Subject: Bug 20670

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_3-branch
Changes by: [EMAIL PROTECTED]   2005-04-06 19:11:36

Modified files:
gcc: ChangeLog 
gcc/config/ia64: unwind-ia64.c 

Log message:
Fix problem with reg f29 being corrupted when unwinding stack.
PR target/20670
* unwind-ia64.c (uw_intall_context): Add missing load of r27.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.16114.2.1063&r2=1.16114.2.1064
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/unwind-ia64.c.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.13.2.4&r2=1.13.2.5



-- 


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

[Bug tree-optimization/19794] [meta-bug] Jump threading related bugs

[law at redhat dot com]

--- Additional Comments From law at redhat dot com  2005-04-06 19:21 ---
More info.

It appears that threading one specific jump is responsible for triggering
the big speedup.  And it could cause the kind of effects we're seeing.

Basically we're threading a conditional branch to a loop exit test back to the
top of the loop.  This has the effect of creating nested loops.  This in turn
causes the register allocators to make different choices in regards to what
values should be kept in registers and which end up on the stack (and at
what offsets each object appears on the stack).

That could cause the kind of decrease in L2 activity I'm seeing, particularly
with the recursive nature of the function in question.  I've got a few more
tests to run before I claim this to be the cause of the huge improvement.
But this is the best theory which fits the data I've seen so far.

-- 


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

[Bug c++/20799] New: Legal code generate wrong binary

[federico dot carminati at cern dot ch]

I try to make a bundle with the the following legal code

#include 

void *operator new(size_t size)
{  void *vp;  return vp;}

void *operator new[](size_t size)
{   return ::operator new(size);}


and I obtain

[/Users/fca/nd] /opt/gcc-4_0/bin/g++ -c NewDelete.cxx 
[/Users/fca/nd] /opt/gcc-4_0/bin/g++ -g -bundle -undefined dynamic_lookup -o 
libNewDelete.so 
NewDelete.o 
/usr/bin/ld: NewDelete.o has external relocation entries in non-writable 
section (__TEXT,__textcoal_nt) 
for symbols:
operator new(unsigned long)
collect2: ld returned 1 exit status

It works with gcc version 3.3 20030304 (Apple Computer, Inc. build 1671)

-- 
   Summary: Legal code generate wrong binary
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: federico dot carminati at cern dot ch
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: powerpc-apple-darwin7.8.0
  GCC host triplet: powerpc-apple-darwin7.8.0
GCC target triplet: powerpc-apple-darwin7.8.0


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

[Bug fortran/16939] Pointers not passed as subroutine arguments

[paulthomas2 at wanadoo dot fr]

--- Additional Comments From paulthomas2 at wanadoo dot fr  2005-04-06 
19:26 ---
Subject: Re:  Pointers not passed as subroutine arguments


- Original Message - 
From: "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 06, 2005 8:37 PM
Subject: [Bug fortran/16939] Pointers not passed as subroutine arguments


>
> --- Additional Comments From pinskia at gcc dot gnu dot org 
> 2005-04-06 18:37 ---
> This looks to me (a non fortran person) a duplicate of bug 17192.
>
> -- 
>   What|Removed |Added
> 
>  BugsThisDependsOn||17192
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16939
>
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
> 




-- 


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

[Bug target/20799] [4.0/4.1 Regression] Legal code generate wrong binary

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 CC||geoffk at gcc dot gnu dot
   ||org
   Severity|critical|normal
  Component|c++ |target
   Keywords||wrong-code
  Known to fail||4.0.0 4.1.0
  Known to work||3.3.3
Summary|Legal code generate wrong   |[4.0/4.1 Regression] Legal
   |binary  |code generate wrong binary
   Target Milestone|--- |4.0.0


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

[Bug fortran/16939] Pointers not passed as subroutine arguments

[paulthomas2 at wanadoo dot fr]

--- Additional Comments From paulthomas2 at wanadoo dot fr  2005-04-06 
19:31 ---
Subject: Re:  Pointers not passed as subroutine arguments

I think that it is,. in principle.  The examples are a bit strange 
though.

Paul

- Original Message - 
From: "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 06, 2005 8:37 PM
Subject: [Bug fortran/16939] Pointers not passed as subroutine arguments


>
> --- Additional Comments From pinskia at gcc dot gnu dot org 
> 2005-04-06 18:37 ---
> This looks to me (a non fortran person) a duplicate of bug 17192.
>
> -- 
>   What|Removed |Added
> 
>  BugsThisDependsOn||17192
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16939
>
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
> 




-- 


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

[Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols

[amylaar at gcc dot gnu dot org]

--- Additional Comments From amylaar at gcc dot gnu dot org  2005-04-06 
19:32 ---
(In reply to comment #17)
> Subject: Re:  [4.0/4.1 regression] shared SH libgcc is
>  exporting too many symbols
> 
> "joern dot rennecke at st dot com" <[EMAIL PROTECTED]> writes:
> 
> [LIB1FUNCS_ST]
> > Won't this have the effect that any of the referenced symbols remain
> > undefined in libgc_s.so, and will get a GOT (and in 4.0 even a PLT
> > entry) in libgcc.so? 
> 
> You can avoid this problem by including libgcc.a in the final link of
> libgcc_s.so.  Every global symbol in libgcc.a is or ought to be hidden
> (that being a goal of all the work I put in on libgcc construction
> last year) so the effect will be that libgcc_s.so gets private copies
> of everything that it actually uses, but nothing more.
> 
I just had a look, and actually there appears to be no variable called
LIB1FUNCS_ST.  There is one called LIB2FUNCS_ST, but that's a place for
machine-independent static libgcc2 parts, and one called
LIB2FUNCS_STATIC_EXTRA.  The latter is actually a list of filenames, no
a list of pieces inside lib1funcs.asm, so I couldn't use it without major
butchery of the SH assembler support functions.

-- 


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

[Bug target/20617] [4.0/4.1 regression] shared SH libgcc is exporting too many symbols

[zack at codesourcery dot com]

--- Additional Comments From zack at codesourcery dot com  2005-04-06 20:03 
---
Subject: Re:  [4.0/4.1 regression] shared SH libgcc is
 exporting too many symbols

"amylaar at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:

> I just had a look, and actually there appears to be no variable called
> LIB1FUNCS_ST.

... so add one.

zw


-- 


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

[Bug other/20791] visibilty options don't work

[oliverst at online dot de]

--- Additional Comments From oliverst at online dot de  2005-04-06 20:56 
---
I didn't build GCC 4.0.0 myself, I got it from this site:

http://www.thisiscool.com/gcc_mingw.htm

and he is offering a complete MinGW package. Looking at the list of components
he put in, we can see, that it says "binutils-2.15.94-20050118-1", so I guess
it's a build done by the MinGW guys.

-- 


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

[Bug middle-end/19225] [3.4 regression] g++.dg/eh/omit-frame-pointer2.C fails with -fpic/-fPIC on i686-pc-linux-gnu

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-06 
21:02 ---
Subject: Bug 19225

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED]   2005-04-06 21:01:53

Modified files:
gcc: ChangeLog calls.c 

Log message:
2005-04-06  Dale Johannesen  <[EMAIL PROTECTED]>

PR middle-end/19225
* calls.c (expand_call):  Flush pending deferrals before
throwing call.

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.834&r2=2.2326.2.835
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/calls.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.315.2.7&r2=1.315.2.8



-- 


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

[Bug middle-end/19225] [3.4 regression] g++.dg/eh/omit-frame-pointer2.C fails with -fpic/-fPIC on i686-pc-linux-gnu

[dalej at gcc dot gnu dot org]

--- Additional Comments From dalej at gcc dot gnu dot org  2005-04-06 21:02 
---
Also fixed in 4.0 and 3.4 branches.  Closing.



-- 
   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


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

[Bug other/20792] [4.1 Regression] target.opt messages missing from gcc.pot

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-06 
22:42 ---
Subject: Bug 20792

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-04-06 22:42:46

Modified files:
gcc: ChangeLog Makefile.in optc-gen.awk 
gcc/po : ChangeLog exgettext gcc.pot 

Log message:
gcc/
PR other/20792
* Makefile.in (gcc.pot): Remove options.c dependency.
* optc-gen.awk: Don't quote help strings with N_().

gcc/po/
PR other/20792
* exgettext: Don't scan options.c.  Scan .opt files for help strings.
* gcc.pot: Regenerate.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8175&r2=2.8176
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/Makefile.in.diff?cvsroot=gcc&r1=1.1464&r2=1.1465
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/optc-gen.awk.diff?cvsroot=gcc&r1=2.2&r2=2.3
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/po/ChangeLog.diff?cvsroot=gcc&r1=1.140&r2=1.141
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/po/exgettext.diff?cvsroot=gcc&r1=1.10&r2=1.11
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/po/gcc.pot.diff?cvsroot=gcc&r1=1.34&r2=1.35



-- 


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

[Bug target/20799] [4.0/4.1 Regression] bad relocs for new/delete overrides

[geoffk at gcc dot gnu dot org]

--- Additional Comments From geoffk at gcc dot gnu dot org  2005-04-06 
23:12 ---
There's a local change on apple-ppc-branch that appears to fix this, but for 
some reason it was not 
submitted to FSF:

1.22.2.24.2.44 (zlaski   01-Mar-05):   /* APPLE LOCAL coalescing */ 
1.22.2.24.2.44 (zlaski   01-Mar-05):   /* Removed special handling of 
'::operator new' and '::operator 
delete'.  */


-- 
   What|Removed |Added

 CC||zlaski at apple dot com
   Keywords|wrong-code  |rejects-valid
Summary|[4.0/4.1 Regression] Legal  |[4.0/4.1 Regression] bad
   |code generate wrong binary  |relocs for new/delete
   ||overrides


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