[Bug middle-end/36593] [4.4 Regression]: gfortran.dg/default_format_1.f90, 22_locale/num_get/get/char/2.cc

[hp at gcc dot gnu dot org]

--- Comment #3 from hp at gcc dot gnu dot org  2008-06-23 07:12 ---
An obvious and plausible explanation.  It appears it's also correct; simulator
traces and trial link-time replacement gives it's _strtod_r (in
newlib/libc/stdlib/strtod.c) that's "miscompiled". On closer look it seems the
cause is the ugly type-punning done in the dword0 and dword1 macros (defined in
mprec.h in the same directory):

typedef union { double d; __ULong L[2]; } U;
#define dword0(x) ((U*)&x)->L[0]
#define dword1(x) ((U*)&x)->L[1]
with common use of dword0/1 as lvalues and mixing in non-cast assignments.
Ugh.


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


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

[Bug middle-end/36593] [4.4 Regression]: gfortran.dg/default_format_1.f90, 22_locale/num_get/get/char/2.cc

[hp at gcc dot gnu dot org]

--- Comment #4 from hp at gcc dot gnu dot org  2008-06-23 07:38 ---
FWIW, I'm about to fix newlib...


-- 


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

[Bug fortran/36597] OpenMP 3: _OPENMP should be 200805 instead of 200505

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2008-06-23 08:44 ---
Oh, I wasn't aware Fortran duplicates this, nor fortran/cpp.c has been around
on the gomp-3_0-branch when I've committed the change.
Will fix up.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|WAITING |ASSIGNED
  Component|middle-end  |fortran
 Ever Confirmed|0   |1
   Last reconfirmed|2008-06-22 12:31:00 |2008-06-23 08:44:09
   date||


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

[Bug fortran/36604] New: ICE on duplicate DATA

[jakub at gcc dot gnu dot org]

program test
  real value(2)
  data value/2*0.0/
  data value/2*0.0/
end

ICEs in gfc_assign_data_value_range - ref->next == NULL, but find_con_by_offset
returned non-NULL (as the data has been set already).  Guess some checking for
duplicate DATA needs to be done and error reported instead of failing
assertions.


-- 
   Summary: ICE on duplicate DATA
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org


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

[Bug middle-end/36593] [4.4 Regression]: gfortran.dg/default_format_1.f90, 22_locale/num_get/get/char/2.cc

[rguenther at suse dot de]

--- Comment #5 from rguenther at suse dot de  2008-06-23 09:48 ---
Subject: Re:  [4.4 Regression]: gfortran.dg/default_format_1.f90,
 22_locale/num_get/get/char/2.cc

On Mon, 23 Jun 2008, hp at gcc dot gnu dot org wrote:

> --- Comment #3 from hp at gcc dot gnu dot org  2008-06-23 07:12 ---
> An obvious and plausible explanation.  It appears it's also correct; simulator
> traces and trial link-time replacement gives it's _strtod_r (in
> newlib/libc/stdlib/strtod.c) that's "miscompiled". On closer look it seems the
> cause is the ugly type-punning done in the dword0 and dword1 macros (defined 
> in
> mprec.h in the same directory):
> 
> typedef union { double d; __ULong L[2]; } U;
> #define dword0(x) ((U*)&x)->L[0]
> #define dword1(x) ((U*)&x)->L[1]
> with common use of dword0/1 as lvalues and mixing in non-cast assignments.
> Ugh.

Note that this type-punning using a union is ok, so it must be something
else (or it is gccs fault in this case).

Richard.


-- 


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

[Bug fortran/24978] ICE in gfc_assign_data_value_range

[dfranke at gcc dot gnu dot org]

--- Comment #17 from dfranke at gcc dot gnu dot org  2008-06-23 09:53 
---
*** Bug 36604 has been marked as a duplicate of this bug. ***


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu dot org


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

[Bug fortran/36604] ICE on duplicate DATA

[dfranke at gcc dot gnu dot org]

--- Comment #1 from dfranke at gcc dot gnu dot org  2008-06-23 09:53 ---


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


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/36482] cris gcc 4.2.3 -Os causes internal compiler error (-O0 works)

[hinko dot kocevar at cetrtapot dot si]

--- Comment #2 from hinko dot kocevar at cetrtapot dot si  2008-06-23 10:05 
---
I can recreate the same error with gcc-4.3.1 and gcc-4.4-20080502. I also fails
to compile linux kernel:
..
  CC  lib/zlib_deflate/deflate_syms.o
