[Bug debug/25324] New: Wrong DW_TAG_compile_unit generated when compiling preprocessed fortran code

[taschna at uni-muenster dot de]

When compiling the following code with gfortran 
(gcc version 4.0.2 20051125 (Red Hat 4.0.2-8)) it is afterwards not possible
to set a breakpoint on specific lines in the code:

$ cat main.F
  PROGRAM Test
  IMPLICIT NONE

WRITE(*,*) 'Hello World'

  END
$ gfortran -g -save-temps main.F -o main
$ gdb main
GNU gdb Red Hat Linux (6.3.0.0-1.84rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db
library "/lib/libthread_db.so.1".

(gdb) l
1   # 1 "main.F"
2   # 1 "/home/taschna/gdbtest//"
3   # 1 ""
4   # 1 ""
5   # 1 "main.F"
6 PROGRAM Test
7 IMPLICIT NONE
8
9   WRITE(*,*) 'Hello World'
10
(gdb) b 9
No line 9 in file "main.f".

According to the comments in the gdb bug database to bug fortran/2048

this is a bug in gfortran, because
the DW_TAG_compile_unit is set to 'main.f' which is a temporary file
created by the compiler and therefore "should not be mentioned in 
debugging information".


-- 
   Summary: Wrong DW_TAG_compile_unit generated when compiling
preprocessed fortran code
   Product: gcc
   Version: 4.0.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: taschna at uni-muenster dot de


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

[Bug c++/25322] ISO compliance of defining structs in anonymous unions

[bangerth at dealii dot org]

--- Comment #2 from bangerth at dealii dot org  2005-12-09 05:20 ---
Confirmed. We should at least complain about cases 1, 3, 5. As does,
incidentally, icc with -Xc -ansi.

W.


-- 

bangerth at dealii dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2005-12-09 05:20:59
   date||


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

[Bug middle-end/25315] [4.2 regression] testsuite failure:27_io/basic_ostream/inserters_character/char/9555-oc.cc wchar_t/9555-oc.cc exec

[hp at gcc dot gnu dot org]

--- Comment #3 from hp at gcc dot gnu dot org  2005-12-09 05:19 ---
Comment #2 is generally wrong: a change in GCC codegen can certainly expose a
coding bug in libstdc++ despite "nothing changed" there.  As the bug is exposed
by libstdc++, it is correct to set component to "libstdc++" pending further
analysis.  I guess you disagree, but by your logic the change of component to
"target" is just as wrong: there are no "target" changes for neither CRIS nor
ia64 between those revisions.  Let's settle for "middle-end", ok?


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|target  |middle-end


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

[Bug other/4372] #pragma weak pthread* inclusion causes applications to crash without a linker error when one forgets to link with -lpthread

[pinskia at gcc dot gnu dot org]

--- Comment #13 from pinskia at gcc dot gnu dot org  2005-12-09 04:56 
---
*** Bug 14952 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rassahah at neofonie dot de


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

[Bug other/14952] libgcc_eh.a broken with respect to pthreads & static linking

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2005-12-09 04:56 ---
(In reply to comment #4)
> I have a real world RT application on linux where dynamic linking lead to a
> VmSize of 70 Mb whereas static linling leads to VmSize = 10 Mb. The problem > 
> is that you need to do mlockall to avoid page faults...

VMSize means nothing as most of the code is just mapped in and nothing else.
And if the VM shit, then really it is not a GCC bug.

Anyways this is really a dup of bug 4372.

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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug c/8960] Segfault with __attribute__ ((mode (...))) in start_function:5702

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|REOPENED|NEW


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

[Bug rtl-optimization/25115] [4.2 Regression] Segmentation fault in pre_insert_copy_insn

[hp at gcc dot gnu dot org]

--- Comment #8 from hp at gcc dot gnu dot org  2005-12-09 03:50 ---
I see this on cris-axis-elf too, with local changes in progress of changing
from cc0, causing at least:
Running
/home/hp/combined/combined/gcc/testsuite/gcc.c-torture/execute/builtins/builtins.exp
...
FAIL: gcc.c-torture/execute/builtins/memcpy-chk.c compilation,  -O2

...and it seems like the (updated) patch at
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01954.html>
DTRT and works for me too.


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hp at gcc dot gnu dot org


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

[Bug pch/13676] GCC failes to recognize files ending in .hpp as headers to be precompiled

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2005-12-09 03:05 ---
*** Bug 25323 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pluto at agmk dot net


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

[Bug pch/25323] precompilationi fails on *.hpp headers.

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2005-12-09 03:05 ---


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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug libfortran/25039] comma short-circuit field width

[jvdelisle at gcc dot gnu dot org]

--- Comment #12 from jvdelisle at gcc dot gnu dot org  2005-12-09 02:57 
---
Subject: Bug 25039

Author: jvdelisle
Date: Fri Dec  9 02:57:13 2005
New Revision: 108272

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108272
Log:
2005-12-08  Jerry DeLisle  <[EMAIL PROTECTED]>

PR libgfortran/25039
* gfortran.dg/read_comma.f: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/read_comma.f
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug pch/25323] New: precompilationi fails on *.hpp headers.

[pluto at agmk dot net]

[1] tmp.hpp contains only include guard
# g++ -Wall -O2 tmp.hpp
tmp.hpp: file not recognized: File format not recognized
collect2: ld returned 1 exit status

[2] tmp.hpp ie empty.
# g++ -Wall -O2 tmp.hpp
/usr/lib/gcc/i686-pld-linux/3.4.5/../../../crt1.o(.text+0x18): In function
`_start':
init.c: undefined reference to `main'
collect2: ld returned 1 exit status


-- 
   Summary: precompilationi fails on *.hpp headers.
   Product: gcc
   Version: 3.4.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: pch
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
 GCC build triplet: *-linux
  GCC host triplet: *-linux
GCC target triplet: *-linux


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

[Bug libfortran/25039] comma short-circuit field width

[jvdelisle at gcc dot gnu dot org]

--- Comment #11 from jvdelisle at gcc dot gnu dot org  2005-12-09 02:53 
---
Subject: Bug 25039

Author: jvdelisle
Date: Fri Dec  9 02:53:41 2005
New Revision: 108271

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108271
Log:
2005-12-08  Jerry DeLisle  <[EMAIL PROTECTED]>

PR libgfortran/25039
* io/io.h: Create a new flag sf_read_comma to control comma
separators in numeric reads.
* io/transfer.c (formatted_transfer_scalar): Initialize the flag.
(read_sf): Check for commas coming in and if the flag is set,
shortcut the read.
* io/read.c (read_a) (read_x): Clear the flag for character reads and
reset it after the reads.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/io.h
trunk/libgfortran/io/read.c
trunk/libgfortran/io/transfer.c


-- 


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

[Bug fortran/25319] namelist error

[jvdelisle at gcc dot gnu dot org]

--- Comment #1 from jvdelisle at gcc dot gnu dot org  2005-12-09 02:08 
---
I see that ifort gives identical results to gfortran.  I believe the correct
interpretation is that the read is expecting a list of data and when its not
there it ends the read.  There are some compilers that might provide an
extension that would auto fill an array if the data list is followed by a
comma.  That would be an enhancement.

So I think this is not a bug, but maybe others have an opinion.


-- 


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

[Bug target/25315] [4.2 regression] testsuite failure:27_io/basic_ostream/inserters_character/char/9555-oc.cc wchar_t/9555-oc.cc exec

[pcarlini at suse dot de]

--- Comment #2 from pcarlini at suse dot de  2005-12-09 00:11 ---
"Component" cannot be libstdc++, nothing changed between those revisions..


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

  Component|libstdc++   |target


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

[Bug c++/25316] POD structures can have

[mrs at apple dot com]

--- Comment #3 from mrs at apple dot com  2005-12-08 23:53 ---
As I said, the prohibition is in 8.5.1 in the definition of aggregate.  This is
what makes it not a POD.  No DR needed, no gcc bug fix needed, the bug was in
the Metroworks compiler and in the users understanding.


-- 


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

[Bug debug/24908] [4.0/4.1/4.2 Regression] ICE in dwarf2out for cpu2000 with -funroll-loops -fno-tree-copyrename

[amodra at bigpond dot net dot au]

--- Comment #11 from amodra at bigpond dot net dot au  2005-12-08 23:51 
---
Fixed.


-- 

amodra at bigpond dot net dot au changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   Priority|P1  |P3
 Resolution||FIXED


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

[Bug debug/24908] [4.0/4.1/4.2 Regression] ICE in dwarf2out for cpu2000 with -funroll-loops -fno-tree-copyrename

[amodra at gcc dot gnu dot org]

--- Comment #10 from amodra at gcc dot gnu dot org  2005-12-08 23:50 ---
Subject: Bug 24908

Author: amodra
Date: Thu Dec  8 23:50:40 2005
New Revision: 108259

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108259
Log:
PR debug/24908
* dwarf2out.c (dwarf2out_frame_debug_expr): Don't assert that
call_used_regs can't be used to save reg in another reg.


Modified:
branches/gcc-4_0-branch/gcc/ChangeLog
branches/gcc-4_0-branch/gcc/dwarf2out.c


-- 


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

[Bug debug/24908] [4.0/4.1/4.2 Regression] ICE in dwarf2out for cpu2000 with -funroll-loops -fno-tree-copyrename

[amodra at gcc dot gnu dot org]

--- Comment #9 from amodra at gcc dot gnu dot org  2005-12-08 23:47 ---
Subject: Bug 24908

Author: amodra
Date: Thu Dec  8 23:47:48 2005
New Revision: 108258

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108258
Log:
PR debug/24908
* dwarf2out.c (dwarf2out_frame_debug_expr): Don't assert that
call_used_regs can't be used to save reg in another reg.


Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/dwarf2out.c


-- 


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

[Bug debug/24908] [4.0/4.1/4.2 Regression] ICE in dwarf2out for cpu2000 with -funroll-loops -fno-tree-copyrename

[amodra at gcc dot gnu dot org]

--- Comment #8 from amodra at gcc dot gnu dot org  2005-12-08 23:43 ---
Subject: Bug 24908

Author: amodra
Date: Thu Dec  8 23:43:40 2005
New Revision: 108257

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108257
Log:
PR debug/24908
* dwarf2out.c (dwarf2out_frame_debug_expr): Don't assert that
call_used_regs can't be used to save reg in another reg.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c


-- 


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

[Bug c++/25322] ISO compliance of defining structs in anonymous unions

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2005-12-08 23:36 ---
Hmm, I actually want to say that case 2, 4, and 6 are actually valid (But I
have not looked at the standard) as anonymous types are special.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||accepts-invalid
  Known to fail||2.95.3 3.0.4 3.2.3 3.4.0
   ||3.3.3


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

[Bug target/23424] cris.md rtl canonicalization bug