(const_int -13 [0xfff3])
net/core/stream.c: In function 'sk_stream_wait_connect':
net/core/stream.c:78: internal compiler error: output_operand: invalid operand
for 'p' modifier
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
{standard input}: Assembler messages:
{standard input}:488: Warning: partial line at end of file ignored
make[3]: *** [net/core/stream.o] Error 1
make[2]: *** [net/core] Error 2
make[1]: *** [net] Error 2
make[1]: *** Waiting for unfinished jobs
  CC  fs/jffs2/readinode.o
  CC  drivers/mtd/mtdsuper.o

..


-- 


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

[Bug tree-optimization/36519] [4.3 Regression] time/memory hog for c++ source.

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2008-06-23 10:11 ---
Subject: Bug 36519

Author: rguenth
Date: Mon Jun 23 10:10:38 2008
New Revision: 137033

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137033
Log:
2008-06-23  Richard Guenther  <[EMAIL PROTECTED]>

PR tree-optimization/36519
* tree-ssa-alias.c (mem_sym_score): Count call-clobbered
unpartitionable SFTs in the usual way.
(compute_memory_partitions): Do partition call-clobbered
unpartitionable SFTs, but make sure to partition all other
SFTs of its parent var into the same partition.

Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/tree-ssa-alias.c


-- 


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

[Bug other/36498] [4.3 Regression] time/memory hog for large c++ source.

[rguenth at gcc dot gnu dot org]

--- Comment #16 from rguenth at gcc dot gnu dot org  2008-06-23 10:13 
---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/36519] [4.3 Regression] time/memory hog for c++ source.

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2008-06-23 10:14 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to fail||4.3.1
 Resolution||FIXED


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

[Bug fortran/36597] OpenMP 3: _OPENMP should be 200805 instead of 200505

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2008-06-23 10:21 ---
Subject: Bug 36597

Author: jakub
Date: Mon Jun 23 10:20:33 2008
New Revision: 137034

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137034
Log:
PR fortran/36597
* cpp.c (cpp_define_builtins): Change _OPENMP value to 200805.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/cpp.c


-- 


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

[Bug c++/36407] [4.3/4.4 regression] ICE with conversion and -fpermissive

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2008-06-23 10:39 ---
Introduced by PR35773.


-- 


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

[Bug c/36605] New: no previous prototype for 'host_detect_local_cpu' in 06/20/08 snapshot of gcc on MIPS Linux

[michael dot a dot richmond at nasa dot gov]

When I attempt to compile the 06/20/08 snapshot of gcc and gfortran on an SGI
box running Debian Linux 4.0 I get the following message:

/home/mrichmon/gcc-4.4-20080620/gcc/config/mips/driver-native.c:37: error: no
previous prototype for 'host_detect_local_cpu'


-- 
   Summary: no previous prototype for 'host_detect_local_cpu' in
06/20/08 snapshot of gcc on MIPS Linux
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michael dot a dot richmond at nasa dot gov


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

[Bug tree-optimization/36508] [4.3 Regression] ICE in compute_antic

[jakub at gcc dot gnu dot org]

--- Comment #12 from jakub at gcc dot gnu dot org  2008-06-23 11:52 ---
Subject: Bug 36508

Author: jakub
Date: Mon Jun 23 11:51:34 2008
New Revision: 137036

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137036
Log:
PR tree-optimization/36508
* tree-ssa-pre.c (compute_antic): Allow num_iterations up to
499, don't check it at all in release compilers.

* gcc.dg/pr36508.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr36508.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-pre.c


-- 


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

[Bug tree-optimization/36508] [4.3 Regression] ICE in compute_antic

[jakub at gcc dot gnu dot org]

--- Comment #14 from jakub at gcc dot gnu dot org  2008-06-23 11:58 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/36508] [4.3 Regression] ICE in compute_antic

[jakub at gcc dot gnu dot org]

--- Comment #13 from jakub at gcc dot gnu dot org  2008-06-23 11:58 ---
Subject: Bug 36508

Author: jakub
Date: Mon Jun 23 11:57:19 2008
New Revision: 137037

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137037
Log:
PR tree-optimization/36508
* tree-ssa-pre.c (compute_antic): Allow num_iterations up to
499, don't check it at all in release compilers.

* gcc.dg/pr36508.c: New test.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/pr36508.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
branches/gcc-4_3-branch/gcc/tree-ssa-pre.c


-- 


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

[Bug target/36583] [4.3/4.4 Regression] ICE on 5282/5206 at -O2

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Priority|P3  |P4
Summary|ICE on 5282/5206 at -O2 |[4.3/4.4 Regression] ICE on
   |[regression]|5282/5206 at -O2
   Target Milestone|--- |4.3.2


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

[Bug target/36533] [4.3/4.4 Regression] Incorrectly assumed aligned_operand

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2008-06-23 13:07 ---
Subject: Bug 36533