[hp at gcc dot gnu dot org]

--- Comment #7 from hp at gcc dot gnu dot org  2005-12-08 23:07 ---
Subject: Bug 23424

Author: hp
Date: Thu Dec  8 23:07:31 2005
New Revision: 108255

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108255
Log:
PR target/23424
* recog.c (constrain_operands): Strip unary operators
only ifndef KEEP_UNARY_OPERATORS_AT_CONSTRAINT_CHECKING.
* reload.c (find_reloads): Ditto.
* config/cris/cris.h (KEEP_UNARY_OPERATORS_AT_CONSTRAINT_CHECKING):
Define.

Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/config/cris/cris.h
branches/gcc-4_1-branch/gcc/recog.c
branches/gcc-4_1-branch/gcc/reload.c


-- 


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

[Bug c++/25322] New: ISO compliance of defining structs in anonymous unions

[cfranz at aldon dot com]

$ cat testunion.cpp
// testunion.cpp

static union { struct n { int I2; } S2; }; // Case 1
static union { struct   { int I1; } S1; }; // Case 2

struct foo
{
   union { struct n { int I2; } S2; }; // Case 3
   union { struct   { int I1; } S1; }; // Case 4
};

void func()
{
   union { struct n { int I2; } S2; }; // Case 5
   union { struct   { int I1; } S1; }; // Case 6
}

$ g++ --version
g++ (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ g++ -c -pedantic testunion.cpp
testunion.cpp:8: error: `struct foon' invalid; an
anonymous
 union can only have non-static data members


g++ reports an error only in Case 3, regardless of the settings of -pedantic or
-pedantic-errors, but as I understand it all six cases violate the C++
standard.  Accordingly, Comeau and xlc++ reject all six cases in strict mode,
and accept them with warnings in relaxed mode.

This behavior is consistent for at least versions 3.4.4 and 3.3.2.


-- 
   Summary: ISO compliance of defining structs in anonymous unions
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cfranz at aldon dot com


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

[Bug fortran/25321] New: array shape conformance error

[uttamp at us dot ibm dot com]

$ cat 
program test
integer ::a(2,2)
real :: b(4,4)
a=1
b=2.0
b = b + a
end program test

gfortran doesn't give a "shapes not conformable" error.

There is a PR #19754 and fix for the similar problem when arrays are of the
same type. In this particular case arrays are of different types.


-- 
   Summary: array shape conformance error
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uttamp at us dot ibm dot com
 GCC build triplet: powerpc64-linux
  GCC host triplet: powerpc64-linux
GCC target triplet: powerpc64-linux


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

[Bug c++/25316] POD structures can have

[gdr at integrable-solutions dot net]

--- Comment #2 from gdr at integrable-solutions dot net  2005-12-08 22:25 
---
Subject: Re:   New: POD structures can have

"mrs at apple dot com" <[EMAIL PROTECTED]> writes:

| A user reported that this:
| 
| mrs $ cat > t98.c
| struct X {
| int a, b;
| X() : a(0), b(0) {}
| };
| 
| static void f(const char *s, ...);
| 
| int main()
| {
| X x;
| f("foo!", x);
| return 0;
| }
| 
| works on other C++ compilers (Metroworks), but on gcc:
| 
| mrs $ ./g++ -B./ -c t98.c
| t98.c: In function 'int main()':
| t98.c:11: warning: cannot pass objects of non-POD type 'struct X' through
| '...'; call will abort at runtime
| 
| This, according the a reading of the standard is a POD type, no, really.  :-) 

Are you saying "struct X" is a POD?

-- Gaby


-- 


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

[Bug c++/19317] [4.1 Regression] removing a temporary return value when we cannot

[jakub at gcc dot gnu dot org]

--- Comment #51 from jakub at gcc dot gnu dot org  2005-12-08 21:56 ---
Subject: Bug 19317

Author: jakub
Date: Thu Dec  8 21:56:44 2005
New Revision: 108253

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108253
Log:
PR c++/19317
* g++.dg/opt/pr19317-1.C: New test.
* g++.dg/opt/pr19317-2.C: New test.
* g++.dg/opt/pr19317-3.C: New test.

Added:
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/opt/pr19317-1.C
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/opt/pr19317-2.C
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/opt/pr19317-3.C
Modified:
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug target/19005] [3.4 regression] Error: bad register name `%sil'

[jakub at gcc dot gnu dot org]

--- Comment #12 from jakub at gcc dot gnu dot org  2005-12-08 21:54 ---
Subject: Bug 19005

Author: jakub
Date: Thu Dec  8 21:54:34 2005
New Revision: 108252

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108252
Log:
PR target/19005
* gcc.c-torture/execute/pr19005.c: New test.

Added:
branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/execute/pr19005.c
Modified:
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug target/17828] -O2 -fPIC doesn't work with switches in linkonce functions and new binutils

[jakub at gcc dot gnu dot org]

--- Comment #12 from jakub at gcc dot gnu dot org  2005-12-08 21:54 ---
Subject: Bug 17828

Author: jakub
Date: Thu Dec  8 21:53:59 2005
New Revision: 108251

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108251
Log:
PR target/17828
* g++.old-deja/g++.other/comdat5.C: New test.
* g++.old-deja/g++.other/comdat5-aux.cc: New file.

Added:
branches/gcc-4_1-branch/gcc/testsuite/g++.old-deja/g++.other/comdat5-aux.cc
branches/gcc-4_1-branch/gcc/testsuite/g++.old-deja/g++.other/comdat5.C
Modified:
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/19317] [4.1 Regression] removing a temporary return value when we cannot

[jakub at gcc dot gnu dot org]

--- Comment #50 from jakub at gcc dot gnu dot org  2005-12-08 21:50 ---
Subject: Bug 19317

Author: jakub
Date: Thu Dec  8 21:50:38 2005
New Revision: 108247

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108247
Log:
PR c++/19317
* g++.dg/opt/pr19317-1.C: New test.
* g++.dg/opt/pr19317-2.C: New test.
* g++.dg/opt/pr19317-3.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/opt/pr19317-1.C
trunk/gcc/testsuite/g++.dg/opt/pr19317-2.C
trunk/gcc/testsuite/g++.dg/opt/pr19317-3.C
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/19005] [3.4 regression] Error: bad register name `%sil'

[jakub at gcc dot gnu dot org]

--- Comment #11 from jakub at gcc dot gnu dot org  2005-12-08 21:49 ---
Subject: Bug 19005

Author: jakub
Date: Thu Dec  8 21:49:17 2005
New Revision: 108246

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108246
Log:
PR target/19005
* gcc.c-torture/execute/pr19005.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr19005.c
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/17828] -O2 -fPIC doesn't work with switches in linkonce functions and new binutils

[jakub at gcc dot gnu dot org]

--- Comment #11 from jakub at gcc dot gnu dot org  2005-12-08 21:47 ---
Subject: Bug 17828

Author: jakub
Date: Thu Dec  8 21:47:10 2005
New Revision: 108245

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108245
Log:
PR target/17828
* g++.old-deja/g++.other/comdat5.C: New test.
* g++.old-deja/g++.other/comdat5-aux.cc: New file.

Added:
trunk/gcc/testsuite/g++.old-deja/g++.other/comdat5-aux.cc
trunk/gcc/testsuite/g++.old-deja/g++.other/comdat5.C
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/25308] [4.2 Regression] 22_locale/locale/cons/12658_thread-1.cc, etc fail

[pcarlini at suse dot de]

--- Comment #2 from pcarlini at suse dot de  2005-12-08 21:44 ---
(In reply to comment #1)
 (12658_thread-1.cc also FAILs but is
> blacklisted in my regression tester as having been known to pass or fail at
> random.

In my opinion, assuming some basic prerequisites are satisfied (i.e.,
sufficiently recent glibc, not affected by a thread-safety bug, >= 2.3.4 is
certainly ok), currently there are no good reasons for 12658_thread-1.cc to
fail.


-- 


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

[Bug testsuite/25318] [4.1/4.2 Regression] g++.dg/other/pr22003.C (test for excess errors) fails

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2005-12-08 21:35 ---
This is only a testsuite failure as -freorder-blocks-and-partition is not
excepted to work on ia64 or any target which emits undwind info by default.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|target  |testsuite
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2005-12-08 21:35:46
   date||
   Target Milestone|--- |4.1.0


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

[Bug rtl-optimization/25285] pessimization of goto * ("computed goto")

[anton at mips dot complang dot tuwien dot ac dot at]

--- Comment #6 from anton at mips dot complang dot tuwien dot ac dot at  
2005-12-08 21:31 ---
Subject: Re:  pessimization of goto * ("computed goto")

pinskia at gcc dot gnu dot org wrote:
> --- Comment #5 from pinskia at gcc dot gnu dot org  2005-12-06 21:58 
> ---
> (In reply to comment #4)
> > So, no, the code is not worse, but much better.  I hope this
> > workaround will continue to work in future versions.
> 
> You are wrong in general since this is a conditional indirect jump.  Since it
> is conditional it means that it is going to do a jump and the locatity reasons
> are that important as like in the old days when there was a little code 
> cache. 
> In fact have doing jne instead of jeq might cause the branch mispridected. 

Sorry, you lost me here.  Conditional branch predictors on current
general-purpose CPUs are history-based, and I would not expect any
difference in the accuracy of the conditional branch prediction.
However, for BTB-based indirect branch predictors (Pentium 3, Athlon
64, and (modulo replication from the trace cache) Pentium 4), the
branch prediction accuracy suffers quite a lot if you combine several
well-predictable indirect branches with different targets into a
single indirect branch.

See [ertl&gregg03] for a deeper discussion, in particular Section 3.
You can also read in Section 5.2 (towards the end) why we don't want
to have a jump to far-away places.

> Note if you were actually using a target which have conditional indirect jumps
> this would be a bug (PPC for an example from either lr or ctr register, see PR
> 25287 for a bug report about that).

Sure, having a conditional indirect jump in-line would be nice.

But if the architecture does not have it (or if gcc does not utilize
it), what I would like to see in the resulting code is:

1) We compile with -fno-reorder-blocks, so the indirect branch should
be in the place corresponding to the source code, not somewhere else.

2) If you do reorder the blocks, you should not merge indirect
branches on CPUs with BTBs, for better branch prediction.

BTW, the __asm__("") workaround works nicely (for now), so I could
produce numbers for the slowdown for this bug, if you are interested.

@InProceedings{ertl&gregg03,
  author =   "M. Anton Ertl and David Gregg",
  title ="Optimizing Indirect Branch Prediction Accuracy in Virtual
Machine Interpreters",
  crossref = "sigplan03",
  OPTpages = "",
  url = 
"http://www.complang.tuwien.ac.at/papers/ertl%26gregg03.ps.gz";,
  abstract = "Interpreters designed for efficiency execute a huge
  number of indirect branches and can spend more than
  half of the execution time in indirect branch
  mispredictions.  Branch target buffers are the best
  widely available\mn{on all recent general-purpose
  machines?} form of indirect branch prediction;
  however, their prediction accuracy for existing
  interpretes is only 2\%--50\%.  In this paper we
  investigate two methods for improving the prediction
  accuracy of BTBs for interpreters: replicating
  virtual machine (VM) instructions and combining
  sequences of VM instructions into superinstructions.
  We investigate static (interpreter build-time) and
  dynamic (interpreter run-time) variants of these
  techniques and compare them and several combinations
  of these techniques.  These techniques can eliminate
  nearly all of the dispatch branch mispredictions,
  and have other benefits, resulting in speedups by a
  factor of up to 3.17 over efficient threaded-code
  interpreters, and speedups by a factor of up to 1.3
  over techniques relying on superinstructions alone."
}

- anton


-- 


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

[Bug libstdc++/25315] [4.2 regression] testsuite failure:27_io/basic_ostream/inserters_character/char/9555-oc.cc wchar_t/9555-oc.cc exec

[jsm28 at gcc dot gnu dot org]

--- Comment #1 from jsm28 at gcc dot gnu dot org  2005-12-08 21:24 ---
Also seen on ia64-hp-hpux11.23, appearing between revisions 108152 and 108215.


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu dot org


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

[Bug middle-end/25276] [4.2 regression] testsuite failure: execution gcc.dg/attr-weakref-1.c

[jsm28 at gcc dot gnu dot org]

--- Comment #2 from jsm28 at gcc dot gnu dot org  2005-12-08 21:20 ---
Execution failure also seen on i686-pc-linux-gnu appearing between unmodified
revisions 108044 and 108105 of trunk.


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
 GCC target triplet|cris-axis-elf, x86_64-  |cris-axis-elf, x86_64-
   |unknown-linux-gnu and cris- |unknown-linux-gnu, i686-pc-
   |axis-linux-gnu  |linux-gnu and c
   Last reconfirmed|-00-00 00:00:00 |2005-12-08 21:20:40
   date||
   Target Milestone|--- |4.2.0


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

[Bug testsuite/25320] New: dg-require-sharedlib should support installed compiler testing

[jsm28 at gcc dot gnu dot org]

libstdc++ tests using dg-require-sharedlib are wrongly marked UNSUPPORTED when
testing an installed compiler because the test in libstdc++.exp does
[lookfor_file $blddir src/.libs/libstdc++.so].  This does not of course work
when there is an installed libstdc++.so being tested instead of a build
directory.  Cf. bug 23867 for another (independent) libstdc++ installed testing
issue.


-- 
   Summary: dg-require-sharedlib should support installed compiler
testing
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsm28 at gcc dot gnu dot org


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

[Bug target/25308] [4.2 Regression] 22_locale/locale/cons/12658_thread-1.cc, etc fail

[jsm28 at gcc dot gnu dot org]

--- Comment #1 from jsm28 at gcc dot gnu dot org  2005-12-08 21:09 ---
Confirmed appearing between revisions 108044 and 108105, at least as regards
12658_thread-2.cc and pthread3.cc.  (12658_thread-1.cc also FAILs but is
blacklisted in my regression tester as having been known to pass or fail at
random.  22309_thread.cc appears as UNSUPPORTED because of a separate test
harness bug.)


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2005-12-08 21:09:41
   date||
   Target Milestone|--- |4.2.0


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

[Bug fortran/25319] New: namelist error

[uttamp at us dot ibm dot com]

$ cat test.f95
program test_namelist
  call test1
  contains
 subroutine test1()
 real :: array(6)
 namelist /list/array
 read (*, nml=list)
 write (*, nml=list)
end

$ gfortran test.f95
$ ./a.out
&list array(1:5)=1.5

output
$ &LIST
 ARRAY=  1.50,  0.00, 2.5253750E-29, 1.4012985E-45,
1.5694543E-43,131089.0,  /

Shouldn't this set all the elements of array(1:6) to 1.5 value?

$ gfortran -v
gcc version 4.2.0 20051206 (experimental)


-- 
   Summary: namelist error
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uttamp at us dot ibm dot com
 GCC build triplet: powerpc64-linux
  GCC host triplet: powerpc64-linux
GCC target triplet: powerpc64-linux


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

[Bug target/25318] New: [4.1/4.2 Regression] g++.dg/other/pr22003.C (test for excess errors) fails

[jsm28 at gcc dot gnu dot org]

FAIL: g++.dg/other/pr22003.C (test for excess errors)
appeared on mainline on ia64-hp-hpux11.23, both -milp32 and -mlp64 (having
previously PASSed) between 20051205 (revision 108044) and 20051206 (revision
108105).  It also appeared on 4.1 branch between 20051204 (revision 108010) and
20051206 (revision 108105).

cc1plus: note: -freorder-blocks-and-partition does not work on this
architecture

gcc-testresults also shows the failure on ia64-linux.  If the diagnostic is
correct then the test needs refining not to apply on targets not supporting
this option (or better to use the special option only on suitable targets but
still to build everywhere else).


-- 
   Summary: [4.1/4.2 Regression] g++.dg/other/pr22003.C (test for
excess errors) fails
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsm28 at gcc dot gnu dot org
GCC target triplet: ia64-*-*


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

[Bug target/25317] New: [4.1 Regression] hppa64 EH failures

[jsm28 at gcc dot gnu dot org]

Some time between 20051118 (trunk revision 107161) and 20051203 (4.1 branch
revision 107994), still present as of 20051206 (4.1 branch revision 108105),
the following FAILs of tests previously PASSing appeared on
hppa64-hp-hpux11.11.  This is seen on 4.1 branch only, not on mainline.

FAIL: g++.dg/compat/eh/ctor1 cp_compat_x_tst.o-cp_compat_y_tst.o execute 
FAIL: g++.dg/compat/eh/ctor2 cp_compat_x_tst.o-cp_compat_y_tst.o execute 
FAIL: g++.dg/compat/eh/dtor1 cp_compat_x_tst.o-cp_compat_y_tst.o execute 
FAIL: g++.dg/compat/eh/filter1 cp_compat_x_tst.o-cp_compat_y_tst.o execute 
FAIL: g++.dg/compat/eh/new1 cp_compat_x_tst.o-cp_compat_y_tst.o execute 
FAIL: g++.dg/compat/eh/nrv1 cp_compat_x_tst.o-cp_compat_y_tst.o execute 
FAIL: g++.dg/compat/eh/spec3 cp_compat_x_tst.o-cp_compat_y_tst.o execute 
FAIL: g++.dg/compat/eh/template1 cp_compat_x_tst.o-cp_compat_y_tst.o execute 
FAIL: g++.dg/compat/eh/unexpected1 cp_compat_x_tst.o-cp_compat_y_tst.o execute 
FAIL: g++.dg/compat/init/array5 cp_compat_x_tst.o-cp_compat_y_tst.o execute 
FAIL: g++.dg/eh/cond1.C execution test
FAIL: g++.dg/eh/crossjump1.C execution test
FAIL: g++.dg/eh/ctor1.C execution test
FAIL: g++.dg/eh/ctor2.C execution test
FAIL: g++.dg/eh/delayslot1.C execution test
FAIL: g++.dg/eh/dtor1.C execution test
FAIL: g++.dg/eh/elide1.C execution test
FAIL: g++.dg/eh/filter1.C execution test
FAIL: g++.dg/eh/filter2.C execution test
FAIL: g++.dg/eh/forced1.C execution test
FAIL: g++.dg/eh/fp-regs.C execution test
FAIL: g++.dg/eh/loop1.C execution test
FAIL: g++.dg/eh/loop2.C execution test
FAIL: g++.dg/eh/new1.C execution test
FAIL: g++.dg/eh/omit-frame-pointer.C execution test
FAIL: g++.dg/eh/omit-frame-pointer2.C execution test
FAIL: g++.dg/eh/registers1.C execution test
FAIL: g++.dg/eh/simd-1.C execution test
FAIL: g++.dg/eh/simd-2.C execution test
FAIL: g++.dg/eh/spec3.C execution test
FAIL: g++.dg/eh/spec7.C execution test
FAIL: g++.dg/eh/synth2.C execution test
FAIL: g++.dg/eh/template1.C execution test
FAIL: g++.dg/eh/uncaught1.C execution test
FAIL: g++.dg/eh/unexpected1.C execution test
FAIL: g++.dg/init/array16.C execution test
FAIL: g++.dg/init/array5.C execution test
FAIL: g++.dg/init/ctor1.C execution test
FAIL: g++.dg/init/placement2.C execution test
FAIL: g++.dg/init/ref9.C execution test
FAIL: g++.dg/opt/eh2.C execution test
FAIL: g++.dg/opt/eh3.C execution test
FAIL: g++.dg/opt/pr23478.C execution test
FAIL: g++.old-deja/g++.abi/cxa_vec.C execution test
FAIL: g++.old-deja/g++.brendan/eh1.C execution test
FAIL: g++.old-deja/g++.eh/badalloc1.C execution test
FAIL: g++.old-deja/g++.eh/catch11.C execution test
FAIL: g++.old-deja/g++.eh/catch12.C execution test
FAIL: g++.old-deja/g++.eh/catch3.C execution test
FAIL: g++.old-deja/g++.eh/catch3p.C execution test
FAIL: g++.old-deja/g++.eh/catch4.C execution test
FAIL: g++.old-deja/g++.eh/catch4p.C execution test
FAIL: g++.old-deja/g++.eh/catch5.C execution test
FAIL: g++.old-deja/g++.eh/catch5p.C execution test
FAIL: g++.old-deja/g++.eh/catch6.C execution test
FAIL: g++.old-deja/g++.eh/catch6p.C execution test
FAIL: g++.old-deja/g++.eh/catch7.C execution test
FAIL: g++.old-deja/g++.eh/catch7p.C execution test
FAIL: g++.old-deja/g++.eh/catch8.C execution test
FAIL: g++.old-deja/g++.eh/catch8p.C execution test
FAIL: g++.old-deja/g++.eh/catch9.C execution test
FAIL: g++.old-deja/g++.eh/catch9p.C execution test
FAIL: g++.old-deja/g++.eh/catchptr1.C execution test
FAIL: g++.old-deja/g++.eh/cleanup1.C execution test
FAIL: g++.old-deja/g++.eh/cleanup2.C execution test
FAIL: g++.old-deja/g++.eh/flow1.C execution test
FAIL: g++.old-deja/g++.eh/fntry1.C execution test
FAIL: g++.old-deja/g++.eh/ia64-1.C execution test
FAIL: g++.old-deja/g++.eh/inline2.C execution test
FAIL: g++.old-deja/g++.eh/new1.C execution test
FAIL: g++.old-deja/g++.eh/new2.C execution test
FAIL: g++.old-deja/g++.eh/pdel1.C execution test
FAIL: g++.old-deja/g++.eh/pdel2.C execution test
FAIL: g++.old-deja/g++.eh/ptr1.C execution test
FAIL: g++.old-deja/g++.eh/ptrmem1.C execution test
FAIL: g++.old-deja/g++.eh/rethrow1.C execution test
FAIL: g++.old-deja/g++.eh/rethrow2.C execution test
FAIL: g++.old-deja/g++.eh/rethrow3.C execution test
FAIL: g++.old-deja/g++.eh/rethrow4.C execution test
FAIL: g++.old-deja/g++.eh/rethrow5.C execution test
FAIL: g++.old-deja/g++.eh/rethrow6.C execution test
FAIL: g++.old-deja/g++.eh/spec1.C execution test
FAIL: g++.old-deja/g++.eh/spec2.C execution test
FAIL: g++.old-deja/g++.eh/spec3.C execution test
FAIL: g++.old-deja/g++.eh/spec4.C execution test
FAIL: g++.old-deja/g++.eh/tmpl1.C execution test
FAIL: g++.old-deja/g++.eh/unwind1.C execution test
FAIL: g++.old-deja/g++.eh/vbase1.C execution test
FAIL: g++.old-deja/g++.eh/vbase2.C execution test
FAIL: g++.old-deja/g++.eh/vbase4.C execution test
FAIL: g++.old-deja/g++.martin/new1.C execution test
FAIL: g++.old-deja/g++.mike/dyncast1.C execution test
FAIL: g++.old-deja/g++.mike/dyncast2.C execution test
FAIL: g++.old-deja/g++.mike/eh10.C execution test
FAIL

[Bug c++/25316] POD structures can have

[mrs at apple dot com]

--- Comment #1 from mrs at apple dot com  2005-12-08 20:51 ---
Ah, Geoff found it:

  The definition of 'aggregate' is in 8.5.1

I new it was there someplace.


-- 

mrs at apple dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID
Summary|POD structures can have |POD structures can have


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

[Bug c++/25316] New: POD structures can have

[mrs at apple dot com]

A user reported that this:

mrs $ cat > t98.c
struct X {
int a, b;
X() : a(0), b(0) {}
};

static void f(const char *s, ...);

int main()
{
X x;
f("foo!", x);
return 0;
}

works on other C++ compilers (Metroworks), but on gcc:

mrs $ ./g++ -B./ -c t98.c
t98.c: In function 'int main()':
t98.c:11: warning: cannot pass objects of non-POD type 'struct X' through
'...'; call will abort at runtime

This, according the a reading of the standard is a POD type, no, really.  :-) 
Curious though, the same misreading of the text was done by the author of:

3 It is possible to transfer into  a  block,  but  not  in  a  way  that
  bypasses declarations with initialization.  A  program  that  jumps77)
  from a point where a local variable with automatic storage duration is
  not in scope to a point where it is in scope is ill-formed unless  the
  variable  has POD type (_basic.types_) and is declared without an ini-
  tializer (_dcl.init_).

as the intent was to not bypass a constructor call.

Also curious is the wording:

  To default-initialize an object of type T means:

  --if T is a non-POD class type (clause _class_), the default construc-
tor  for  T is called (and the initialization is ill-formed if T has
no accessible default constructor);

which again reinforces the idea that only non-PODs can have default
constructors called.

Seems like we need a DR to clarify this, if one doesn't aready exist, and then
to fix up the compiler, if any fixups need to be done.  I'd expect that the
compiler behavior is correct, but until DRed.


-- 
   Summary: POD structures can have
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com


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

[Bug debug/25023] [4.1/4.2 Regression] ICE in def_cfa_1, at dwarf2out.c:792

[rth at gcc dot gnu dot org]

--- Comment #12 from rth at gcc dot gnu dot org  2005-12-08 19:12 ---
This patch is ok.


-- 


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

[Bug fortran/20844] ADVANCE=specifier in output statement

[pault at gcc dot gnu dot org]

-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
Summary|error needed|ADVANCE=specifier in output
   ||statement


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

[Bug c/25314] [3.4/4.0/4.1/4.2 Regression] Unreachable code at beginning of switch statement is not reported anymore

[Uwe dot Seimet at seimet dot de]

--- Comment #4 from Uwe dot Seimet at seimet dot de  2005-12-08 19:05 
---
Subject: Re:  [3.4/4.0/4.1/4.2 Regression] Unreachable code at beginning of
switch statement is not reported anymore

Hello,

> > It would be nice for -Wall to include -Wunreachable-code, similar to how
> > it was in gcc 3.3.
> 
> -Wunreachable-code was not in included with -Wall in 3.3 but a different
> warning was enabled for this.

Yes, but at least there was a warning (even though a different one) when
using gcc 3.3 and -Wall. With 4.0.2 and -Wall there is no warning at all.
If I had not still been using 3.3 while migrating to 4.0.2 I would never
have found this bug in my code, because 4.0.2 did not report it with
-Wall.

Best regards,   Uwe


-- 


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

[Bug c/25314] [3.4/4.0/4.1/4.2 Regression] Unreachable code at beginning of switch statement is not reported anymore

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2005-12-08 18:59 ---
(In reply to comment #2)
> It would be nice for -Wall to include -Wunreachable-code, similar to how
> it was in gcc 3.3.

-Wunreachable-code was not in included with -Wall in 3.3 but a different
warning was enabled for this.


-- 


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

[Bug libstdc++/25315] New: [4.2 regression] testsuite failure:27_io/basic_ostream/inserters_character/char/9555-oc.cc wchar_t/9555-oc.cc exec

[hp at gcc dot gnu dot org]

I see this regression on two different machines.
Last known to work with: "Wed Dec  7 13:39:51 UTC 2005 (revision 108164M)".
Known to fail with: "Thu Dec  8 09:08:46 UTC 2005 (revision 108221M)".
With LAST_UPDATED: "Thu Dec  8 10:28:12 UTC 2005 (revision 108225M)" I still
get:
FAIL: 27_io/basic_ostream/inserters_character/char/9555-oc.cc execution test
FAIL: 27_io/basic_ostream/inserters_character/wchar_t/9555-oc.cc execution test

With the message in the .log being:
...
PASS: 27_io/basic_ostream/inserters_character/char/9555-oc.cc (test for excess
errors)
core: 4 byte misaligned read to address 0x19 at 0x92a0a^M
program stopped with signal 10.^M
FAIL: 27_io/basic_ostream/inserters_character/char/9555-oc.cc execution test
...
PASS: 27_io/basic_ostream/inserters_character/wchar_t/9555-oc.cc (test for
excess errors)
core: 4 byte misaligned read to address 0x19 at 0x924d8^M
program stopped with signal 10.^M
FAIL: 27_io/basic_ostream/inserters_character/wchar_t/9555-oc.cc execution test


-- 
   Summary: [4.2 regression] testsuite
failure:27_io/basic_ostream/inserters_character/char/955
5-oc.cc wchar_t/9555-oc.cc exec
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux-gnu, x86_64-unknown-linux-gnu
GCC target triplet: cris-axis-linux-gnu


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

[Bug c/25314] [3.4/4.0/4.1/4.2 Regression] Unreachable code at beginning of switch statement is not reported anymore

[Uwe dot Seimet at seimet dot de]

--- Comment #2 from Uwe dot Seimet at seimet dot de  2005-12-08 18:37 
---
Subject: Re:  [3.4/4.0/4.1/4.2 Regression] Unreachable code at beginning of
switch statement is not reported anymore

Hello,

> Hmm, someone else has to do decide if we only want to warn about this with
> -Wunreachable-code or with just -W -Wall because 3.4.0 and above only warn 
> with
> -Wunreachable-code.

Thank you for your quick response! It was not obvious for me that
-Wunreachable-code would enable the correct warning, since in previous
versions this warning was covered by -Wall.
It would be nice for -Wall to include -Wunreachable-code, similar to how
it was in gcc 3.3.

Best regards,  Uwe


-- 


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

[Bug c/25314] [3.4/4.0/4.1/4.2 Regression] Unreachable code at beginning of switch statement is not reported anymore

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2005-12-08 18:32 ---
Hmm, someone else has to do decide if we only want to warn about this with
-Wunreachable-code or with just -W -Wall because 3.4.0 and above only warn with
-Wunreachable-code.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c++ |c
   Keywords||diagnostic
Summary|Unreachable code at |[3.4/4.0/4.1/4.2 Regression]
   |beginning of switch |Unreachable code at
   |statement is not reported   |beginning of switch
   |anymore |statement is not reported
   ||anymore
   Target Milestone|--- |4.0.3


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

[Bug fortran/17737] ICE when variable appears in two data statements

[pinskia at gcc dot gnu dot org]

--- Comment #16 from pinskia at gcc dot gnu dot org  2005-12-08 18:14 
---
(In reply to comment #15)
> Subject: Re:  ICE when variable appears in two data statements
> This is not a duplicated bug, because I recently installed the 
> last version of gcc and recompiled the operational system.
> Why is this problem not solved?

4.0.3 has not been released yet.  It has been fixed for 4.0.3 and 4.1.0 both of
which are currently CVS/SVN versions only with a snapshot provided for both of
them.


-- 


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

[Bug c++/25314] New: Unreachable code at beginning of switch statement is not reported anymore

[Uwe dot Seimet at seimet dot de]

The warning available in previous versions of gcc (at least until gcc 3.3)
'unreachable code at beginning of switch statement' is not reported anymore.
This behavior hides programming errors. When compiling this code sample with
'c++ -Wall test.cpp':

int main()
{
int a;

switch(1)
{
a = 1;
break;

default:
break;
}

return 0;
}

No warning is reported. Older versions of gcc issue a warning here. Using
additional switch-related warnings like -Wswitch does not change anything.


-- 
   Summary: Unreachable code at beginning of switch statement is not
reported anymore
   Product: gcc
   Version: 4.0.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Uwe dot Seimet at seimet dot de
 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=25314

[Bug c/25309] [3.4/4.0/4.1/4.2 Regression] ICE on initialization of a huge array

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[3.4/4.0/4.1 Regression] ICE|[3.4/4.0/4.1/4.2 Regression]
   |on initialization of a huge |ICE on initialization of a
   |array   |huge array
   Target Milestone|--- |4.0.3


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

[Bug fortran/17737] ICE when variable appears in two data statements

[segalemb at usp dot br]

--- Comment #15 from segalemb at usp dot br  2005-12-08 18:10 ---
Subject: Re:  ICE when variable appears in two data statements

This is not a duplicated bug, because I recently installed the 
last version of gcc and recompiled the operational system.
Why is this problem not solved?

   Best regards,

Sergio
Citando pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]>:

> 
> 
> --- Comment #14 from pinskia at gcc dot gnu dot org  2005-12-08 17:49
> ---
> *** Bug 25312 has been marked as a duplicate of this bug. ***
> 
> 
> -- 
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17737
> 
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.
> 


-- 


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

[Bug fortran/17737] ICE when variable appears in two data statements

[pinskia at gcc dot gnu dot org]

--- Comment #14 from pinskia at gcc dot gnu dot org  2005-12-08 17:49 
---
*** Bug 25312 has been marked as a duplicate of this bug. ***


-- 


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

[Bug fortran/25312] error in indexes in data assignment

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2005-12-08 17:49 ---
Fixed in 4.0.3 by allowing this without -pedantic-errors.

This is a dup of bug 17737.

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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE
   Target Milestone|--- |4.1.0


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

[Bug fortran/25312] error in indexes in data assignment

[segalemb at usp dot br]

--- Comment #1 from segalemb at usp dot br  2005-12-08 17:26 ---
Created an attachment (id=10442)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10442&action=view)
a.s


-- 


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

[Bug fortran/25312] New: error in indexes in data assignment

[segalemb at usp dot br]

Hello,

 When I try to compile the code:

==
 module param
  double precision mutdefc(8,5)
  data mutdefc(1,1)/0.D0/
  data mutdefc(1,1)/0.D0/
  end module param


witth the same indexes in both assignments of mutdefc, the compliler presents
an internal error:

===
Driving: gfortran40 -v -g -save-temps a.F -lgfortranbegin -lgfortran -lm
Using built-in specs.
Target: i386-portbld-freebsd5.4
Configured with: ./..//gcc-4.0-20050728/configure --disable-nls
--with-system-zlib --with-libiconv-prefix=/usr/local --program-suffix=40
--libdir=/usr/local/lib/gcc/i386-portbld-freebsd5.4/4.0.2
--with-gxx-include-dir=/usr/local/lib/gcc/i386-portbld-freebsd5.4/4.0.2/include/c++/
--with-gmp=/usr/local --disable-shared --prefix=/usr/local
i386-portbld-freebsd5.4
Thread model: posix
gcc version 4.0.2 20050728 (prerelease) [FreeBSD]
 /usr/local/libexec/gcc/i386-portbld-freebsd5.4/4.0.2/cc1 -E -traditional-cpp
-D_LANGUAGE_FORTRAN -quiet -v a.F -fworking-directory -fpch-preprocess -o a.f
ignoring nonexistent directory
"/usr/local/lib/gcc/i386-portbld-freebsd5.4/4.0.2/gcc/i386-portbld-freebsd5.4/4.0.2/../../../../i386-portbld-freebsd5.4/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include

/usr/local/lib/gcc/i386-portbld-freebsd5.4/4.0.2/gcc/i386-portbld-freebsd5.4/4.0.2/include
 /usr/include
End of search list.
 /usr/local/libexec/gcc/i386-portbld-freebsd5.4/4.0.2/f951 a.f -ffixed-form
-quiet -dumpbase a.F -auxbase a -g -version -o a.s
GNU F95 version 4.0.2 20050728 (prerelease) [FreeBSD] (i386-portbld-freebsd5.4)
compiled by GNU C version 4.0.2 20050728 (prerelease) [FreeBSD].
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
a.f:0: internal compiler error: in gfc_assign_data_value, at fortran/data.c:319
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

===

but, whwn I change the indexes of mutdefc, as mutdefc(1,1) and mutdefc(1,2) the 
executable is generated.

 Thank you very much,

Sergio


-- 
   Summary: error in indexes in data assignment
   Product: gcc
   Version: 4.0.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: segalemb at usp dot br


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

[Bug target/24894] ICE building newlib/libc/misc/init.c

[berndtrog at yahoo dot com]

--- Comment #3 from berndtrog at yahoo dot com  2005-12-08 17:14 ---
PR 19636 fails only when compiled with -Os, while
this one fails only when compiled with -O2 or -O3.


-- 


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

[Bug libstdc++/25304] std::fill_n, std::generate_n incorrect signature

[gdr at integrable-solutions dot net]

--- Comment #16 from gdr at integrable-solutions dot net  2005-12-08 17:12 
---
Subject: Re:  std::fill_n, std::generate_n incorrect signature

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

| + the more general consideration that, delivering a C++0x conforming
| library certainly will involve breaking the ABI in tens of different
| ways 

I have no trouble with that.
My main concern is whether the flip flop worths it *if* we're going to
change back.

-- Gaby


-- 


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

[Bug fortran/25292] ASSOCIATED( func() ) rejected ?

[eedelman at gcc dot gnu dot org]

--- Comment #4 from eedelman at gcc dot gnu dot org  2005-12-08 17:04 
---
Subject: Bug 25292

Author: eedelman
Date: Thu Dec  8 17:04:54 2005
New Revision: 108241

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108241
Log:
fortran/
2005-12-08  Erik Edelmann  <[EMAIL PROTECTED]>

PR fortran/25292
* check.c (gfc_check_associated): Allow function results
as actual arguments to ASSOCIATED.  Moved a misplaced
comment.


testsuite/
2005-12-08  Erik Edelmann  <[EMAIL PROTECTED]>

PR fortran/25292
* gfortran.dg/associated_1.f90: New.


Added:
branches/gcc-4_0-branch/gcc/testsuite/gfortran.dg/associated_1.f90
Modified:
branches/gcc-4_0-branch/gcc/fortran/ChangeLog
branches/gcc-4_0-branch/gcc/fortran/check.c
branches/gcc-4_0-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/25292] ASSOCIATED( func() ) rejected ?

[eedelman at gcc dot gnu dot org]

--- Comment #3 from eedelman at gcc dot gnu dot org  2005-12-08 17:00 
---
Subject: Bug 25292

Author: eedelman
Date: Thu Dec  8 17:00:26 2005
New Revision: 108239

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108239
Log:
fortran/
2005-12-08  Erik Edelmann  <[EMAIL PROTECTED]>

PR fortran/25292
* check.c (gfc_check_associated): Allow function results
as actual arguments to ASSOCIATED.  Moved a misplaced
comment.


testsuite/
2005-12-08  Erik Edelmann  <[EMAIL PROTECTED]>

PR fortran/25292
* gfortran.dg/associated_1.f90: New.


Added:
branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/associated_1.f90
Modified:
branches/gcc-4_1-branch/gcc/fortran/check.c
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/25292] ASSOCIATED( func() ) rejected ?

[eedelman at gcc dot gnu dot org]

--- Comment #2 from eedelman at gcc dot gnu dot org  2005-12-08 16:56 
---
Subject: Bug 25292

Author: eedelman
Date: Thu Dec  8 16:56:10 2005
New Revision: 108238

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108238
Log:
fortran/
2005-12-08  Erik Edelmann  <[EMAIL PROTECTED]>

PR fortran/25292
* check.c (gfc_check_associated): Allow function results
as actual arguments to ASSOCIATED.  Moved a misplaced
comment.


testsuite/
2005-12-08  Erik Edelmann  <[EMAIL PROTECTED]>

PR fortran/25292
* gfortran.dg/associated_1.f90: New.



Added:
trunk/gcc/testsuite/gfortran.dg/associated_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/check.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c/25309] [3.4/4.0/4.1 Regression] ICE on initialization of a huge array

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2005-12-08 16:55 ---
HOST_WIDE_INT is what it says.  The code should check host_integerp first and
then use TREE_INT_CST_LOW.


-- 


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

[Bug libstdc++/25304] std::fill_n, std::generate_n incorrect signature

[sebor at roguewave dot com]

--- Comment #15 from sebor at roguewave dot com  2005-12-08 16:27 ---
(In reply to comment #11)

Okay, I see your concern.

Well, IMO, your signatures are better than those required by the standard so if
you care about 100% compliance you (or Paolo -- and I promise not to beat him
;-) should open an issue with the LWG and try to get the standard changed. I
will support the change. Until the LWG issue is resolved (and hopefully even
after that) you can leave your signatures alone.


-- 


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

[Bug libstdc++/25304] std::fill_n, std::generate_n incorrect signature

[gdr at integrable-solutions dot net]

--- Comment #14 from gdr at integrable-solutions dot net  2005-12-08 16:23 
---
Subject: Re:  std::fill_n, std::generate_n incorrect signature

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

| 2- As I see the issue, it depends a lot on the actual timeframe of
| the possible enhancement to the standard. I mean, if we are thinking
| about C++0x, seems rather far in time. I think most of our users
| would not perceive our practice as randomly going back and forward
| on something. 

Fair enough.

(At Lillehammer, we set to have x, in C++0x, a digit; so that means
we're almost done by 2007.  That is not far, given that LWG would not
need to wait 2007 before agreeing on the issue.  I was amazed to
discover that CWG two two meetings to open an issue and move it to WP.
LWG could do the same.  Hint, hint, :-))

-- Gaby


-- 


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

[Bug libstdc++/25304] std::fill_n, std::generate_n incorrect signature

[pcarlini at suse dot de]

--- Comment #13 from pcarlini at suse dot de  2005-12-08 16:20 ---
(In reply to comment #12)

> 2- As I see the issue, it depends a lot on the actual timeframe of the 
> possible
> enhancement to the standard. I mean, if we are thinking about C++0x, seems
> rather far in time. I think most of our users would not perceive our practice
> as randomly going back and forward on something.

+ the more general consideration that, delivering a C++0x conforming library
certainly will involve breaking the ABI in tens of different ways (e.g., I have
in front of me the implementation of DR 130, only a very simple and relatively
trivial example).


-- 


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

[Bug libstdc++/25304] std::fill_n, std::generate_n incorrect signature

[pcarlini at suse dot de]

--- Comment #12 from pcarlini at suse dot de  2005-12-08 16:11 ---
(In reply to comment #11)
> However, I'm looking at the pratical effect.  If libstdc++ changes the
> return types (correcting the bug) then it will be an ABI breakage.
> If LWG considers and agrees on the enhancement, libstdc++ will have to
> change again the return types.  At the end of the day we would have
> two ABI breakages with zero net benefit for existing libstdc++ users.

I share your concerns. Want to add a couple of thoughts:
1- When we broke the ABI to fix 16505, I think we did that with the spirit that
it was a, so to speak, "weak" breakage, because could possibly byte only people
using the return value, something not standard conforming. Indeed, we received
zero complaints, as I already remarked.
2- As I see the issue, it depends a lot on the actual timeframe of the possible
enhancement to the standard. I mean, if we are thinking about C++0x, seems
rather far in time. I think most of our users would not perceive our practice
as randomly going back and forward on something.


-- 


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

[Bug libstdc++/25304] std::fill_n, std::generate_n incorrect signature

[gdr at integrable-solutions dot net]

--- Comment #11 from gdr at integrable-solutions dot net  2005-12-08 16:04 
---
Subject: Re:  std::fill_n, std::generate_n incorrect signature

"sebor at roguewave dot com" <[EMAIL PROTECTED]> writes:

| No, I don't. The standard is clear and most of us seem to think it's "by
| design." Rather I am suggesting is that we might want to discuss with the
whole
| LWG changing the return type as an enhancement.

I think I understand that.  

However, I'm looking at the pratical effect.  If libstdc++ changes the
return types (correcting the bug) then it will be an ABI breakage.
If LWG considers and agrees on the enhancement, libstdc++ will have to
change again the return types.  At the end of the day we would have
two ABI breakages with zero net benefit for existing libstdc++ users.

-- Gaby


-- 


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

[Bug middle-end/25248] [4.1 Regression] 2.6.15-rc4 arch/powerpc/mm/hash_utils_64.c miscompiled

[pinskia at gcc dot gnu dot org]

--- Comment #27 from pinskia at gcc dot gnu dot org  2005-12-08 15:54 
---
Fixed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug c/25309] [3.4/4.0/4.1 Regression] ICE on initialization of a huge array

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2005-12-08 15:54 ---
Confirmed.  This is only reproducible on targets where HOST_WIDE_INT is 32bits
(and I still say that HOST_WIDE_INT should be always at least 64bits).  Oh and
this is a regression for at least x86.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|i686-pc-linux-gnu   |
   GCC host triplet|i686-pc-linux-gnu   |
   Keywords||ice-on-invalid-code
  Known to fail||3.3.3 3.2.3 3.4.0 4.0.0
   ||4.1.0 4.2.0
  Known to work||3.0.4
   Last reconfirmed|-00-00 00:00:00 |2005-12-08 15:54:05
   date||
Summary|ICE on initialization of a  |[3.4/4.0/4.1 Regression] ICE
   |huge array  |on initialization of a huge
   ||array


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

[Bug libstdc++/25304] std::fill_n, std::generate_n incorrect signature

[sebor at roguewave dot com]

--- Comment #10 from sebor at roguewave dot com  2005-12-08 15:51 ---
No, I don't. The standard is clear and most of us seem to think it's "by
design." Rather I am suggesting is that we might want to discuss with the whole
LWG changing the return type as an enhancement.


-- 


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

[Bug middle-end/25248] [4.1 Regression] 2.6.15-rc4 arch/powerpc/mm/hash_utils_64.c miscompiled

[rakdver at gcc dot gnu dot org]

--- Comment #26 from rakdver at gcc dot gnu dot org  2005-12-08 15:44 
---
Subject: Bug 25248

Author: rakdver
Date: Thu Dec  8 15:44:22 2005
New Revision: 108236

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108236
Log:
PR tree-optimization/25248
* tree-scalar-evolution.c (follow_ssa_edge_in_rhs): Do not use
evolution_of_loop from the failed attempt.  Remove handling of
MULT_EXPR.


Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/tree-scalar-evolution.c


-- 


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

[Bug c++/25152] [3.4/4.0 only] no warning from -Wstrict-aliasing for C++ code

[pinskia at gcc dot gnu dot org]

--- Comment #9 from pinskia at gcc dot gnu dot org  2005-12-08 15:43 ---
(In reply to comment #8)
> For 4.0, it is IMHO a bad idea to backport this, there are tons of programs
> built with -Werror and if we suddenly start issuing a huge amount of new
> warnings (and this warning has sometimes many false positives), we'd force
> people to change packages a lot.  People are used to do this kind of things
> when porting to a newer major GCC version, but e.g. when upgrading from
> x.y.z to x.y.z+1 it is not expected.

They might not be expecting this.  The warning has very few false warnings.

Actually they are broken (in fact they don't know what hit them in 4.0.x).  In
fact 4.0.x already uses strict aliasing information more than 3.4.0.  I also
have seen 3.4.x use strict aliasing more than 3.3.3 did too.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2005-12-08 15:43:23
   date||
Summary|[4.0 only] no warning from -|[3.4/4.0 only] no warning
   |Wstrict-aliasing for C++|from -Wstrict-aliasing for
   |code|C++ code
   Target Milestone|4.1.0   |4.0.3


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

[Bug libgcj/25265] linking BC-compiled classes with incompatible changes

[aph at gcc dot gnu dot org]

--- Comment #6 from aph at gcc dot gnu dot org  2005-12-08 15:32 ---
Subject: Bug 25265

Author: aph
Date: Thu Dec  8 15:32:44 2005
New Revision: 108235

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108235
Log:
2005-12-08  Andrew Haley  <[EMAIL PROTECTED]>

PR libgcj/25265
* java-tree.h (enum java_tree_index): Add JTI_SOFT_NOSUCHFIELD_NODE.
(soft_abstractmethod_node): New.
* expr.c (build_field_ref): Add in-line check for missing field.
* decl.c (java_init_decl_processing): Add soft_nosuchfield_node.

2005-12-08  Andrew Haley  <[EMAIL PROTECTED]>

PR libgcj/25265
* java/lang/Object.h (throwNoSuchMethodError): New method.
* java/lang/Object.java (throwNoSuchMethodError): New method.
* include/jvm.h (_Jv_ThrowNoSuchFieldError): Declare.
* link.cc (_Jv_ThrowNoSuchFieldError): New.
(link_symbol_table): Don't throw a NoSuchFieldError if a field is
missing.  Instead, set the otable entry to zero.
(link_symbol_table): If we don't find a nonstatic method, insert
the vtable offset of Object.throwNoSuchMethodError() into the
otable.


Modified:
trunk/gcc/java/ChangeLog
trunk/libjava/ChangeLog


-- 


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

Re: GCC Compiling Problem

[Peter Loo (sent by Nabble.com)]

Hi Joel,

I have PERL 5.8.7 and still does not work.  I used the "--enable-languages" as 
you had advised, but now I am getting the following errors:

"Makefile", line 821: make: Dependency line needs colon or double colon 
operator.
"Makefile", line 822: make: Dependency line needs colon or double colon 
operator.
"Makefile", line 823: make: Dependency line needs colon or double colon 
operator.
"Makefile", line 824: make: Dependency line needs colon or double colon 
operator.
"Makefile", line 825: make: Dependency line needs colon or double colon 
operator.
"Makefile", line 826: make: Dependency line needs colon or double colon 
operator.
"Makefile", line 827: make: Dependency line needs colon or double colon 
operator.
"Makefile", line 828: make: Dependency line needs colon or double colon 
operator.
"Makefile", line 829: make: Dependency line needs colon or double colon 
operator.
"Makefile", line 830: make: Dependency line needs colon or double colon 
operator.
"Makefile", line 831: make: Dependency line needs colon or double colon 
operator.
"Makefile", line 832: make: Dependency line needs colon or double colon 
operator.
"Makefile", line 833: make: Dependency line needs colon or double colon 
operator.
"Makefile", line 834: make: Dependency line needs colon or double colon 
operator.
"Makefile", line 835: make: Dependency line needs colon or double colon 
operator.
"Makefile", line 836: make: Dependency line needs colon or double colon 
operator.
"Makefile", line 1034: make: Dependency line needs colon or double colon 
operator.
"Makefile", line 1037: make: Dependency line needs colon or double colon 
operator.
"../../gcc-4.0.2/gcc/cp/Make-lang.in", line 136: make: Dependency line needs 
colon or double colon operator.
"Makefile", line 1039: make: Dependency line needs colon or double colon 
operator.
"Makefile", line 1045: make: Dependency line needs colon or double colon 
operator.
"Makefile", line 1047: make: Dependency line needs colon or double colon 
operator.
"Makefile", line 1050: make: Dependency line needs colon or double colon 
operator.
"", line 0: make: Cannot open 
"Makefile", line 1052: make: Dependency line needs colon or double colon 
operator.
"Makefile", line 2259: make: Dependency line needs colon or double colon 
operator.
make: Fatal errors encountered -- cannot continue.
make: The error code from the last command is 2.


Stop.

Thanks.

Peter Loo
--
Sent from the gcc - bugs forum at Nabble.com:
http://www.nabble.com/GCC-Compiling-Problem-t528973.html#a1852878

[Bug middle-end/25248] [4.1 Regression] 2.6.15-rc4 arch/powerpc/mm/hash_utils_64.c miscompiled

[rguenth at gcc dot gnu dot org]

--- Comment #25 from rguenth at gcc dot gnu dot org  2005-12-08 15:11 
---
Zdenek, can you please apply to the 4.1 branch, too?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.1/4.2 Regression] 2.6.15-|[4.1 Regression] 2.6.15-rc4
   |rc4 |arch/powerpc/mm/hash_utils_6
   |arch/powerpc/mm/hash_utils_6|4.c miscompiled
   |4.c miscompiled |


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

[Bug libgcj/25265] linking BC-compiled classes with incompatible changes

[aph at gcc dot gnu dot org]

--- Comment #5 from aph at gcc dot gnu dot org  2005-12-08 14:44 ---
Subject: Bug 25265

Author: aph
Date: Thu Dec  8 14:44:29 2005
New Revision: 108233

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108233
Log:
2005-12-08  Andrew Haley  <[EMAIL PROTECTED]>

PR libgcj/25265
* java/lang/Object.h (throwNoSuchMethodError): New method.
* java/lang/Object.java (throwNoSuchMethodError): New method.
* include/jvm.h (_Jv_ThrowNoSuchFieldError): Declare.
* link.cc (_Jv_ThrowNoSuchFieldError): New.
(link_symbol_table): Don't throw a NoSuchFieldError if a field is
missing.  Instead, set the otable entry to zero.
(link_symbol_table): If we don't find a nonstatic method, insert
the vtable offset of Object.throwNoSuchMethodError() into the
otable.


Modified:
branches/gcc-4_1-branch/libjava/ChangeLog


-- 


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

[Bug libgcj/25265] linking BC-compiled classes with incompatible changes

[aph at gcc dot gnu dot org]

--- Comment #4 from aph at gcc dot gnu dot org  2005-12-08 14:40 ---
Subject: Bug 25265

Author: aph
Date: Thu Dec  8 14:40:48 2005
New Revision: 108232

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108232
Log:
2005-12-08  Andrew Haley  <[EMAIL PROTECTED]>

PR libgcj/25265
* java-tree.h (enum java_tree_index): Add JTI_SOFT_NOSUCHFIELD_NODE.
(soft_abstractmethod_node): New.
* expr.c (build_field_ref): Add in-line check for missing field.
* decl.c (java_init_decl_processing): Add soft_nosuchfield_node.


Modified:
branches/gcc-4_1-branch/gcc/java/ChangeLog
branches/gcc-4_1-branch/gcc/java/decl.c
branches/gcc-4_1-branch/gcc/java/expr.c
branches/gcc-4_1-branch/gcc/java/java-tree.h


-- 


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

[Bug libfortran/25271] gfortran fails to pad lines in format statements to 72 characters.

[dir at lanl dot gov]

--- Comment #5 from dir at lanl dot gov  2005-12-08 14:16 ---
Your are likely correct - it probability is not in the standard, but for the
first 15 years of FORTRAN, keypunches and card readers were the only way to
create and submit a program and they always pad to 80 characters - by
definition a line of FORTRAN was 80 character - since a card reader was the
only way to get a program to the computer. If the modern text editors, that
mostly truncate as they please had been around - the padding requirement would
have been in the standard. Actually, I am surprized that FORTRAN 77 did not add
that requirement to the standard.


-- 


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

[Bug target/25311] [4.1 Regression] ICE in reload_cse_simplify_operands, at postreload.c:393

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2005-12-08 14:08 ---
Reduced testcase:

typedef long Lisp_Object;
extern Lisp_Object Qnil;
struct window {
int pixel_top;
int pixel_height; 
int pixel_width;
Lisp_Object next;
Lisp_Object parent;
};
static void set_window_pixsize (Lisp_Object window, int new_pixsize, int
nodelete, int set_height) {
struct window *w = ((struct window *) ((void *) (window)));
struct window *c;
int old_pixsize = (set_height ? ((w)->pixel_height) : ((w)->pixel_width));
Lisp_Object child, minor_kid, major_kid;
int minsize;
int line_size;
if (!nodelete
&& !(((w)->parent) == (Qnil))
&& new_pixsize < minsize)
  {
  }
else if (!((major_kid) == (Qnil)))
  {
int last_pos, last_old_pos, pos, old_pos, first;
int div_val = old_pixsize << 1;
for (child = major_kid; !((child) == (Qnil)); child = c->next)
  {
c = ((struct window *) ((void *) (child)));
if (set_height)
  {
old_pos = last_old_pos + ((c)->pixel_height);
((c)->pixel_top) = last_pos;
  }
pos = (((old_pos * new_pixsize) << 1) + old_pixsize) / div_val;
if (!((c->next) == (Qnil)))
  pos = (pos / line_size) * line_size;
set_window_pixsize (child, pos + first - last_pos, 1, set_height);
last_pos = pos + first;
  }
  }
}
void set_window_pixheight (Lisp_Object window, int new_pixheight, int nodelete)
{
   set_window_pixsize (window, new_pixheight, nodelete, 1);
}


-- 


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

[Bug target/25311] [4.1 Regression] ICE in reload_cse_simplify_operands, at postreload.c:393

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2005-12-08 14:02 ---
Created an attachment (id=10441)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10441&action=view)
testcase (unreduced)

testcase. reducing.


-- 


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

[Bug target/25311] New: [4.1 Regression] ICE in reload_cse_simplify_operands, at postreload.c:393

[rguenth at gcc dot gnu dot org]

Maybe related to 25310.  We fail to build xemacs with:

/usr/lib64/gcc/s390x-suse-linux/4.1.0/cc1 -fpreprocessed window.i -quiet
-dumpbase window.i -m64 -mzarch -march=z900 -auxbase window -g -O2 -Wall
-Wno-switch -Wundef -Wsign-compare -Wno-char-subscripts -Wpacked
-Wunused-parameter -Wall -Wall -Wno-switch -version -fmessage-length=0
-fno-strict-aliasing -o /tmp/ccZf90fd.s
window.c: In function ‘set_window_pixsize’:
window.c:3584: error: insn does not satisfy its constraints:
(insn:QI 70 410 71 4 window.c:3487 (set (reg:CCZ 33 %cc)
(compare:CCZ (mem/s/j:DI (plus:DI (reg/v:DI 11 %r11 [orig:66 window ]
[66])
(const_int 208 [0xd0])) [0 .parent+0 S8 A64])
(mem/c/i:DI (reg:DI 13 %r13) [0 Qnil+0 S8 A64]))) 24 {*cmpdi_cct}
(insn_list:REG_DEP_TRUE 67 (nil))
(nil))
window.c:3584: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:393
Please submit a full bug report,
with preprocessed source if appropriate.
See http://www.suse.de/feedback> for instructions.


-- 
   Summary: [4.1 Regression] ICE in reload_cse_simplify_operands, at
postreload.c:393
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
GCC target triplet: s390x-*-linux-gnu


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

[Bug c++/20552] [3.4 Regression] ICE in write_type, at cp/mangle.c:1579

[reichelt at gcc dot gnu dot org]

--- Comment #5 from reichelt at gcc dot gnu dot org  2005-12-08 13:55 
---
Patch posted.


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |reichelt at gcc dot gnu dot
   |dot org |org
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2005-
   ||12/msg00613.html
 Status|NEW |ASSIGNED
   Keywords||patch


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

[Bug c++/19441] [3.4 regression] Bad error message with invalid destructor declaration

[reichelt at gcc dot gnu dot org]

--- Comment #3 from reichelt at gcc dot gnu dot org  2005-12-08 13:42 
---
This is now also fixed on the 3.4 branch (probably by the patch for PR19397).
We now get the following error message:

bug.cc:3: error: type/value mismatch at argument 1 in template parameter list
for `template > struct A'
bug.cc:3: error:   expected a constant of type `char', got `char'


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug target/25310] [4.1 Regression] ICE in reload_cse_simplify_operands, at postreload.c:393

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2005-12-08 13:38 ---
Reduced testcase:

typedef enum {   HTTP_FIELD_MAX } http_field_t;
typedef struct {   char hostname[256],fields[HTTP_FIELD_MAX][256]; }
http_t;
extern int httpRead(http_t *http, char *buffer, int length);
translate_messages(const char *language)
{
   http_t *http;
   char buffer[65536], *bufptr, *bufend;
   int bytes;
   bufend = buffer + sizeof(buffer) - 1;
   while ((bytes = httpRead(http, bufptr, bufend - bufptr)) > 0)
 ;
}

(please make sure the original testcase works, too)


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||uweigand at gcc dot gnu dot
   ||org


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

[Bug target/25310] [4.1 Regression] ICE in reload_cse_simplify_operands, at postreload.c:393

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2005-12-08 13:35 ---
Created an attachment (id=10440)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10440&action=view)
testcase (unreduced)

testcase.  reducing.


-- 


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

[Bug target/25310] New: [4.1 Regression] ICE in reload_cse_simplify_operands, at postreload.c:393

[rguenth at gcc dot gnu dot org]

We fail to build cupsddk:

/usr/lib64/gcc/s390x-suse-linux/4.1.0/cc1 -quiet espmsg.i -quiet -m64 -mzarch
-march=z900 -O2 -fmessage-length=0 -o /tmp/cc8yapDN.s
espmsg.c: In function ‘translate_messages’:
espmsg.c:923: error: insn does not satisfy its constraints:
(insn 715 266 716 25 (set (reg:DI 2 %r2)
(const_int 65736 [0x100c8])) 47 {*movdi_64} (nil)
(nil))
espmsg.c:923: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:393
Please submit a full bug report,
with preprocessed source if appropriate.
See http://www.suse.de/feedback> for instructions.