Author: jakub
Date: Mon Jun 23 13:06:15 2008
New Revision: 137038

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137038
Log:
PR target/36533
* emit-rtl.c (set_reg_attrs_from_value): Do nothing if
REG is a hard register.

* gcc.target/i386/pr36533.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr36533.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/emit-rtl.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/36597] OpenMP 3: _OPENMP should be 200805 instead of 200505

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2008-06-23 13:07 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/36593] [4.4 Regression]: gfortran.dg/default_format_1.f90, 22_locale/num_get/get/char/2.cc

[hp at gcc dot gnu dot org]

--- Comment #6 from hp at gcc dot gnu dot org  2008-06-23 13:13 ---
(In reply to comment #5)
> Note that this type-punning using a union is ok, so it must be something
> else (or it is gccs fault in this case).

For the record, presumably (re our discussion on irc) you're confusing the
type-punning through a union extension with type-punning through a cast using a
type containing a union.  The "type-punning through a union" extension
(documentation malplaced in invoke.texi @opindex fstrict-aliasing) has an
example that implies that using casts invalidates the extension.  Let's defer
to the gcc@ list to be safe.

Warnings are emitted with -Wstrict-aliasing=1 and 2, but not 3.


-- 


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

[Bug target/36533] [4.3/4.4 Regression] Incorrectly assumed aligned_operand

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2008-06-23 13:16 ---
Subject: Bug 36533

Author: jakub
Date: Mon Jun 23 13:16:07 2008
New Revision: 137039

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137039
Log:
PR target/36533
* emit-rtl.c (set_reg_attrs_from_value): Do nothing if
REG is a hard register.

* gcc.target/i386/pr36533.c: New test.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/pr36533.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/emit-rtl.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug target/36533] [4.3/4.4 Regression] Incorrectly assumed aligned_operand

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2008-06-23 13:19 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/36593] [4.4 Regression]: gfortran.dg/default_format_1.f90, 22_locale/num_get/get/char/2.cc

[hp at gcc dot gnu dot org]

--- Comment #7 from hp at gcc dot gnu dot org  2008-06-23 13:30 ---
Created an attachment (id=15806)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15806&action=view)
preprocessed offending code

Use -O2; should "work" with any 32-bit target.  Note the single (U*) cast for
e.g. aadj1 in _strtod_r used on the left-hand side.  The actual (non-formal)
breakage at hand might be that it's used together with ordinary assignments.


-- 


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

[Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above

[rguenth at gcc dot gnu dot org]

--- Comment #18 from rguenth at gcc dot gnu dot org  2008-06-23 13:39 
---
Created an attachment (id=15807)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15807&action=view)
patch

This "fixes" it for me.  Can you check on hppa?


-- 


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

[Bug fortran/36599] major execution regression for induct.f90 polyhedron benchmark in 4.3.1 on Intel

[howarth at nitro dot med dot uc dot edu]

--- Comment #9 from howarth at nitro dot med dot uc dot edu  2008-06-23 
13:41 ---
Since r134730 represents a new feature and can't be backported, this leaves one
question. Did that change un gcc trunk really 'fix' the problem in the induct
benchmark performance using -fassociative-math and -O3 or just make it go
latent?


-- 


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

[Bug debug/36589] [4.4 Regression]: No debug info for local static variable at -O0

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2008-06-23 13:44 ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01431.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||06/msg01431.html
   Keywords||patch


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

[Bug fortran/36599] major execution regression for induct.f90 polyhedron benchmark in 4.3.1 on Intel

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2008-06-23 14:02 
---
It probably made it latent.


-- 


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

[Bug pch/36606] New: segfault when a pch is included through a header file

[davorin dot ucakar at gmail dot com]

A chain of files like pch -> .h -> .h -> .cpp (pch is included through 2
headers) crashes gcc. This bug is a regression from 4.2.x.

Here's a base64 encoded .tar.gz with example source (sorry, but where's any
option to send an attachments here on buzilla? :/):

H4sIAOutX0gAA+3XQW+CMBgGYM79FY1etotSWsrBZb9id4O2jiZSSYUty7L/vtYo6MFwWOqy+T4X
kgIp5ONtP1bd6zyJLPWKPA9HVuTp+fEkYSzNiiKTBfPjjOWZSGge+8GCbt+WjtJElW87Z+zV68bO
/1ErX/8XvW9n66aJNUcosBTiav196U/1z7jgvv6ccZnQNNYDnbvz+k+NXW87penk8BVUE0L6oad9
q8xuVj0TYmxL69LYh0fySSh1uu2cpemCfJHffgP4iZD/xun1rm7MVqtZFWGOsfz79b5f/6VkPv/C
n0f+b2E+p6qr6w/E+D71+3+M4B+N5l8M+7+Qmc9/Jn0biPzfwLD/v7uyabQ7tADDdr/AwvCvhfz3
lY80x2j/z9mQ/zzs/5wL9P83MTUbq/SGLo8fwbJakqkfMFZfjA1/BZOLdjH8L2irzIb6TuL8ht9+
MQCAO/YNr2yLgQAoAAA=

commands that trigger the bug:
$ g++ precompiled.h
$ g++ Test.cpp
In file included from wrapper.h:1,
 from precompiled.h:1:
cc1plus: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

gcc version:
$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/usr --enable-shared
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --enable-threads=posix
--mandir=/usr/share/man --enable-__cxa_atexit --disable-multilib
--libdir=/usr/lib --libexecdir=/usr/lib --enable-clocale=gnu
--disable-libstdcxx-pch --with-tune=generic
Thread model: posix
gcc version 4.3.1 (GCC)


-- 
   Summary: segfault when a pch is included through a header file
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: pch
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: davorin dot ucakar at gmail dot com
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug fortran/36599] major execution regression for induct.f90 polyhedron benchmark in 4.3.1 on Intel

[howarth at nitro dot med dot uc dot edu]

--- Comment #11 from howarth at nitro dot med dot uc dot edu  2008-06-23 
14:54 ---
Any suggestions for debugging this further in gcc 4.3 branch? Currently we have
the following observations...

1) The problem is specific to -fassociative-math -fno-signed-zeros
-fno-trapping-math (-fno-signed-zeros -fno-trapping-math are required for
-fassociative-math to be active) and happens with -O3 but not -O2.
2) The problem doesn't occur on powerpc-apple-darwin9.
3) The problem occurs on i686-apple-darwin9 at both -m32 and -m64.
4) -funroll-loops -param min-vect-loop-bound=2 suppresses the problem on
Macintel 
(but is it just going latent as with r134730 on gcc trunk)?


-- 


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

[Bug fortran/36599] major execution regression for induct.f90 polyhedron benchmark in 4.3.1 on Intel

[howarth at nitro dot med dot uc dot edu]

--- Comment #12 from howarth at nitro dot med dot uc dot edu  2008-06-23 
15:22 ---
I just checked on an Opteron and a Xeon with Fedora 9. Neither shows the
problem so it may be Core 2 specific.


-- 


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

[Bug c++/36364] [4.1/4.2/4.3/4.4 Regression] Problem with -frepo

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2008-06-23 15:34 ---
Testing a fix.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-06-23 15:34:11
   date||


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

[Bug c++/36607] New: Incorrect type diagnostic on substracting casted char pointers

[rschiele at gmail dot com]

The following little code sample does no longer compile with 4.3 or higher:

struct a {};
void b() {
int a::*m;
a *c;
int p = reinterpret_cast(&(c->*m)) - reinterpret_cast(c);
}

Instead the compiler emits the error message:

bad.cc: In function ‘void b()’:
bad.cc:5: error: aggregate value used where an integer was expected

Though it is clear that this code sample is not perfectly valid according to
the C++ standard since "reinterpret_cast(&(c->*m))" and
"reinterpret_cast(c)" are not part of the same array I would not expect
this kind of behavior since the claim of the compiler that there is something
wrong with types is completely bogus.

Rewriting the code like the following makes the compiler accepting it again:

struct a {};
void b() {
int a::*m;
a *c;
char* d = reinterpret_cast(&(c->*m));
char* e = reinterpret_cast(c);
int p = d - e;
}


-- 
   Summary: Incorrect type diagnostic on substracting casted char
pointers
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rschiele at gmail dot com
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug tree-optimization/36504] [4.3/4.4 regression] ICE when building xorg-server with -O3 -fprefetch-loop-arrays

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2008-06-23 16:27 ---
Sounds related to PR33856.  Does xorg-server really return uninitialized
aggregate?


-- 


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

[Bug tree-optimization/36504] [4.3/4.4 regression] ICE when building xorg-server with -O3 -fprefetch-loop-arrays

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2008-06-23 16:41 ---
tree-ssa-loop-prefetch.c is the only other direct caller of create_data_ref.
PR33856 should catch in get_references_in_stmt all refs without base,
so all that needs to be done is to avoid REFERENCE_CLASS_P's with
!get_base_address () in tree-ssa-loop-prefetch.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rakdver at gcc dot gnu dot
   ||org


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

[Bug target/36584] [4.3/4.4 Regression] Stack is not aligned correctly in recursive function