-- 
   Summary: [4.1 Regression] ICE in reload_cse_simplify_operands, at
postreload.c:393
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
GCC target triplet: s390x-*-linux-gnu


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

[Bug debug/25023] [4.1/4.2 Regression] ICE in def_cfa_1, at dwarf2out.c:792

[jakub at gcc dot gnu dot org]

--- Comment #11 from jakub at gcc dot gnu dot org  2005-12-08 13:11 ---
Created an attachment (id=10439)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10439&action=view)
gcc41-pr25293.patch

This patch disallows 16-bit pushes (similarly how x86_64 disallows
16-bit and 32-bit pushes).  I don't have an i586 to verify how slow pushw
is, but it would surprise me if it was fast.


-- 


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

[Bug target/25299] Another ABI incompatibility with Apple's gcc

[amodra at bigpond dot net dot au]

--- Comment #2 from amodra at bigpond dot net dot au  2005-12-08 13:05 
---
Your testcase fails on powerpc64-linux with -malign-power


-- 


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

[Bug c/25309] New: ICE on initialization of a huge array

[jens dot teubner at in dot tum dot de]

GCC throws an internal compiler error when compiling the following
C99 code (gcc -std=c99 -c):

static char * name[] = {
[0x8000]  = "bar"
};

(GCC reports `internal compiler error: in tree_low_cst, at tree.c:3318'.)

I realize that the above code is quite stupid, as I request the compiler
to create an array of huge size.  However, I think GCC should not throw
an internal compiler error.  For smaller values of the array index, GCC
correctly reports `error: size of variable 'name' is too large'.

I have reproduced the problem with GCC 3.4.4 (Gentoo Linux) and GCC
3.3.5 (SuSE 9.3), both on Intel Pentium M.


-- 
   Summary: ICE on initialization of a huge array
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jens dot teubner at in dot tum dot de
 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=25309

[Bug libfortran/25271] gfortran fails to pad lines in format statements to 72 characters.

[tobi at gcc dot gnu dot org]

--- Comment #4 from tobi at gcc dot gnu dot org  2005-12-08 12:41 ---
The lines are padded (see scanner.c:810), but this doesn't make it into the
format string, which could be construed to be a bug, but since this is not
something required by the standard (at least I think this was the consensus the
last time this came up) I'm downgrading this to enhancement.


-- 

tobi at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tobi at gcc dot gnu dot org
   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2005-12-08 12:41:33
   date||


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

[Bug c++/25152] [4.0 only] no warning from -Wstrict-aliasing for C++ code

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2005-12-08 12:30 ---
-Wstrict-aliasing backport has been committed today to gcc-4_1-branch:
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108226

For 4.0, it is IMHO a bad idea to backport this, there are tons of programs
built with -Werror and if we suddenly start issuing a huge amount of new
warnings (and this warning has sometimes many false positives), we'd force
people to change packages a lot.  People are used to do this kind of things
when porting to a newer major GCC version, but e.g. when upgrading from
x.y.z to x.y.z+1 it is not expected.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.0/4.1 only] no warning   |[4.0 only] no warning from -
   |from -Wstrict-aliasing for  |Wstrict-aliasing for C++
   |C++ code|code


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