[ubizjak at gmail dot com]

--- Comment #4 from ubizjak at gmail dot com  2008-06-23 17:36 ---
Author: uros
Date: Mon Jun 23 17:31:12 2008
New Revision: 137045

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137045
Log:
PR middle-end/PR36584
* calls.c (expand_call): Increase alignment for recursive functions.

testsuite/ChangeLog:

PR middle-end/PR36584
* testsuite/gcc.dg/pr36584.c: New test.
* testsuite/gcc.target/i386/local2.c: Remove invalid test.


Added:
trunk/gcc/testsuite/gcc.dg/pr36584.c
Removed:
trunk/gcc/testsuite/gcc.target/i386/local2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/calls.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug bootstrap/33304] Bootstrap failure on solaris2 using cc due to empty macro arguments

[ghazi at gcc dot gnu dot org]

--- Comment #1 from ghazi at gcc dot gnu dot org  2008-06-23 17:50 ---
Patches to fix these problems in c-common.c/tree.c were posted here:

http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00687.html
http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00858.html


-- 

ghazi at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-06-23 17:50:52
   date||


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

[Bug c/20319] -fkeep-static-consts with -O asserted doesn't keep consts

[hans at mesoscopic dot mines dot edu]

--- Comment #9 from hans at mesoscopic dot mines dot edu  2008-06-23 18:03 
---
FWIW-

I ran into this "bug" too, in the same usecase as Gary. I think the current
behavior is close to useless and should be changed as outlined above.

Cheers

Hans


-- 

hans at mesoscopic dot mines dot edu changed:

   What|Removed |Added

 CC||hans at mesoscopic dot mines
   ||dot edu


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

[Bug target/35620] ICE passing dereferenced pointer to _Decimal32

[bergner at gcc dot gnu dot org]

--- Comment #2 from bergner at gcc dot gnu dot org  2008-06-23 19:57 ---
Janis, is this fixed with your patch so we can close this bugzilla?


-- 


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

[Bug c/35712] decimal float literal constant zero loses significant trailing zeroes

[bergner at gcc dot gnu dot org]

--- Comment #2 from bergner at gcc dot gnu dot org  2008-06-23 19:59 ---
Janis, is this fixed so we can close this bugzilla?


-- 


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

[Bug fortran/36341] MATMUL: Bounds check missing (run time & compile time)

[tkoenig at gcc dot gnu dot org]

--- Comment #6 from tkoenig at gcc dot gnu dot org  2008-06-23 21:28 ---
We should probably set the shape for
arguments of known shape in gfc_resolve_matmul.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu dot
   ||org


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

[Bug middle-end/36594] [4.4 Regression] multiple regressions on powerpc at rev.136976

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2008-06-23 22:12 ---
This is the patch which I am testing (which fixes the original issue Honza ran
into and this one too):
Index: builtins.c
===
--- builtins.c  (revision 137049)
+++ builtins.c  (working copy)
@@ -873,6 +873,9 @@ expand_builtin_nonlocal_goto (tree exp)
   r_label = convert_memory_address (Pmode, r_label);
   r_save_area = expand_normal (t_save_area);
   r_save_area = convert_memory_address (Pmode, r_save_area);
+  /* Copy the address of the save location to a register just in case it was
based
+on the frame pointer.   */
+  r_save_area = copy_to_reg (r_save_area);
   r_fp = gen_rtx_MEM (Pmode, r_save_area);
   r_sp = gen_rtx_MEM (STACK_SAVEAREA_MODE (SAVE_NONLOCAL),
  plus_constant (r_save_area, GET_MODE_SIZE (Pmode)));
@@ -887,7 +890,6 @@ expand_builtin_nonlocal_goto (tree exp)
 #endif
 {
   r_label = copy_to_reg (r_label);
-  r_sp = copy_to_reg (r_sp);

   emit_clobber (gen_rtx_MEM (BLKmode, gen_rtx_SCRATCH (VOIDmode)));
   emit_clobber (gen_rtx_MEM (BLKmode, hard_frame_pointer_rtx));


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c++/36608] New: internal compiler error: in find_outermost_region_in_block, at tree-cfg.c:4739

[bmayer at gmail dot com]

I am using C++ and OpenMP, This also appears to be a bug in more recent
versions of the compiler.


-- 
   Summary: internal compiler error: in
find_outermost_region_in_block, at tree-cfg.c:4739
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bmayer at gmail dot com
  GCC host triplet: Linux localhost.localdomain 2.6.23.17-88.fc7 #1 SMP Thu
May 15 0


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

[Bug c++/36608] internal compiler error: in find_outermost_region_in_block, at tree-cfg.c:4739