[Bug fortran/25297] Support for STRUCTURE/END STRUCTURE and RECORD

[tobi at gcc dot gnu dot org]

-- 

tobi at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2005-12-08 12:28:40
   date||


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

[Bug libstdc++/24617] vector vs __erase_at_end

[pcarlini at suse dot de]

--- Comment #4 from pcarlini at suse dot de  2005-12-08 11:34 ---
Done for 4.2.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

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


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

[Bug libstdc++/24617] vector vs __erase_at_end

[paolo at gcc dot gnu dot org]

--- Comment #3 from paolo at gcc dot gnu dot org  2005-12-08 11:32 ---
Subject: Bug 24617

Author: paolo
Date: Thu Dec  8 11:32:37 2005
New Revision: 108227

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108227
Log:
2005-12-08  Paolo Carlini  <[EMAIL PROTECTED]>

* include/bits/stl_vector.h (vector<>::size, resize, capacity,
operator[]): Avoid troubles with ADL, user defined operators
and __normal_iterator.
(_M_erase_at_end): Fix to take a pointer.
(clear): Adjust call.
* include/bits/vector.tcc (vector<>::insert(iterator, const
value_type&), erase(iterator, iterator), operator=(const
vector<>&), _M_assign_aux(input_iterator_tag), _M_insert_aux,
_M_fill_insert, _M_range_insert): Likewise.
(_M_fill_assign, _M_assign_aux(forward_iterator_tag)): Adjust
_M_erase_at_end call.
* testsuite/23_containers/vector/types/1.cc: New.

2005-12-08  Paolo Carlini  <[EMAIL PROTECTED]>

PR libstdc++/24617
* include/bits/stl_vector.h (vector<>::_M_erase_at_end): New.
(vector<>::clear, resize): Use it.
* include/bits/vector.tcc (vector<>::erase(iterator, iterator),
_M_fill_assign, _M_assign_aux): Likewise.

* testsuite/23_containers/vector/modifiers/erase/1.cc: New.

Added:
trunk/libstdc++-v3/testsuite/23_containers/vector/modifiers/erase/
trunk/libstdc++-v3/testsuite/23_containers/vector/modifiers/erase/1.cc
trunk/libstdc++-v3/testsuite/23_containers/vector/types/1.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/stl_vector.h
trunk/libstdc++-v3/include/bits/vector.tcc


-- 


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

[Bug target/25308] New: [4.2 Regression] 22_locale/locale/cons/12658_thread-1.cc, etc fail

[pcarlini at suse dot de]

FAIL: 22_locale/locale/cons/12658_thread-1.cc execution test
FAIL: 22_locale/locale/cons/12658_thread-2.cc execution test
FAIL: ext/mt_allocator/22309_thread.cc execution test
FAIL: thread/pthread3.cc execution test

appeared on mainline between 20051205 and 20051206.