[bmayer at gmail dot com]

--- Comment #1 from bmayer at gmail dot com  2008-06-23 22:34 ---
I tried to attach the preprocessed source, bugzilla told me that the file was
1300KB and it only could be 1000KB. I can email it to you if you want. This bug
appears to show up in later compilers also.


-- 

bmayer at gmail dot com changed:

   What|Removed |Added

 CC||bmayer at gmail dot com
   Keywords||openmp


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

[Bug c++/36608] internal compiler error: in find_outermost_region_in_block, at tree-cfg.c:4739

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-06-23 22:37 ---
This is most likely fixed in 4.2.0 or 4.3.0.


-- 


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

[Bug target/36609] New: AVR wrong code using incorrect RTL for test reversal pattern

[hutchinsonandy at gcc dot gnu dot org]

I found problem with AVR test instructions such used by c/c++ code (x>0)
and demonstrated by testsuite test gcc.c-torture/execute/pr22493-1.c

#include 
extern void abort ();
extern void exit (int);
void f(int i)
{
  if (i>0)
abort();
  i = -i;
  if (i<0)
return;
  abort ();
}

int main(int argc, char *argv[])
{
  f(INT_MIN);
  exit (0);
}


Compiling this with:

avr-gcc -c -mmcu=atmega128 -I. -w  -Os  -fwrapv  -mmcu=atmega128 -Wall
-Wstrict-prototypes -Wa,-ahlms=test.s  -std=gnu99 test.c -o test.o


produces wrong code.

An integer test x>0 is translated into RTL:

CC0=Rx

from which we create AVR assembler code

TST Rx

which is equivalent to CMP Rx,0


AVR target also have negated_tst  RTL patterns to reverse tests in avr_reorg so
that we can match the available branches on AVR. For example AVR has BRLT and
BRGE but not BRLE and BRGT.

So

CC0 = Rx
Jump LE

becomes reorganized as

CC0 = NEG:xx(Rx)
Jump GE

which emits the following code via  define_insn "*negated_tst.

CMP 0,Rx
BRGE


For such test reversals  the final code is correct. However, the intermediate
RTL used by translation is WRONG

CC0=Rx
Jump LE

is NOT equivalent to

CC0 = NEG:xx(Rx)
Jump GE

For test reversal the problem is hidden - 2 wrongs making a right in this case.
BUT the bug appears when we have a normal code sequence such as

NEG:xx(Rx)
CC0 = Rx

which the combine phase will match against the RTL of *negated_tst and result
in assembler code of:

CMP 0,Rx

which is incorrect. Consider the case where Rx= -32768

NEG:HI(-32768) => -32768
CC0 = -32768 => Negative correct!

but the replacment:

CMP 0,-32768 =>Positive - WRONG


The fix is to redefine  the "*negated_tst" RTL patterns to use correct COMPARES
 and have avr_reorg to emit the corrected RTL.