-- 
   Summary: [4.2 Regression] 22_locale/locale/cons/12658_thread-
1.cc, etc fail
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pcarlini at suse dot de
GCC target triplet: i686-pc-linux-gnu


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

[Bug c++/14024] g++ isn't reporting aliasing warnings

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2005-12-08 11:24 
---
Subject: Bug 14024

Author: rguenth
Date: Thu Dec  8 11:24:07 2005
New Revision: 108226

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108226
Log:
2005-12-08  Richard Guenther  <[EMAIL PROTECTED]>

Backport from mainline
2005-11-28  Richard Guenther  <[EMAIL PROTECTED]>

* c-common.c (strict_aliasing_warning): Handle all
component-ref like accesses.

* gcc.dg/alias-9.c: New testcase.
* g++.dg/warn/Wstrict-aliasing-7.C: Likewise.

2005-11-24  Richard Guenther  <[EMAIL PROTECTED]>
Dirk Mueller <[EMAIL PROTECTED]>

PR c++/14024
* c-common.h (strict_aliasing_warning): Declare.
* c-common.c (strict_aliasing_warning): New function,
split out from ...
* c-typeck.c (build_c_cast): ... here.

* typeck.c (build_reinterpret_cast_1): Use
strict_aliasing_warning.

* g++.dg/warn/Wstrict-aliasing-1.C: New testcase.
* g++.dg/warn/Wstrict-aliasing-2.C: Likewise.
* g++.dg/warn/Wstrict-aliasing-3.C: Likewise.
* g++.dg/warn/Wstrict-aliasing-4.C: Likewise.
* g++.dg/warn/Wstrict-aliasing-5.C: Likewise.
* g++.dg/warn/Wstrict-aliasing-6.C: Likewise.

2005-11-23  Paolo Carlini  <[EMAIL PROTECTED]>

PR libstdc++/24975 (basic_string)
* include/bits/basic_string.h (_Rep::_S_empty_rep): Avoid
strict-aliasing warnings.

Added:
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/warn/Wstrict-aliasing-1.C
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/warn/Wstrict-aliasing-2.C
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/warn/Wstrict-aliasing-3.C
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/warn/Wstrict-aliasing-4.C
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/warn/Wstrict-aliasing-5.C
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/warn/Wstrict-aliasing-6.C
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/warn/Wstrict-aliasing-7.C
branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/alias-9.c
Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/c-common.c
branches/gcc-4_1-branch/gcc/c-common.h
branches/gcc-4_1-branch/gcc/c-typeck.c
branches/gcc-4_1-branch/gcc/cp/ChangeLog
branches/gcc-4_1-branch/gcc/cp/typeck.c
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog
branches/gcc-4_1-branch/libstdc++-v3/ChangeLog
branches/gcc-4_1-branch/libstdc++-v3/include/bits/basic_string.h


-- 


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

[Bug libstdc++/24975] Aliasing problems inside libstdc++

[rguenth at gcc dot gnu dot org]

--- Comment #23 from rguenth at gcc dot gnu dot org  2005-12-08 11:24 
---
Subject: Bug 24975

Author: rguenth
Date: Thu Dec  8 11:24:07 2005
New Revision: 108226

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108226
Log:
2005-12-08  Richard Guenther  <[EMAIL PROTECTED]>

Backport from mainline
2005-11-28  Richard Guenther  <[EMAIL PROTECTED]>

* c-common.c (strict_aliasing_warning): Handle all
component-ref like accesses.

* gcc.dg/alias-9.c: New testcase.
* g++.dg/warn/Wstrict-aliasing-7.C: Likewise.

2005-11-24  Richard Guenther  <[EMAIL PROTECTED]>
Dirk Mueller <[EMAIL PROTECTED]>

PR c++/14024
* c-common.h (strict_aliasing_warning): Declare.
* c-common.c (strict_aliasing_warning): New function,
split out from ...
* c-typeck.c (build_c_cast): ... here.

* typeck.c (build_reinterpret_cast_1): Use
strict_aliasing_warning.

* g++.dg/warn/Wstrict-aliasing-1.C: New testcase.
* g++.dg/warn/Wstrict-aliasing-2.C: Likewise.
* g++.dg/warn/Wstrict-aliasing-3.C: Likewise.
* g++.dg/warn/Wstrict-aliasing-4.C: Likewise.
* g++.dg/warn/Wstrict-aliasing-5.C: Likewise.
* g++.dg/warn/Wstrict-aliasing-6.C: Likewise.

2005-11-23  Paolo Carlini  <[EMAIL PROTECTED]>

PR libstdc++/24975 (basic_string)
* include/bits/basic_string.h (_Rep::_S_empty_rep): Avoid
strict-aliasing warnings.

Added:
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/warn/Wstrict-aliasing-1.C
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/warn/Wstrict-aliasing-2.C
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/warn/Wstrict-aliasing-3.C
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/warn/Wstrict-aliasing-4.C
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/warn/Wstrict-aliasing-5.C
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/warn/Wstrict-aliasing-6.C
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/warn/Wstrict-aliasing-7.C
branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/alias-9.c
Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/c-common.c
branches/gcc-4_1-branch/gcc/c-common.h
branches/gcc-4_1-branch/gcc/c-typeck.c
branches/gcc-4_1-branch/gcc/cp/ChangeLog
branches/gcc-4_1-branch/gcc/cp/typeck.c
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog
branches/gcc-4_1-branch/libstdc++-v3/ChangeLog
branches/gcc-4_1-branch/libstdc++-v3/include/bits/basic_string.h


-- 


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

[Bug fortran/25307] New: internal read with end=label aborts

[jpr at csc dot fi]

Hi!

The following program 

program test
   character(len=10) :: str
   str = '123'
   read( str, *, end=10 ) i,x
10 continue
   print*,i
end program test

aborts at runtime with somewhat unexpected  message 

gfortran -v -o file file.f90; ./file
Driving: gfortran -v -o file file.f90 -lgfortranbegin -lgfortran -lm
-shared-libgcc
Using built-in specs.
Target: i386-linux
Configured with: ../gcc/configure --prefix=/tmp/gfortran-20051205/irun
--enable-languages=c,fortran --host=i386-linux
Thread model: posix
gcc version 4.2.0 20051205 (experimental)
 /home/wrk/jpr/irun/bin/../libexec/gcc/i386-linux/4.2.0/f951 file.f90 -quiet
-dumpbase file.f90 -auxbase file -version -o /tmp/ccuEHGgN.s
GNU F95 version 4.2.0 20051205 (experimental) (i386-linux)
compiled by GNU C version 4.0.2 (Debian 4.0.2-2).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
 as -V -Qy -o /tmp/ccqaQsjs.o /tmp/ccuEHGgN.s
GNU assembler version 2.13.90.0.18 (i386-redhat-linux) using BFD version
2.13.90.0.18 20030206
 /home/wrk/jpr/irun/bin/../libexec/gcc/i386-linux/4.2.0/collect2 --eh-frame-hdr
-m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o file /usr/lib/crt1.o
/usr/lib/crti.o /home/wrk/jpr/irun/bin/../lib/gcc/i386-linux/4.2.0/crtbegin.o
-L/home/wrk/jpr/irun/bin/../lib/gcc/i386-linux/4.2.0
-L/home/wrk/jpr/irun/bin/../lib/gcc
-L/home/wrk/jpr/irun/bin/../lib/gcc/i386-linux/4.2.0/../../.. /tmp/ccqaQsjs.o
-lgfortranbegin -lgfortran -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/home/wrk/jpr/irun/bin/../lib/gcc/i386-linux/4.2.0/crtend.o /usr/lib/crtn.o
At line 4 of file file.f90
Fortran runtime error: Success

ifort, g95, sun f90, pgf90, pathf90, xlf90 all treat the end specfier
as i would expect...

Juha


-- 
   Summary: internal read with end=label aborts
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jpr at csc dot fi


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

[Bug middle-end/25248] [4.1/4.2 Regression] 2.6.15-rc4 arch/powerpc/mm/hash_utils_64.c miscompiled

[rakdver at gcc dot gnu dot org]

--- Comment #24 from rakdver at gcc dot gnu dot org  2005-12-08 09:34 
---
Subject: Bug 25248

Author: rakdver
Date: Thu Dec  8 09:34:26 2005
New Revision: 108225

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108225
Log:
PR tree-optimization/25248
* tree-scalar-evolution.c (follow_ssa_edge_in_rhs): Do not use
evolution_of_loop from the failed attempt.  Remove handling
of MULT_EXPR.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-scalar-evolution.c


-- 


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