(define_insn "*reversed_tsthi"
  [(set (cc0)
(compare (const_int 0)
(match_operand:HI 0 "register_operand"  "r")))

Test reversals will be unaffected. But now combine won't find any bad RTL.

I have not studied to see if the above RTL is ever generated. If it is, it is
perfectly safe.


-- 
   Summary: AVR wrong code using incorrect RTL for test reversal
pattern
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hutchinsonandy at gcc dot gnu dot org
 GCC build triplet: i686-pc-cygwin
  GCC host triplet: i686-pc-cygwin
GCC target triplet: avr-unknown-none


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

[Bug objc/36610] New: message forwarding broken on x86_64: self is not receiver

[hydrologiccycle at gmail dot com]

Note that this is a 64-bit problem.  i386 works fine.  Code for reproducing is
included, as well as all system information.


correct output of program on 32-bit:

forwarding for selector display from 134536384 to 134536136
worked, self == receiver
foo is 1234567890, and should be 1234567890


incorrect output of program on 64-bit:

forwarding for selector display from 6330720 to 6330224
broken, self != receiver
foo is 6330224, and should be 1234567890


test program:

// Objective-C x86_64 bug:  self is wrong on forward;
// broken on gcc-4.1.2, 4.3.0, and 4.3.1

#include 
#include 
#include 
#include 

id forwarder, receiver;

@interface Forwarder:Object
{
id receiver;
}

-initWithReceiver:theReceiver;

@end

@interface Receiver:Object
{
int foo;
}

-display;
-initWithFoo:(int)theFoo;

@end

@implementation Receiver

-initWithFoo:(int)theFoo
{
foo = theFoo;
return self;
}

-display
{
if (self == receiver) {
printf("worked, self == receiver\n");
} else {
printf("broken, self != receiver\n");
}
printf("foo is %d, and should be %d\n", foo, 1234567890);
return self;
}

@end

@implementation Forwarder

-initWithReceiver:theReceiver
{
[super init];
receiver = theReceiver;
return self;
}

-(retval_t) forward:(SEL)theSel:(arglist_t)theArgFrame
{
if (receiver) {

printf("forwarding for selector %s from %ld to %ld\n",
sel_get_name(theSel), self, receiver);

//return objc_msg_sendv(itsNextLink, theSel, theArgFrame);
return [receiver performv:theSel:theArgFrame];

} else {
return [self doesNotRecognize:theSel];
}
}

@end

int main()
{
receiver = [[Receiver alloc] initWithFoo:1234567890];
forwarder = [[Forwarder alloc] initWithReceiver:receiver];

[forwarder display];

exit(EXIT_SUCCESS);
return 0;
}


I compiled gcc from the 4.3.1 tarball on ftp.gnu.org in order to avoid any
distro patches.  Here's the output of gcc -v:

Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-4.3.1/configure --prefix=/usr/local
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--enable-nls -
-without-included-gettext --with-system-zlib --disable-checking
--disable-werror --enable-secureplt --disable-multilib --enable-libmudflap
--disabl
e-libssp --disable-libgcj --enable-languages=c,objc --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu 
Thread model: posix
gcc version 4.3.1 (GCC)


-- 
   Summary: message forwarding broken on x86_64: self is not
receiver
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: objc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hydrologiccycle at gmail dot com
 GCC build triplet: x86_64-pc-linux-gnu
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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

[Bug libobjc/36610] message forwarding broken on x86_64: self is not receiver

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-06-24 01:52 ---
This is most likely a problem with __builtin_apply :).


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|major   |normal
  Component|objc|libobjc


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

[Bug target/33104] Missing error check in .md converter

[amylaar at gcc dot gnu dot org]

-- 

amylaar at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-06-24 02:01:16
   date||


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

[Bug middle-end/36593] [4.4 Regression]: gfortran.dg/default_format_1.f90, 22_locale/num_get/get/char/2.cc

[hp at gcc dot gnu dot org]

--- Comment #8 from hp at gcc dot gnu dot org  2008-06-24 02:38 ---
Newlib patch here: , also
referring to a gcc documentation improvement patch.


-- 


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

[Bug middle-end/36611] New: false negatives with -Wstrict-aliasing=3

[hp at gcc dot gnu dot org]

See PR36593. In one of the comments, I mention that the testcase in that PR
(which was originally marked as a miscompilation) had warnings for
-Wstrict-aliasing=1 and 2, but not 3.  According to the documentation for
-Wstrict-aliasing, level 3 ought to have *less* false negatives than 1 and 2,
even more important when "bad code" was actually generated.  Hence this
enhanceement PR.
It could even be stretched to be seen as a regression: the warnings no longer
match the generated code.


-- 
   Summary: false negatives with -Wstrict-aliasing=3
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
GCC target triplet: cris-axis-elf


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

[Bug libstdc++/36612] New: __throw_* functions in ext/pb_ds/exception.hpp cause multiple definition errors

[chalathip at gmail dot com]

If the "ext/pb_ds/exception.hpp" is included (directly or indirectly) in more
than one separate compilation units, all of its __throw_... functions are
redefinition.

Fox example:
=== main.cc ===
#include"someclass.h"

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

=== someclass.h === 
#include // in gcc 4.2
/*
#include // in gcc 4.3.0
#include
#include
*/
class someclass
{
   // I want to use pat_trie here.
};

=== someclass.cc === 
#include"someclass.h"


$ g++ main.cc someclass.cc
someclass.cc:(.text+0x0): multiple definition of
`pb_ds::__throw_resize_error()'
/tmp/cc8LPB2N.o:main.cc:(.text+0x12): first defined here
/tmp/ccl19hyr.o: In function `pb_ds::__throw_join_error()':
someclass.cc:(.text+0x52): multiple definition of `pb_ds::__throw_join_error()'
/tmp/cc8LPB2N.o:main.cc:(.text+0x64): first defined here
/tmp/ccl19hyr.o: In function `pb_ds::__throw_insert_error()':
someclass.cc:(.text+0xa4): multiple definition of
`pb_ds::__throw_insert_error()'
/tmp/cc8LPB2N.o:main.cc:(.text+0xb6): first defined here
/tmp/ccl19hyr.o: In function `pb_ds::__throw_container_error()':
someclass.cc:(.text+0xf6): multiple definition of
`pb_ds::__throw_container_error()'
/tmp/cc8LPB2N.o:main.cc:(.text+0x108): first defined here
collect2: ld returned 1 exit status

===
My solution is to change all of _throw__... functions into inline ones.


-- 
   Summary: __throw_* functions in ext/pb_ds/exception.hpp cause
multiple definition errors
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chalathip at gmail dot com


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

[Bug c/36613] New: likely codegen bug

[regehr at cs dot utah dot edu]

This is seen on svn 137045.

[EMAIL PROTECTED] tmp27]$ current-gcc -O -fwrapv small.c -o small
[EMAIL PROTECTED] tmp27]$ ./small
0
[EMAIL PROTECTED] tmp27]$ current-gcc -Os -fwrapv small.c -o small
[EMAIL PROTECTED] tmp27]$ ./small
2

[EMAIL PROTECTED] gcc-current]$ current-gcc -v   
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --program-prefix=current-
--enable-languages=c,c++ --prefix=/home/regehr
Thread model: posix
gcc version 4.4.0 20080623 (experimental) (GCC) 





#include 
#include 

static inline int
lshift_s_s(int left, int right)
{
if ((left < 0)
|| (right < 0)
|| (right >= sizeof(int)*CHAR_BIT)
|| (left > (INT_MAX >> right))) {
/* Avoid undefined behavior. */
return left;
}
return left << right;
}

static inline unsigned int
lshift_u_u(unsigned int left, unsigned int right)
{
if ((right >= sizeof(unsigned int)*CHAR_BIT)
|| (left > (UINT_MAX >> right))) {
/* Avoid undefined behavior. */
return left;
}
return left << right;
}

static inline int
rshift_s_u(int left, unsigned int right)
{
if ((left < 0)
|| (right >= sizeof(int)*CHAR_BIT)) {
/* Avoid implementation-defined and undefined behavior. */
return left;
}
return left >> right;
}

int func_47(unsigned int p_48 ) ;
int func_47(unsigned int p_48 ) 
{ 
  int tmp = lshift_u_u(p_48, p_48);
  int tmp___0 = lshift_s_s(tmp, 1);
  int tmp___1 = rshift_s_u(1 + p_48, tmp___0);
  return (tmp___1);
}

int main(void) 
{ 
  int x = func_47(1);
  printf("%d\n", x);
  return 0;
}


-- 
   Summary: likely codegen bug
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah dot edu
 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=36613

[Bug middle-end/36613] likely codegen bug

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-06-24 04:32 ---
This worked with:
Using built-in specs.
Target: i386-apple-darwin8.11.1
Configured with: /Users/apinski/src/local/gcc/configure
--prefix=/Users/apinski/local-gcc --disable-multilib
Thread model: posix
gcc version 4.4.0 20080622 (experimental) [trunk revision 137020] (GCC) 


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c   |middle-end


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

[Bug c/36614] New: incorrect "warning: array subscript is above array bounds"

[gnu at rothwell dot id dot au]

In some circumstances gcc 4.3.1 and later give the above warning incorrectly.
I have tried this with:

gcc (Debian 4.3.1-2) 4.3.1 on x86_64 (This is the compiler in current Debian
unstable)

gcc (GCC) 4.4.0 20080624 (experimental) [trunk revision 137057] on PowerPC -
this was built with "--disable-bootstrap --enable-languages=c")

The .i version of my test program is as follows:

# 1 "arrtest.c"
# 1 ""
# 1 ""
# 1 "arrtest.c"

struct pt_regs {
 unsigned long gpr[32];
 unsigned long nip;
 unsigned long msr;
 unsigned long orig_gpr3;
 unsigned long ctr;
 unsigned long link;
 unsigned long xer;
 unsigned long ccr;
 unsigned long softe;
 unsigned long trap;
 unsigned long dar;
 unsigned long dsisr;
 unsigned long result;
};

void restore_sigcontext(struct pt_regs *regs)
{
 unsigned long *gregs = (unsigned long *)regs;
 int i;


 for (i = 31; i <= 43; i++)
  gregs[i] = 1;


 for (i = 32; i <= 43; i++)
  gregs[i] = 1;


 for (i = 31; i <= 60; i++)
  gregs[i] = 1;
}

I compiled this with "gcc -Wall -O2 -c arrtest.c" and get the warning for the
seond "gregs[i] = 1;" but not either of the others.  This is a cut down from a
file in the current Linux kernel PowerPC arch code.

Compiler output:
arrtest.c: In function ‘restore_sigcontext’:
arrtest.c:29: warning: array subscript is above array bounds


-- 
   Summary: incorrect "warning: array subscript is above array
bounds"
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gnu at rothwell dot id dot au


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