[Bug tree-optimization/19828] [4.0 Regression] LIM is pulling out a pure function even though there is something which can modify global memory

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-02-19 
09:26 ---
Subject: Bug 19828

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-02-19 09:26:09

Modified files:
gcc: ChangeLog tree-ssa-loop-im.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.c-torture/execute: 20050218-1.c 
gcc/testsuite/gcc.dg/tree-ssa: loop-7.c 

Log message:
PR tree-optimization/19828
* tree-ssa-loop-im.c: Add a TODO comment.
(movement_possibility): Return MOVE_PRESERVE_EXECUTION for calls
without side-effects.

* gcc.dg/tree-ssa/loop-7.c: New test.
* gcc.c-torture/execute/20050218-1.c: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7535&r2=2.7536
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop-im.c.diff?cvsroot=gcc&r1=2.27&r2=2.28
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5052&r2=1.5053
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/20050218-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/loop-7.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug tree-optimization/19828] [4.0 Regression] LIM is pulling out a pure function even though there is something which can modify global memory

[jakub at gcc dot gnu dot org]

--- Additional Comments From jakub at gcc dot gnu dot org  2005-02-19 09:33 
---
Fixed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug c++/20073] New: [4.0 regression] ICE initializing const array

[reichelt at gcc dot gnu dot org]

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

==
template struct A
{
A();
};

const A<0> x[] = { A<0>() };
==

bug.cc:7: internal compiler error: in set_mem_attributes_minus_bitpos, at
emit-rtl.c:1539
Please submit a full bug report, [etc.]

This is a relitively new regression (the compiler from 2005-02-16works fine).

-- 
   Summary: [4.0 regression] ICE initializing const array
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, monitored
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug libfortran/20074] New: reshape of pointer array segfaults at runtime

[Thomas dot Koenig at online dot de]

>From a posting to comp.lang.fortran.

$ cat tryresh.f90
! From: "Alfredo Buttari" <[EMAIL PROTECTED]>
! Newsgroups: comp.lang.fortran
! Subject: reshape problem
! Date: 18 Feb 2005 09:54:35 -0800

program tryreshape

  integer,allocatable :: vect1(:),resh1(:,:)
  integer,pointer :: vect(:),resh(:,:)
  integer :: vect2(2*4), resh2(2,4)
  integer :: r, s(2)

  r=2;  nb=4

  s(:)=(/r,nb/)

  allocate(vect(nb*r),vect1(nb*r))
  allocate(resh(r,nb),resh1(r,nb))

  vect =1
  vect1=1
  vect2=1

  write(*,'("Reshaping to  ",1(i1.1,"x"),i2.2)')s

! THIS WORKS
  resh2 = reshape(vect2,s)
  write(*,'("resh2: ",1(i3,2x))')resh2(1,1)

! THIS WORKS
  resh1 = reshape(vect1,s)
  write(*,'("resh1: ",1(i3,2x))')resh1(1,1)

! THIS DOESN'T
  resh = reshape(vect,s)
  write(*,'("resh : ",1(i3,2x))')resh(1,1)

end program tryreshape
$ gfortran -g tryresh.f90
$ ./a.out
Reshaping to  2x04
resh2:   1
resh1:   1
Segmentation fault
$ gdb ./a.out
GNU gdb 6.3-debian
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-linux"...Using host libthread_db library
"/lib/tls/libthread_db.so.1".

(gdb) r
Starting program: /home/ig25/Krempel/a.out
Reshaping to  2x04
resh2:   1
resh1:   1

Program received signal SIGSEGV, Segmentation fault.
0x40127cef in memcpy () from /lib/tls/libc.so.6
(gdb) bt
#0  0x40127cef in memcpy () from /lib/tls/libc.so.6
#1  0x40056f08 in *_gfortrani_reshape_packed (ret=0x0, rsize=32,
source=0x20 , ssize=32, pad=0x0, psize=4)
at ../../../gcc/libgfortran/intrinsics/reshape_packed.c:45
#2  0x40044b8b in *_gfortran_reshape_4 (ret=0xb4c4, source=Variable "source"
is not available.
)
at ../../../gcc/libgfortran/generated/reshape_i4.c:160
#3  0x08048d6f in MAIN__ () at tryresh.f90:35
#4  0x08048f43 in main (argc=32, argv=0x20)
at ../../../gcc/libgfortran/fmain.c:18
(gdb) q
The program is running.  Exit anyway? (y or n) y
$ gfortran -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/ig25 --enable-languages=c,f95
Thread model: posix
gcc version 4.0.0 20050219 (experimental)

-- 
   Summary: reshape of pointer array segfaults at runtime
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug ada/20075] New: Bug in GNAT.Expect.Non_Blocking_Spawn

[sbellon at sbellon dot de]

GNAT.Expect.Non_Blocking_Spawn puts Command_With_Path into argv[0] when calling
__gnat_expect_portable_execvp (via Set_Up_Child_Communications). This leads to
problems on Windows when the path to command contains spaces as the spawned
process only returns the path up to the first space when questioning argv[0]. A
fix is to only put just Command (without the complete path) into argv[0]. The
spawn versions in GNAT.OS_Lib do it that way, so GNAT.Expect.Non_Blocking_Spawn
is inconsistent anyway.

The fix is simple and needs only to change two lines (patch for GCC 3.4.4 but is
similar for 3.15p as well):

--- 3.4.4/g-expect.adb  2005-02-19 12:28:29.350605929 +0100
+++ patched/g-expect.adb2005-02-19 12:29:16.332632637 +0100
@@ -873,8 +873,8 @@
   if Descriptor.Pid = Null_Pid then
  --  Prepare an array of arguments to pass to C
 
- Arg := new String (1 .. Command_With_Path'Length + 1);
- Arg (1 .. Command_With_Path'Length) := Command_With_Path.all;
+ Arg := new String (1 .. Command'Length + 1);
+ Arg (1 .. Command'Length) := Command;
  Arg (Arg'Last):= ASCII.NUL;
  Arg_List (1)  := Arg;
 

A minimal test case that shows the problem needs two main programs, one
(launcher.adb) which launches the other (show_params.adb):

$ cat show_params.adb
with Ada.Command_Line;
with Ada.Text_IO;
procedure Show_Params is
begin
   Ada.Text_IO.Put_Line (Ada.Command_Line.Command_Name);
end Show_Params;

$ cat show launcher.adb
with Ada.Text_IO;
with GNAT.OS_Lib;
with GNAT.Expect;
procedure Launcher is
   Args : GNAT.OS_Lib.Argument_List (1 .. 0);
   PD   : GNAT.Expect.Process_Descriptor;
   Succ : Boolean;
   Res  : GNAT.Expect.Expect_Match;
   use type GNAT.Expect.Expect_Match;
begin
   Ada.Text_IO.Put_Line ("via GNAT.OS_Lib.Spawn:");
   GNAT.OS_Lib.Spawn ("show_params", Args, Succ);
   Ada.Text_IO.Put_Line ("via GNAT.Expect.Non_Blocking_Spawn:");
   GNAT.Expect.Non_Blocking_Spawn (PD, "show_params", Args);
   begin
  loop
 GNAT.Expect.Expect (PD, Res, ".");
 if Res >= 0 then
Ada.Text_IO.Put (GNAT.Expect.Expect_Out (PD));
 end if;
   end loop;
   exception
  when GNAT.Expect.Process_Died =>
 GNAT.Expect.Close (PD);
   end;
end Launcher;

$ gnatmake show_params.adb 
gcc-3.4 -c show_params.adb
gnatbind -x show_params.ali
gnatlink show_params.ali
$ gnatmake launcher.adb 
gcc-3.4 -c launcher.adb
gnatbind -x launcher.ali
gnatlink launcher.ali

Put show_params somewhere in your $PATH and start launcher. You'll see that via
GNAT.OS_Lib, only the basename of the command is put into argv[0] and via
GNAT.Expect, the whole path is put there. Now, if you put show_params into a
path with some spaces, you'll see the problem:

$ PATH=`pwd` launcher
via GNAT.OS_Lib.Spawn:
show_params
via GNAT.Expect.Non_Blocking_Spawn:
/home/sbellon/tmp/show params/show_params

It works under GNU/Linux, but it fails on Windows. If you put show_params.exe
into a path of "C:\Program Files\show_params.exe", put that into your %PATH% and
start launcher.exe, then you'll see that only "C:\Program" is returned as
Ada.Command_Line.Command_Name.

This is true for all versions of GNAT we have looked at (GNAT 3.15p, GCC 3.3.x
and GCC 3.4.x). As the fix is very simple, I hope it can be applied to the
current version before the release of GCC 4.0 and perhaps even backported to
older versions.

According to your instructions of how to submit a bug report, I'll include all
the further details but I don't see that they're relevant here as it's a simple
bug in the GNAT lib and is present across all versions of GNAT and all
target/host configurations (applies to MinGW as well).

$ gcc-3.4 -v
Reading specs from /usr/lib/gcc/i486-linux/3.4.4/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr
--libexecdir=/usr/lib --with-gxx-include-dir=/usr/include/c++/3.4
--enable-shared --with-system-zlib --enable-nls --without-included-gettext
--program-suffix=-3.4 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt
--enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm
--enable-java-awt=gtk --disable-werror i486-linux
Thread model: posix
gcc version 3.4.4 20050203 (prerelease) (Debian 3.4.3-9)

-- 
   Summary: Bug in GNAT.Expect.Non_Blocking_Spawn
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sbellon at sbellon dot de
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug other/19525] [4.0 Regression] In-build-directory multilib testing broken

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-02-19 
11:44 ---
Subject: Bug 19525

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-02-19 11:44:11

Modified files:
gcc: ChangeLog gcc.c mklibgcc.in 
gcc/doc: invoke.texi 
gcc/config : t-libunwind-elf t-slibgcc-darwin 
 t-slibgcc-elf-ver t-slibgcc-sld 
gcc/config/i386: t-nwld 
gcc/config/ia64: t-hpux 
gcc/config/mips: t-slibgcc-irix 
gcc/config/pa  : t-hpux-shlib 
gcc/config/rs6000: t-aix43 t-aix52 
gcc/config/sh  : t-linux 

Log message:
PR other/19525
* doc/invoke.texi: Remove documentation of %M spec.
* gcc.c: Likewise.
(init_spec): Remove %M suffix from -lgcc_s.
(do_spec_1): Remove 'M' case.
* mklibgcc.in: Remove SHLIB_MULTILIB handling.  Expect SHLIB_LINK
to put shared libraries in the multilib directory.  Remove the
shlib_so_soname substitution variable.  Don't add a multilib encoding
to shlib_base_name.  Set shlib_slibdir_qual to the full pathname
reported by -print-multi-os-directory.  Pass @multilib_dir@ to
SHLIB_INSTALL as well as SHLIB_LINK.
* config/t-slibgcc-elf-ver (SHLIB_SONAME): Use @[EMAIL PROTECTED]
(SHLIB_NAME): Delete.
(SHLIB_DIR): New macro.
(SHLIB_LINK): Put $(SHLIB_SONAME) and $(SHLIB_SOLINK) in $(SHLIB_DIR).
(SHLIB_INSTALL): Adjust accordingly.
* config/t-slibgcc-darwin: As for t-slibgcc-elf-ver.
* config/t-slibgcc-sld: Likewise.
* config/t-libunwind-elf (SHLIBUNWIND_NAME): Delete.
(SHLIBUNWIND_SONAME): Use @[EMAIL PROTECTED]
(SHLIBUNWIND_LINK): Put $(SHLIBUNWIND_SONAME) and $(SHLIB_SOLINK)
in $(SHLIB_DIR).
(SHLIBUNWIND_INSTALL): Adjust accordingly.
* config/i386/t-nwld (SHLIB_SONAME): Delete.
(SHLIB_LINK, SHLIB_INSTALL): Use SHLIB_NAME instead of SHLIB_SONAME.
Use @shlib_base_name@ instead of @[EMAIL PROTECTED]
* config/ia64/t-hpux (SHLIB_LINK): Put @[EMAIL PROTECTED]
and @[EMAIL PROTECTED] in @[EMAIL PROTECTED]
(SHLIB_INSTALL): Adjust accordingly.  Add @shlib_slibdir_qual@
to the install path.
* config/mips/t-slibgcc-irix: As for t-slibgcc-elf-ver.
(SHLIB_LINK): Remove previous workaround.
* config/pa/t-hpux-shlib (SHLIB_DIR, SHLIB_SLIBDIR_QUAL): New macros.
(SHLIB_LINK): Put $(SHLIB_SONAME) and $(SHLIB_NAME) in $(SHLIB_DIR).
(SHLIB_INSTALL): Adjust accordingly.  Add $(SHLIB_SLIBDIR_QUAL) to
the install path.
* config/rs6000/t-aix43 (SHLIB_LINK): Put @[EMAIL PROTECTED] in
@[EMAIL PROTECTED]  Use @multilib_dir@ to check for threading libraries.
(SHLIB_INSTALL): Adjust accordingly.
(SHLIB_LIBS): Use @multilib_dir@ to check for threading libraries.
* config/rs6000/t-aix52: As for config/rs6000/t-aix43.
* config/sh/t-linux (SHLIB_LINK, SHLIB_INSTALL): As for
config/t-slibgcc-elf-ver.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7536&r2=2.7537
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gcc.c.diff?cvsroot=gcc&r1=1.446&r2=1.447
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/mklibgcc.in.diff?cvsroot=gcc&r1=1.83&r2=1.84
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/invoke.texi.diff?cvsroot=gcc&r1=1.580&r2=1.581
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/t-libunwind-elf.diff?cvsroot=gcc&r1=1.4&r2=1.5
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/t-slibgcc-darwin.diff?cvsroot=gcc&r1=1.8&r2=1.9
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/t-slibgcc-elf-ver.diff?cvsroot=gcc&r1=1.10&r2=1.11
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/t-slibgcc-sld.diff?cvsroot=gcc&r1=1.10&r2=1.11
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/t-nwld.diff?cvsroot=gcc&r1=1.5&r2=1.6
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/t-hpux.diff?cvsroot=gcc&r1=1.9&r2=1.10
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/mips/t-slibgcc-irix.diff?cvsroot=gcc&r1=1.5&r2=1.6
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/pa/t-hpux-shlib.diff?cvsroot=gcc&r1=1.4&r2=1.5
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/t-aix43.diff?cvsroot=gcc&r1=1.24&r2=1.25
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/t-aix52.diff?cvsroot=gcc&r1=1.7&r2=1.8
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/sh/t-linux.diff?cvsroot=gcc&r1=1.16&r2=1.17



-- 


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

[Bug other/19525] [4.0 Regression] In-build-directory multilib testing broken

[rsandifo at gcc dot gnu dot org]

--- Additional Comments From rsandifo at gcc dot gnu dot org  2005-02-19 
11:47 ---
Patch applied.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/20024] [4.0 regression] miscompilation of division support functions

[jakub at gcc dot gnu dot org]

--- Additional Comments From jakub at gcc dot gnu dot org  2005-02-19 11:53 
---
Can't this be closed now that
2005-02-18  Jason Merrill  <[EMAIL PROTECTED]>

* gimplify.c (gimplify_modify_expr_rhs) [CALL_EXPR]: Revert again.
is in?

-- 


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

[Bug middle-end/20027] [4.0 Regression] gcc.c-torture/execute/20050121.c execution fails

[jakub at gcc dot gnu dot org]

--- Additional Comments From jakub at gcc dot gnu dot org  2005-02-19 11:53 
---
Can't this be closed now that
2005-02-18  Jason Merrill  <[EMAIL PROTECTED]>

* gimplify.c (gimplify_modify_expr_rhs) [CALL_EXPR]: Revert again.
is in?

-- 


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

[Bug c/20076] New: __builtin_return(__builtin_apply()) inlined incorrectly

[gcczilla at achurch dot org]

GCC 3.4.3 (i686-pc-linux-gnu) generates incorrect code when a function
containing __builtin_return(__builtin_apply(...)) is inlined, whether by the
"inline" keyword or with -finline-functions.  For example, take this simple 
program:

int bar(int hoge) { return hoge; }
int foo(int xyzzy) {
__builtin_return(__builtin_apply(bar,__builtin_apply_args(),64)); }
int main(int ac, char **av) { return foo(9)==9 && foo(42)==42 ? 0 : 1; }

This should generate a main() with two calls to foo(), but with
-finline-functions, main() instead consists of a __builtin_apply() call to bar()
directly, using the arguments to main() rather than the argument passed to
foo().  See attached assembly listings.

$ gcc -vReading specs from /pkg/gcc/lib/gcc/i686-pc-linux-gnu/3.4.3/specs
Configured with: /tmp/packager17310.149/gcc-3.4.3/configure --prefix=/pkg/gcc
--enable-languages=c,c++ --disable-shared --disable-nls
Thread model: posix
gcc version 3.4.3

-- 
   Summary: __builtin_return(__builtin_apply()) inlined incorrectly
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcczilla at achurch dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug c/20076] __builtin_return(__builtin_apply()) inlined incorrectly

[gcczilla at achurch dot org]

--- Additional Comments From gcczilla at achurch dot org  2005-02-19 12:57 
---
Created an attachment (id=8231)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8231&action=view)
Test source file (from description)


-- 


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

[Bug c/20076] __builtin_return(__builtin_apply()) inlined incorrectly

[gcczilla at achurch dot org]

--- Additional Comments From gcczilla at achurch dot org  2005-02-19 12:58 
---
Created an attachment (id=8232)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8232&action=view)
gcc test.c -S -O2


-- 


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

[Bug c/20076] __builtin_return(__builtin_apply()) inlined incorrectly

[gcczilla at achurch dot org]

--- Additional Comments From gcczilla at achurch dot org  2005-02-19 12:59 
---
Created an attachment (id=8233)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8233&action=view)
gcc test.c -S -O2 -finline-functions (bad)


-- 


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

[Bug preprocessor/20077] New: GCC accepts macro definitions that fail a constraint

[neil at gcc dot gnu dot org]

#define a a ## ##
#define a() a ## ##

-- 
   Summary: GCC accepts macro definitions that fail a constraint
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/20073] [4.0 regression] ICE initializing const array

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-19 
13:07 ---
Caused By:
2005-02-18  Jakub Jelinek  <[EMAIL PROTECTED]>

PR c++/19813
* decl.c (start_decl_1): Clear TREE_READONLY flag if
its type has TYPE_NEEDS_CONSTRUCTING.
(complete_vars): Likewise.
2005-02-18  Jakub Jelinek  <[EMAIL PROTECTED]>

PR c++/19813
* emit-rtl.c (set_mem_attributes_minus_bitpos): Add assertion
that ref to be marked MEM_READONLY_P doesn't have base that needs
constructing.


-- 
   What|Removed |Added

 CC||jakub at redhat dot com
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-02-19 13:07:41
   date||
   Target Milestone|--- |4.0.0


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

[Bug bootstrap/20072] make install doesn't create /usr/local/info/dir if .../dir not already present.

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|preprocessor|bootstrap


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

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

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-19 
13:22 ---
Confirmed.

-- 
   What|Removed |Added

   Severity|critical|normal
 Status|UNCONFIRMED |NEW
  Component|c   |tree-optimization
 Ever Confirmed||1
   Keywords||wrong-code
  Known to fail||3.3.3 3.4.0 4.0.0
  Known to work||3.0.4 2.95.3
   Last reconfirmed|-00-00 00:00:00 |2005-02-19 13:22:27
   date||
Summary|__builtin_return(__builtin_a|[3.3/3.4/4.0 Regression]
   |pply()) inlined incorrectly |__builtin_return(__builtin_a
   ||pply()) inlined incorrectly
   Target Milestone|--- |3.4.4


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

[Bug middle-end/20024] [4.0 regression] miscompilation of division support functions

[hp at gcc dot gnu dot org]

--- Additional Comments From hp at gcc dot gnu dot org  2005-02-19 14:30 
---
Jason's patch has been reverted.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug preprocessor/20078] New: Gcc doesn't complain about non-benign macro definitions

[neil at gcc dot gnu dot org]

According to the standard

#define str(x) #x
#define str(x) %:x

violates a constraint, but GCC accepts it.  Amusingly, Comeau shares the same 
bug.

A similar bug exists with the paste operator.

-- 
   Summary: Gcc doesn't complain about non-benign macro definitions
   Product: gcc
   Version: 3.4.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug middle-end/20024] [4.0 regression] miscompilation of division support functions

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.0.0


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

[Bug ada/20079] New: PowerPC Ada compiler blows when building the Ada runtime

[astrominger at yahoo dot com]

When trying to build a powerpc-rtems compiler running under cygwin using the 
20050213 snapshot, the compiler blows during the RTS build phase, with the 
following message:

../../xgcc -B../../ -c -g -O2  -W -Wall -gnatpg  a-direct.adb -o a-direct.o
+===GNAT BUG DETECTED==+
| 4.0.0 20050213 (experimental) (powerpc-unknown-rtems) GCC error: |
| in gnat_type_for_mode, at ada/utils.c:1838   |
| Error detected at a-direct.adb:965:1 |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Include the entire contents of this bug box in the report.   |
| Include the exact gcc or gnatmake command that you entered.  |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files).   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.

raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:387
make[3]: *** [a-direct.o] Error 1

The host compiler used to build the powerpc-unknown-rtems compiler that failed 
was built from the same snapshot (i.e. 20050213 of gcc 4.0)

building host is running WindowsXP, sp2, and cygwin version 1005.12.0.0

full log of the library build phase:

/bin/sh ../gcc-4.0-20050213/mkinstalldirs powerpc-rtems/libada ; \
rm -f powerpc-rtems/libada/Makefile || : ; \
cp multilib.out powerpc-rtems/libada/multilib.out
mkdir -p -- powerpc-rtems/libada
Configuring in powerpc-rtems/libada
configure: creating cache ./config.cache
checking for a BSD-compatible install... /usr/bin/install -c
checking build system type... i686-pc-cygwin
checking host system type... powerpc-unknown-rtems
checking target system type... powerpc-unknown-rtems
checking whether ln -s works... yes
updating cache ./config.cache
configure: creating ./config.status
config.status: creating Makefile
make[1]: Entering directory `/cygdrive/d/c-dev/tools/b-gcc-4.0_20050213/powerpc-
rtems/libada'
make -C ../../gcc/ada "MAKEOVERRIDES=" "LDFLAGS=" "LN_S=ln -
s" "SHELL=/bin/sh" "exeext=.exe" "objext=.o" "prefix=/usr/lo
cal" "STAGE_PREFIX=" "CC=gcc" "CFLAGS=-O2 -g -O2  -W -Wall -Wwrite-strings -
Wstrict-prototypes -Wmissing-prototypes -fno
-common" \
  GNATLIBFLAGS="-W -Wall -gnatpg" \
  GNATLIBCFLAGS="-g -O2" \
  TARGET_LIBGCC2_CFLAGS="" \
  THREAD_KIND="native" \
  TRACE="no" \
  gnatlib
make[2]: Entering directory `/cygdrive/d/c-dev/tools/b-gcc-4.0_20050213/gcc/ada'
rm -f rts/s-*.ali
rm -f rts/s-*.o
rm -f rts/a-*.ali
rm -f rts/a-*.o
rm -f rts/*.ali
rm -f rts/*.o
rm -f rts/*.a
rm -f rts/*.so
touch ../stamp-gnatlib2
rm -f ../stamp-gnatlib
rm -rf rts
mkdir -p rts
chmod u+w rts
ln -s /cygdrive/d/c-dev/tools/gcc-4.0-20050213/gcc/ada/ada.ads rts ;  ln -
s /cygdrive/d/c-dev/tools/gcc-4.0-20050213/gcc
/ada/calendar.ads rts ;  ln -s /cygdrive/d/c-dev/tools/gcc-4.0-
20050213/gcc/ada/directio.ads rts ;  ln -s /cygdrive/d/c-
dev/tools/gcc-4.0-20050213/gcc/ada/gnat.ads rts ;  ln -s /cygdrive/d/c-
dev/tools/gcc-4.0-20050213/gcc/ada/interfac.ads r
ts ;  ln -s /cygdrive/d/c-dev/tools/gcc-4.0-20050213/gcc/ada/ioexcept.ads 
rts ;  ln -s /cygdrive/d/c-dev/tools/gcc-4.0-2
0050213/gcc/ada/machcode.ads rts ;  ln -s /cygdrive/d/c-dev/tools/gcc-4.0-
20050213/gcc/ada/text_io.ads rts ;  ln -s /cyg
drive/d/c-dev/tools/gcc-4.0-20050213/gcc/ada/unchconv.ads rts ;  ln -
s /cygdrive/d/c-dev/tools/gcc-4.0-20050213/gcc/ada/
unchdeal.ads rts ;  ln -s /cygdrive/d/c-dev/tools/gcc-4.0-
20050213/gcc/ada/sequenio.ads rts ;  ln -s /cygdrive/d/c-dev/t
ools/gcc-4.0-20050213/gcc/ada/system.ads rts ;  ln -s /cygdrive/d/c-
dev/tools/gcc-4.0-20050213/gcc/ada/Makefile.adalib r
ts ;  ln -s /cygdrive/d/c-dev/tools/gcc-4.0-20050213/gcc/ada/memtrack.adb 
rts ;  ln -s /cygdrive/d/c-dev/tools/gcc-4.0-2
0050213/gcc/ada/a-*.adb rts ;  ln -s /cygdrive/d/c-dev/tools/gcc-4.0-
20050213/gcc/ada/a-*.ads rts ;  ln -s /cygdrive/d/c
-dev/tools/gcc-4.0-20050213/gcc/ada/g-*.ad? rts ;  ln -s /cygdrive/d/c-
dev/tools/gcc-4.0-20050213/gcc/ada/i-*.ad? rts ;
 ln -s /cygdrive/d/c-dev/tools/gcc-4.0-20050213/gcc/ada/s-[a-o]*.adb rts ;  ln -
s /cygdrive/d/c-dev/tools/gcc-4.0-200502
13/gcc/ada/s-[p-z]*.adb rts ;  ln -s /cygdrive/d/c-dev/tools/gcc-4.0-
20050213/gcc/ada/s-[a-o]*.ads rts ;  ln -s /cygdriv
e/d/c-dev/tools/gcc-4.0-20050213/gcc/ada/s-[p-z]*.ads rts ;  ln -
s /cygdrive/d/c-dev/tools/gcc-4.0-20050213/gcc/ada/ada.
h rts ;  ln -s /cygdrive/d/c-dev/tools/gcc-4.0-20050213/gcc/ada/adaint.c rts ;  
ln -s /cygdrive/d/c-dev/tools/gcc-4.0-20
050213/gcc/ada/adaint.h rts ;  ln -s /cygdrive/d/c-dev/tools/gcc-4.0-
20050213/gcc/ada/argv.c rts ;  ln -s /cygdrive/d/c-
dev/tools/gcc-4.0-20050213/gcc/ada/cio.c rts ;  ln -s /cygdrive/d/c-
dev/tools/gcc-4.0

[Bug ada/20080] New: PowerPC Ada compiler blows when building the Ada runtime

[astrominger at yahoo dot com]

When trying to build a powerpc-rtems compiler running under cygwin using the 
20050213 snapshot, the compiler blows during the RTS build phase, with the 
following message:

../../xgcc -B../../ -c -g -O2  -W -Wall -gnatpg  a-direct.adb -o a-direct.o
+===GNAT BUG DETECTED==+
| 4.0.0 20050213 (experimental) (powerpc-unknown-rtems) GCC error: |
| in gnat_type_for_mode, at ada/utils.c:1838   |
| Error detected at a-direct.adb:965:1 |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Include the entire contents of this bug box in the report.   |
| Include the exact gcc or gnatmake command that you entered.  |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files).   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.

raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:387
make[3]: *** [a-direct.o] Error 1

The host compiler used to build the powerpc-unknown-rtems compiler that failed 
was built from the same snapshot (i.e. 20050213 of gcc 4.0)

building host is running WindowsXP, sp2, and cygwin version 1005.12.0.0

full log of the library build phase:

/bin/sh ../gcc-4.0-20050213/mkinstalldirs powerpc-rtems/libada ; \
rm -f powerpc-rtems/libada/Makefile || : ; \
cp multilib.out powerpc-rtems/libada/multilib.out
mkdir -p -- powerpc-rtems/libada
Configuring in powerpc-rtems/libada
configure: creating cache ./config.cache
checking for a BSD-compatible install... /usr/bin/install -c
checking build system type... i686-pc-cygwin
checking host system type... powerpc-unknown-rtems
checking target system type... powerpc-unknown-rtems
checking whether ln -s works... yes
updating cache ./config.cache
configure: creating ./config.status
config.status: creating Makefile
make[1]: Entering directory `/cygdrive/d/c-dev/tools/b-gcc-4.0_20050213/powerpc-
rtems/libada'
make -C ../../gcc/ada "MAKEOVERRIDES=" "LDFLAGS=" "LN_S=ln -
s" "SHELL=/bin/sh" "exeext=.exe" "objext=.o" "prefix=/usr/lo
cal" "STAGE_PREFIX=" "CC=gcc" "CFLAGS=-O2 -g -O2  -W -Wall -Wwrite-strings -
Wstrict-prototypes -Wmissing-prototypes -fno
-common" \
  GNATLIBFLAGS="-W -Wall -gnatpg" \
  GNATLIBCFLAGS="-g -O2" \
  TARGET_LIBGCC2_CFLAGS="" \
  THREAD_KIND="native" \
  TRACE="no" \
  gnatlib
make[2]: Entering directory `/cygdrive/d/c-dev/tools/b-gcc-4.0_20050213/gcc/ada'
rm -f rts/s-*.ali
rm -f rts/s-*.o
rm -f rts/a-*.ali
rm -f rts/a-*.o
rm -f rts/*.ali
rm -f rts/*.o
rm -f rts/*.a
rm -f rts/*.so
touch ../stamp-gnatlib2
rm -f ../stamp-gnatlib
rm -rf rts
mkdir -p rts
chmod u+w rts
ln -s /cygdrive/d/c-dev/tools/gcc-4.0-20050213/gcc/ada/ada.ads rts ;  ln -
s /cygdrive/d/c-dev/tools/gcc-4.0-20050213/gcc
/ada/calendar.ads rts ;  ln -s /cygdrive/d/c-dev/tools/gcc-4.0-
20050213/gcc/ada/directio.ads rts ;  ln -s /cygdrive/d/c-
dev/tools/gcc-4.0-20050213/gcc/ada/gnat.ads rts ;  ln -s /cygdrive/d/c-
dev/tools/gcc-4.0-20050213/gcc/ada/interfac.ads r
ts ;  ln -s /cygdrive/d/c-dev/tools/gcc-4.0-20050213/gcc/ada/ioexcept.ads 
rts ;  ln -s /cygdrive/d/c-dev/tools/gcc-4.0-2
0050213/gcc/ada/machcode.ads rts ;  ln -s /cygdrive/d/c-dev/tools/gcc-4.0-
20050213/gcc/ada/text_io.ads rts ;  ln -s /cyg
drive/d/c-dev/tools/gcc-4.0-20050213/gcc/ada/unchconv.ads rts ;  ln -
s /cygdrive/d/c-dev/tools/gcc-4.0-20050213/gcc/ada/
unchdeal.ads rts ;  ln -s /cygdrive/d/c-dev/tools/gcc-4.0-
20050213/gcc/ada/sequenio.ads rts ;  ln -s /cygdrive/d/c-dev/t
ools/gcc-4.0-20050213/gcc/ada/system.ads rts ;  ln -s /cygdrive/d/c-
dev/tools/gcc-4.0-20050213/gcc/ada/Makefile.adalib r
ts ;  ln -s /cygdrive/d/c-dev/tools/gcc-4.0-20050213/gcc/ada/memtrack.adb 
rts ;  ln -s /cygdrive/d/c-dev/tools/gcc-4.0-2
0050213/gcc/ada/a-*.adb rts ;  ln -s /cygdrive/d/c-dev/tools/gcc-4.0-
20050213/gcc/ada/a-*.ads rts ;  ln -s /cygdrive/d/c
-dev/tools/gcc-4.0-20050213/gcc/ada/g-*.ad? rts ;  ln -s /cygdrive/d/c-
dev/tools/gcc-4.0-20050213/gcc/ada/i-*.ad? rts ;
 ln -s /cygdrive/d/c-dev/tools/gcc-4.0-20050213/gcc/ada/s-[a-o]*.adb rts ;  ln -
s /cygdrive/d/c-dev/tools/gcc-4.0-200502
13/gcc/ada/s-[p-z]*.adb rts ;  ln -s /cygdrive/d/c-dev/tools/gcc-4.0-
20050213/gcc/ada/s-[a-o]*.ads rts ;  ln -s /cygdriv
e/d/c-dev/tools/gcc-4.0-20050213/gcc/ada/s-[p-z]*.ads rts ;  ln -
s /cygdrive/d/c-dev/tools/gcc-4.0-20050213/gcc/ada/ada.
h rts ;  ln -s /cygdrive/d/c-dev/tools/gcc-4.0-20050213/gcc/ada/adaint.c rts ;  
ln -s /cygdrive/d/c-dev/tools/gcc-4.0-20
050213/gcc/ada/adaint.h rts ;  ln -s /cygdrive/d/c-dev/tools/gcc-4.0-
20050213/gcc/ada/argv.c rts ;  ln -s /cygdrive/d/c-
dev/tools/gcc-4.0-20050213/gcc/ada/cio.c rts ;  ln -s /cygdrive/d/c-
dev/tools/gcc-4.0

[Bug ada/20079] PowerPC Ada compiler blows when building the Ada runtime

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-19 
15:05 ---
I fixed this right after the snapshot was made, see PR 19942 which this is a 
dup of.

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug ada/19942] [4.0 Regression] Stage 2 compilation of ali.adb causes GNAT bug box

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-19 
15:05 ---
*** Bug 20079 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||astrominger at yahoo dot com


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

[Bug ada/20080] PowerPC Ada compiler blows when building the Ada runtime

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-19 
15:06 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug ada/19942] [4.0 Regression] Stage 2 compilation of ali.adb causes GNAT bug box

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-19 
15:06 ---
*** Bug 20080 has been marked as a duplicate of this bug. ***

-- 


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

[Bug c++/20081] New: gcc does not link hello.cc with -lstdc++

[mail at hanns-konrad dot de]

man gcc
 => For any given input file, the file name suffix determines what kind of
 => compilation is done: file.cc: C++ source code which must be preprocessed.
# BUT:
cat  : undefined reference to ...
 => collect2: ld returned 1 exit status

-- 
   Summary: gcc does not link hello.cc with -lstdc++
   Product: gcc
   Version: 3.3.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mail at hanns-konrad dot de
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i486-pc-linux-gnu
  GCC host triplet: i486-pc-linux-gnu
GCC target triplet: i486-pc-linux-gnu


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

[Bug c++/20081] gcc does not link hello.cc with -lstdc++

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-19 
15:22 ---
Use g++ to link.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug libstdc++/20071] [4.0 regression] newlib target testsuite regressions: libstdc++: tr1/6_containers/tuple

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-02-19 
15:34 ---
Subject: Bug 20071

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-02-19 15:33:59

Modified files:
libstdc++-v3   : ChangeLog 
libstdc++-v3/include/tr1: functional 

Log message:
PR libstdc++/20071
* include/tr1/functional (hash): Wrap in #ifdef
_GLIBCXX_USE_WCHAR_T.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&r1=1.2902&r2=1.2903
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/tr1/functional.diff?cvsroot=gcc&r1=1.2&r2=1.3



-- 


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

[Bug libstdc++/20071] [4.0 regression] newlib target testsuite regressions: libstdc++: tr1/6_containers/tuple

[hp at gcc dot gnu dot org]

--- Additional Comments From hp at gcc dot gnu dot org  2005-02-19 15:42 
---
See http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01113.html>.

-- 
   What|Removed |Added

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


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

[Bug target/20082] New: unrecognizable insn

[a dot plot at nettaxi dot com]

avr-gcc (GCC) 3.4.3
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.

Compiling: igncontrol.c
igncontrol.c: In function `__vector_3':
igncontrol.c:121: error: unrecognizable insn:
(insn 16 14 15 0 igncontrol.c:107 (set (reg:QI 46)
(mem:QI (reg/v:HI 2 r2 [ event_ptr ]) [0 S1 A8])) -1 (insn_list 9 (nil))
(nil))
igncontrol.c:121: internal compiler error: in extract_insn, at recog.c:2083
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make: *** [compile/igncontrol.o] Error 1
Process make exited with code 2

Parts of code:
...
// Globals
register char *event_ptr asm("r2");
...
SIGNAL(SIG_OUTPUT_COMPARE2)
{
// if (event_cnt == jump_point_keep)
//  event_cnt = jump_point;

// Set output signals
IGN_CONTROL = *event_ptr++ & ctrl_mask_keep;

unsigned char cmp_tmp = *event_ptr++;

// If use of separate lines like:
//
//unsigned char cmp_tmp = *event_ptr;
//event_ptr++;
//
// so everything works fine.


if (cmp_tmp)
TIM2_CMP = cmp_tmp;
else
{
STOP_TIM2();
TIMSK = tim_mask;
IGN_FEED = 1;
}
}
...


Preprocessor:
...
void __vector_3 (void) __attribute__ ((signal)); void __vector_3 (void)
{




 (*(volatile uint8_t *)((0x15) + 0x20)) = *event_ptr++ & ctrl_mask_keep;

 unsigned char cmp_tmp = *event_ptr++;





 if (cmp_tmp)
  (*(volatile uint8_t *)((0x23) + 0x20)) = cmp_tmp;
 else
 {
  (*(volatile uint8_t *)((0x25) + 0x20)) = 0x00;
  (*(volatile uint8_t *)((0x39) + 0x20)) = tim_mask;
  (*(volatile bit_field *) (((uint16_t) &((*(volatile uint8_t *)((0x18) + 0x20))
.bit2 = 1;
 }
}

-- 
   Summary: unrecognizable insn
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: a dot plot at nettaxi dot com
CC: ericw at evcohs dot com,gcc-bugs at gcc dot gnu dot org
GCC target triplet: avr


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

[Bug middle-end/20033] [4.0 Regression] Bootstrap fails on 32-bit hppa-hpux

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-19 
15:54 ---
The patch has been reverted so closing as fixed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/20027] [4.0 Regression] gcc.c-torture/execute/20050121.c execution fails

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-19 
15:54 ---
The patch was reverted so closing as fixed.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-19 
15:56 ---
Reopening as the patch had to be reverted.

-- 
   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug ada/19959] [4.0 Regression] Can't compile gnattools for the cross targets

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-19 
16:02 ---
(In reply to comment #2)
> Fails for --target=i386-elf too.

but that is more likely PR 6852.

-- 


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

[Bug libstdc++/20071] [4.0 regression] newlib target testsuite regressions: libstdc++: tr1/6_containers/tuple

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-02-19 
16:13 ---
Present on Solaris 2.5.1 and 2.6 too.


-- 
   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org


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

[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 AssignedTo|fche at redhat dot com  |unassigned at gcc dot gnu
   ||dot org
 Status|REOPENED|NEW


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

[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 CC||fche at redhat dot com
 AssignedTo|unassigned at gcc dot gnu   |jason at redhat dot com
   |dot org |
 Status|NEW |ASSIGNED


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

[Bug c++/20073] [4.0 regression] ICE initializing const array

[jakub at gcc dot gnu dot org]

--- Additional Comments From jakub at gcc dot gnu dot org  2005-02-19 16:47 
---
Testing a patch.

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-02-19 13:07:41 |2005-02-19 16:47:38
   date||


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

[Bug tree-optimization/20083] New: Missed optimization with conditional and basically ||

[pinskia at gcc dot gnu dot org]

The following three functions should result in the same assembly (the last is 
the best, branchless and 
only does one compare):
int f(int i, int j, int l)
{
  int k = 0;
  if (i)
   k = 1;
  if (j)
   k = 1; 
  if (l)
k = 1;
  return k;
}
int f1(int i, int j, int l)
{
  int k = 0;
  if (i)
   k = 1;
  else if (j)
   k = 1; 
  else if (l)
   k = 1;
  return k;
}
int f2(int i, int j, int l)
{
  return i||j||l;
}

Note I came up with this testcase after adding code like the above code to gcc 
and I was wondering how 
we optimizated it.

-- 
   Summary: Missed optimization with conditional and basically ||
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug tree-optimization/20084] New: missed optimization with conditional and loads and cross jumping

[pinskia at gcc dot gnu dot org]

Like PR 20083 but a slightly different case, in a way this is missed jump 
crossing.
The following three functions should produce the same assembly code, f2 is the 
most optimal code.
Right now on the tcb only f1 and f2 are the same.

int f(int *i, int *j, int *l)
{
  int k = 0;
  if (*i)
   k = 1;
  if (*j)
   k = 1;
  if (*l)
k = 1;
  return k;
}
int f1(int *i, int *j, int *l)
{
  int k = 0;
  if (*i)
   k = 1;
  else if (*j)
   k = 1;
  else if (*l)
   k = 1;
  return k;
}
int f2(int *i, int *j, int *l)
{
  int k = 0;
  if (*i)
   return 1;
  if (*j)
   return 1;
  return (*l)!=0;
}

-- 
   Summary: missed optimization with conditional and loads and cross
jumping
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug preprocessor/20077] [3.3/3.4/4.0 Regression] GCC accepts macro definitions that fail a constraint

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-19 
17:04 ---
Confirmed, and this is a regression from 2.95.3:
t.c:1: `##' at end of macro definition

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||accepts-invalid, diagnostic
  Known to fail||3.0.4 3.2.3 3.3.6 3.4.4
   ||4.0.0
  Known to work||2.95.3
   Last reconfirmed|-00-00 00:00:00 |2005-02-19 17:04:20
   date||
Summary|GCC accepts macro   |[3.3/3.4/4.0 Regression] GCC
   |definitions that fail a |accepts macro definitions
   |constraint  |that fail a constraint
   Target Milestone|--- |3.4.4


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

[Bug preprocessor/20078] Gcc doesn't complain about non-benign macro definitions

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-19 
17:05 ---
Confirmed, not a regression.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||accepts-invalid, diagnostic
  Known to fail||2.95.3 3.0.4 3.2.3 3.3.3
   ||3.4.0 4.0.0
   Last reconfirmed|-00-00 00:00:00 |2005-02-19 17:05:00
   date||


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

[Bug fortran/20085] New: iargc returns wrong count for number of program arguments

[dir at lanl dot gov]

Function iargc return the wrong argument count on the Macintosh. It returns 1
when it should be zero etc... -

[dir:~/tests/gfortran] dir% gfortran -o mopen mopen.f
[dir:~/tests/gfortran] dir% mopen
   1   
 
STOP 0
[dir:~/tests/gfortran] dir% mopen one
   1 one   
 
   2   
 
STOP 0
[dir:~/tests/gfortran] dir% cat mopen.f
  program mopen
  character*80 c
  integer i,iargc
  iargs=iargc()
  do 10 i=1,iargs
  call getarg(i,c)
  write(*,*)i,c
   10 continue
  stop
  end  
[dir:~/tests/gfortran] dir%

-- 
   Summary: iargc returns wrong count for number of program
arguments
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dir at lanl dot gov
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: powerpc-apple-darwin7.8.0


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

[Bug libfortran/20085] iargc returns wrong count for number of program arguments

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-19 
18:07 ---
Confirmed, just an off by one error as we are counting the program name (aka 
argument 0).

-- 
   What|Removed |Added

OtherBugsDependingO||19292
  nThis||
 Status|UNCONFIRMED |NEW
  Component|fortran |libfortran
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-02-19 18:07:02
   date||


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

[Bug fortran/20086] New: gfortran print routine has problem with the character 'h'

[dir at lanl dot gov]

On the Macintosh, the gfortran print routine drops the character follow an 'h'
in an output string. This happens in hundreds of cases in my program's output.
Here is a simple example -

[dir:~/tests/gfortran] dir% gfortran -o print print.f
[dir:~/tests/gfortran] dir% print
  stiffness reformed for hllo hllo)
  stiffness reformed for ths hghstep)
STOP 0
[dir:~/tests/gfortran] dir% cat print.f
  program main
  write(*,2090)
  write(*,2070)
  stop

 2070  format (2x,37hstiffness reformed for this high step)
 2090  format (2x,34hstiffness reformed for hello hello)

  end

-- 
   Summary: gfortran print routine has problem with the character
'h'
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dir at lanl dot gov
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: powerpc-apple-darwin7.8.0


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

[Bug fortran/20086] gfortran print routine has problem with the character 'h'

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-19 
18:15 ---
Confirmed, I really thought I saw this before.

-- 
   What|Removed |Added

OtherBugsDependingO||19292
  nThis||
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-02-19 18:15:51
   date||


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

[Bug ada/18819] ACATS cdd2a02 fails at runtime

[laurent at guerby dot net]

--- Additional Comments From laurent at guerby dot net  2005-02-19 18:27 
---
I confirm the test PASS with -O2 -fno-tree-sra on x86 and x86_64-linux.

-- 


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

[Bug libgcj/20087] New: gij should support -verbose:jni

[tromey at gcc dot gnu dot org]

We don't support -verbose:jni, but we could.

We could also support -verbose:gc (to some extent),
and, with the BC ABI, could even add a tracing option
to trace all calls.

-- 
   Summary: gij should support -verbose:jni
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P2
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tromey at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org


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

[Bug ada/18659] [4.0 Regression] ACATS ICE in bug in tree-sra.c:1507 on x86 and ppc-darwin (6 FAIL)

[laurent at guerby dot net]

--- Additional Comments From laurent at guerby dot net  2005-02-19 18:28 
---
I confirm all six ACATS tests PASS with -O2 -fno-tree-sra on x86-linux.

-- 


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

[Bug libgcj/20087] gij should support -verbose:jni

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-19 
18:29 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-02-19 18:29:14
   date||
Summary|gij should support -|gij should support -
   |verbose:jni |verbose:jni


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

[Bug java/20088] New: -findirect-dispatch: error: final field 'text' may not have been initialized

[timo dot lindfors at iki dot fi]

Compiling

public class FinalTest2 {
public static final String text = "foo";
public static void main(String[] args) {
System.out.println(text);
}

}

fails if I use -findirect-dispatch:

$ gcj -findirect-dispatch FinalTest2.java --main=FinalTest2 -o FinalTest2
FinalTest2.java: In class 'FinalTest2':
FinalTest2.java: In method '()':
FinalTest2.java:2: error: final field 'text' may not have been initialized
FinalTest2.java: At top level:
FinalTest2.java:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

-- 
   Summary: -findirect-dispatch: error: final field 'text' may not
have been initialized
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: timo dot lindfors at iki dot fi
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org


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

[Bug ada/20089] New: [4.0 Regression] gnatmake broken when building ada tools

[mmazur at kernel dot pl]

Building fails here: 
 
touch ../stamp-tools 
../../gnatmake -c -I../rts -I. 
-I/home/users/builder/rpm/BUILD/gcc-4.0-20050213/gcc/ada 
gnatchop --GCC="../../xgcc -B../../ -O2 -O2 -mieee -mieee  -gnatpg -gnata" 
gnatmake: "gnatchop" not found 
 
Unified build environment on multiple archs shows this bug occurs only on 
alpha: 
http://ep09.pld-linux.org/~builderth/queue.html (sparc broke because of 
something else, 
which I've already fixed). 
 
Full buildlog can be found here: 
ftp://buildlogs.pld-linux.org/th/alpha/FAIL/gcc.bz2

-- 
   Summary: [4.0 Regression] gnatmake broken when building ada tools
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mmazur at kernel dot pl
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: alpha-pld-linux
GCC target triplet: alpha-pld-linux


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

[Bug java/20088] -findirect-dispatch: error: final field 'text' may not have been initialized

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-19 
19:39 ---
Confirmed but note right now that -findirect-dispatch is really only for 
compiling from bytecode.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||ice-on-valid-code, rejects-
   ||valid
   Last reconfirmed|-00-00 00:00:00 |2005-02-19 19:40:00
   date||


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

[Bug ada/19456] [4.0 regression] ada bootstrap failure on alpha-linux

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-19 
19:42 ---
Is this fixed now?

-- 


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

[Bug ada/20089] [4.0 Regression] gnatmake broken when building ada tools

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-19 
19:44 ---
hmm, RTH was able to build and report Ada results on alpha-linux-gnu:
http://gcc.gnu.org/ml/gcc-testresults/2005-02/msg00683.html

-- 


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

[Bug rtl-optimization/336] Superfluous instructions generated from bit-field operations

[roger at eyesopen dot com]

--- Additional Comments From roger at eyesopen dot com  2005-02-19 19:56 
---
This bug has now been fixed for gcc 4.0.  For the testcase attached to the PR,
mainline now generates the following code on sparc-sun-solaris2.8 with -O2:

fun:ld  [%sp+64], %o5
sll %o0, 2, %g1
mov %o5, %o0
or  %g1, 2, %g1
jmp %o7+12
st %g1, [%o5]

i.e. we've now eliminated the unnecessary "and" and "or" instructions, that
were present in 2.95.2 (and still present in 3.4.3).


-- 
   What|Removed |Added

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


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

[Bug middle-end/19466] [meta-bug] bit-fields are non optimal

[roger at eyesopen dot com]

-- 
Bug 19466 depends on bug 336, which changed state.

Bug 336 Summary: Superfluous instructions generated from bit-field operations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=336

   What|Old Value   |New Value

 Status|SUSPENDED   |RESOLVED
 Resolution||FIXED

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

[Bug libgcj/20090] New: gij should be implemented in Java

[fitzsim at redhat dot com]

We need a new class gnu.gcj.runtime.Main that handles the same set of non-jvm
options handled by the java command.  Then gij.cc could use the invocation API
to parse out the jvm options, create a jvm, set up the java argument list and
call gnu.gcj.runtime.Main.main.  This would allow us to easily create a proper
"java" command, using the invocation API.  Also, it would eliminate the need for
libgij.  Instead, one could do:

gcj --main=gnu.gcj.runtime.Main -D...

-- 
   Summary: gij should be implemented in Java
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libgcj
AssignedTo: fitzsim at redhat dot com
ReportedBy: fitzsim at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org


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

[Bug ada/20089] [4.0 Regression] gnatmake broken when building ada tools

[mmazur at kernel dot pl]

--- Additional Comments From mmazur at kernel dot pl  2005-02-19 20:10 
---
I've managed to google myself to PR18434 so looks like there is something wrong 
with 
alpha. 
 
Though I've seen stuff being broken depending on what languages are marked as 
supported (I've turned on only c++ and ada). 
 
Either way, I'll be building a whole distro (5 archs included) based on gcc4 
and I need this 
working, so even a workaround would help. 

-- 


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

[Bug libgcj/20090] gij should be implemented in Java

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-19 
20:10 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-02-19 20:10:58
   date||
Version|unknown |4.0.0


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

[Bug libstdc++/20091] New: 18_support/14026.cc execution test fails

[jsm28 at gcc dot gnu dot org]

The libstdc++ test 18_support/14026.cc execution test has recently
started failing on multiple targets.  Observed on ia64-hpux and hppa64-hpux;
gcc-testresults also shows it on powerpc64-unknown-linux-gnu,
i686-pc-linux-gnu, powerpc-unknown-linux-gnu and ia64-suse-linux-gnu.

-- 
   Summary: 18_support/14026.cc execution test fails
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsm28 at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug ada/20089] [4.0 Regression] gnatmake broken when building ada tools

[laurent at guerby dot net]

--- Additional Comments From laurent at guerby dot net  2005-02-19 20:32 
---
Yes this is probably a miscompilation of gnatmake, you may try to set boot flags
to -O0 or -O1 instead of -O2. No idea on why RTH doesn't see this.

-- 


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

[Bug c++/19440] Invalid destructor declaration in template class accepted

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-02-19 
20:37 ---
Subject: Bug 19440

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-02-19 20:36:57

Modified files:
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/g++.dg/inherit: volatile1.C 
gcc/testsuite/g++.dg/template: dtor4.C 

Log message:
PR c++/19299
* g++.dg/inherit/volatile1.C: New test.

PR c++/19440
* g++.dg/template/dtor4.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5057&r2=1.5058
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/inherit/volatile1.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/dtor4.C.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug c++/19299] [4.0 Regression] ICE with volatile non-PODs pointers

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-02-19 
20:37 ---
Subject: Bug 19299

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-02-19 20:36:57

Modified files:
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/g++.dg/inherit: volatile1.C 
gcc/testsuite/g++.dg/template: dtor4.C 

Log message:
PR c++/19299
* g++.dg/inherit/volatile1.C: New test.

PR c++/19440
* g++.dg/template/dtor4.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5057&r2=1.5058
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/inherit/volatile1.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/dtor4.C.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug libstdc++/20091] 18_support/14026.cc execution test fails

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-19 
20:37 ---
I cannot tell if this expected or that this was recently changed with RTH's 
patch.

-- 


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

[Bug fortran/20092] New: gfortran not correctly padding keyboard or text file input

[dir at lanl dot gov]

Several of my progams use this method to read from the keyboard or a text file.
It should read input and print it until the first character on a line is a 's'.
Absoft 8.0 shows the correct response. gfortran gets a run time error reading
from a file and ignores the carrage returns when reading the keyboard.


[dir:~/tests/gfortran] dir% f77 -o char3 char3.f
FORTRAN 77 Compiler 8.0a, Copyright (c) 1987-2003, Absoft Corp.
[dir:~/tests/gfortran] dir% char3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20092

[Bug libfortran/20092] gfortran not correctly padding keyboard or text file input

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|fortran |libfortran


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

[Bug target/20093] New: [4.0 Regression] 23_containers/deque/cons/2.cc execution test fails on ia64-hpux, -milp32

[jsm28 at gcc dot gnu dot org]

The libstdc++ test 23_containers/deque/cons/2.cc execution test fails on
ia64-hpux with -milp32 (but not with -mlp64).  This is a regression from 3.4.x.

The particular test function which fails is test_copy_ctor_exception_safety
but I haven't reduced the test to a form not depending on the libstdc++
testsuite infrastructure.

-- 
   Summary: [4.0 Regression] 23_containers/deque/cons/2.cc execution
test fails on ia64-hpux, -milp32
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsm28 at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: ia64-*-hpux11.*


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

[Bug target/20093] [4.0 Regression] 23_containers/deque/cons/2.cc execution test fails on ia64-hpux, -milp32

[jsm28 at gcc dot gnu dot org]

--- Additional Comments From jsm28 at gcc dot gnu dot org  2005-02-19 20:57 
---
Created an attachment (id=8234)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8234&action=view)
slightly cut-down testcase


-- 


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

[Bug rtl-optimization/20017] [4.0 Regression] internal compiler error: in rtl_verify_flow_info, at cfgrtl.c:2212

[kazu at cs dot umass dot edu]

--- Additional Comments From kazu at cs dot umass dot edu  2005-02-19 21:03 
---
Patch posted at:

http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01131.html

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug c++/19980] [4.0 regression] ICE on invalid template declaration

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2005-02-19 
21:04 ---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01132.html

-- 
   What|Removed |Added

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


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

[Bug target/20094] New: gcc.dg/transparent-union-* fail on ia64-hpux

[jsm28 at gcc dot gnu dot org]

The tests gcc.dg/transparent-union-1.c and gcc.dg/transparent-union-2.c
fail on ia64-hpux.  Problems start with:

/scratch/joseph/gcc-mainline/gcc/testsuite/gcc.dg/transparent-union-1.c:12:
warning: 'transparent_union' attribute ignored

The union has mode BLKmode while the fields have mode SImode.

Not a regression relative to 3.4.x.

-- 
   Summary: gcc.dg/transparent-union-* fail on ia64-hpux
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsm28 at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: ia64-*-hpux11.*


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

[Bug target/20094] gcc.dg/transparent-union-* fail on ia64-hpux

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-19 
21:24 ---
Hmm, Does anyone know how these union are supposed to be passed on ia64-*-hpux, 
if by referrence 
then the warning is correct and the testcase should not be tested on this 
target.  This is an ABI Issue.

-- 
   What|Removed |Added

   Keywords||ABI


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

[Bug middle-end/20034] [4.0 Regression] g++.dg/inherit/thunk2.C fails

[jsm28 at gcc dot gnu dot org]

--- Additional Comments From jsm28 at gcc dot gnu dot org  2005-02-19 21:29 
---
Now fixed on mainline, probably was indeed caused by that suspicious patch.


-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/20034] [4.0 Regression] g++.dg/inherit/thunk2.C fails

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.0.0


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

[Bug fortran/20086] gfortran print routine has problem with the character 'h'

[bdavis at gcc dot gnu dot org]

--- Additional Comments From bdavis at gcc dot gnu dot org  2005-02-19 
21:58 ---
patch here:


http://gcc.gnu.org/ml/fortran/2005-02/msg00177.html

-- 


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

[Bug target/20095] New: gcc.dg/cleanup-5.c fails on ia64-hpux

[jsm28 at gcc dot gnu dot org]

The test gcc.dg/cleanup-5.c fails on ia64-hpux.  Not a regression relative
to 3.4.x.

There are several problems:

(a) It needs to link against -lunwind.

(b) __gcc_personality_v0 is not defined because unwind-c.c isn't being
used on IA64 HP-UX.

(c) If you add $(srcdir)/unwind-c.c to LIB2ADDEH in config/ia64/t-hpux,
and link with -lgcc_eh -lunwind, then the test will link but dumps core
on execution.

-- 
   Summary: gcc.dg/cleanup-5.c fails on ia64-hpux
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsm28 at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: ia64-*-hpux11.*


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

[Bug target/20095] gcc.dg/cleanup-5.c fails on ia64-hpux

[jsm28 at gcc dot gnu dot org]

--- Additional Comments From jsm28 at gcc dot gnu dot org  2005-02-19 22:12 
---
Created an attachment (id=8235)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8235&action=view)
Patch to use unwind-c.c

This patch allows the test to link if -lgcc_eh -lunwind are used.
I haven't submitted it since it doesn't fix any test failures.


-- 


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

[Bug fortran/20096] New: gfortran -d8 option not working

[dir at lanl dot gov]

Some of my programs need this option, but I finally found out that it is not
working. -d makes no difference in the print out of the c routine, but it 
should  -

[dir:~/tests/gfortran] dir% gfortran -c ptran.f
[dir:~/tests/gfortran] dir% cc -c cend.c
[dir:~/tests/gfortran] dir% gfortran -o ptran ptran.o cend.o
[dir:~/tests/gfortran] dir% ptran
cend 10 20 10 20 
STOP 0
[dir:~/tests/gfortran] dir% gfortran -d8 -c ptran.f
[dir:~/tests/gfortran] dir% gfortran -o ptran ptran.o cend.o
[dir:~/tests/gfortran] dir% ptran
cend 10 20 10 20 
STOP 0
[dir:~/tests/gfortran] dir% cat ptran.f
  program ptran
  ixmin = 10
  iymin = 10
  ixmax = 20
  iymax = 20
  call cend(ixmin,ixmax,iymin,iymax)
  stop
  end
[dir:~/tests/gfortran] dir% cat cend.c
int cend_(long *ixmin,long *ixmax,long *iymin,long *iymax)
{
printf("cend %ld %ld %ld %ld \n",*ixmin,*ixmax,*iymin,*iymax);
return 0;
}

-- 
   Summary: gfortran -d8 option not working
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dir at lanl dot gov
CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: powerpc-apple-darwin7.8.0


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

[Bug rtl-optimization/20097] New: [4.0 regression] ICE in reload_cse_simplify_operands

[schwab at suse dot de]

$ gcc/xgcc -v -B gcc -O2 -S md.i 
Reading specs from gcc/specs
Target: ia64-suse-linux
Configured with: ../configure --host=ia64-suse-linux --enable-shared 
--enable-threads --enable-__cxa_atexit --with-system-zlib 
--with-system-libunwind
Thread model: posix
gcc version 4.0.0 20050219 (experimental)
 gcc/cc1 -fpreprocessed md.i -quiet -dumpbase md.i -auxbase md -O2 -version -o 
md.s
GNU C version 4.0.0 20050219 (experimental) (ia64-suse-linux)
compiled by GNU C version 4.0.0 20050219 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
md.i: In function ‘do_md’:
md.i:3741: error: insn does not satisfy its constraints:
(insn 5989 5988 5990 236 (set (reg:SI 262 p6)
(reg:SI 17 r17)) 4 {*movsi_internal} (nil)
(nil))
md.i:3741: internal compiler error: in reload_cse_simplify_operands, at 
postreload.c:391
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.


Broken by this change:

2005-02-06  Roger Sayle  <[EMAIL PROTECTED]>
Andrew Pinski  <[EMAIL PROTECTED]>
Paolo Bonzini  <[EMAIL PROTECTED]>

* simplify-rtx.c (simplify_relational_operation_1): Simplify
(ne:SI (zero_extract:SI FOO (const_int 1) BAR) (const_int 0))
into just (zero_extract:SI FOO (const_int 1) BAR).

-- 
   Summary: [4.0 regression] ICE in reload_cse_simplify_operands
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P2
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schwab at suse dot de
CC: gcc-bugs at gcc dot gnu dot org,paolo dot bonzini at lu
dot unisi dot ch,pinskia at physics dot uc dot edu,roger
at eyesopen dot com
GCC target triplet: ia64-suse-linux


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

[Bug rtl-optimization/20097] [4.0 regression] ICE in reload_cse_simplify_operands

[schwab at suse dot de]

--- Additional Comments From schwab at suse dot de  2005-02-19 22:37 ---
Created an attachment (id=8236)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8236&action=view)
Testcase


-- 


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

[Bug rtl-optimization/20097] [4.0 regression] ICE in reload_cse_simplify_operands

[schwab at suse dot de]

-- 
   What|Removed |Added

   Target Milestone|--- |4.0.0


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

[Bug middle-end/20066] Ordering of logical constants determines if they're correctly emitted

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2005-02-19 22:54 
---
One more data point:
depending on the order of the functions test1 and test8 the following testcase
will print different results on ix86:
character*2 :: t(2), f(2), test1, test8

t(1) = test1(1)
f(1) = test1(0)
t(2) = test8(1)
f(2) = test8(0)

print *, t
print *, f
end
function test8(i) result(r)
  integer :: i
  character*2 :: r

  if (i==1) then
 write (r, *) .TRUE._8
  else
 write (r, *) .FALSE._8
  end if
end function test8
function test1(i) result(r)
  integer :: i
  character*2 :: r

  if (i==1) then
 write (r, *) .TRUE._1
  else
 write (r, *) .FALSE._1
  end if
end function test1

if test8 comes in front of test1 we get the correct:
  T T
  F F
if test1 comes first (that is, if the order of the functions, not the calls, is
interchanged):
  T T
  F T
which is wrong in the logical(8) case.

The assembly shows the same anomaly as I pointed out in the initial bug report.

-- 


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

[Bug fortran/20096] gfortran -d8 option not working

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-19 
23:13 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug driver/13464] -i8 and -r8 not passed correctly to compiler proper. and -d8 does not work

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-19 
23:13 ---
*** Bug 20096 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||dir at lanl dot gov


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

[Bug target/20094] gcc.dg/transparent-union-* fail on ia64-hpux

[wilson at specifixinc dot com]

--- Additional Comments From wilson at specifixinc dot com  2005-02-19 
23:15 ---
Subject: Re:  gcc.dg/transparent-union-* fail on ia64-hpux

pinskia at gcc dot gnu dot org wrote:
> --- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-19 
> 21:24 ---
> Hmm, Does anyone know how these union are supposed to be passed on 
> ia64-*-hpux, if by referrence 
> then the warning is correct and the testcase should not be tested on this 
> target.  This is an ABI Issue.

unions get passed right-aligned little-endian and left-aligned 
big-endian.  Since linux is little-endian, and HPUX is big-endian, only 
HPUX has a problem here.  HPUX defines MEMBER_TYPE_FORCES_BLK to make 
this work.  There are other ways to solve this problem used by other 
targets, for instance, defining BLOCK_REG_PADDING for HPUX.  Getting 
BLOCK_REG_PADDING to work can be tricky though.

It looks like the ia64/hpux.h is the only one that defines 
MEMBER_TYPE_FORCES_BLK that can trigger this problem, since the others 
don't trigger on pointer or integer types.

It appears that MEMBER_TYPE_FORCES_BLK should not be used for a 
transparent union, or should be used differently.  This check could 
perhaps be done unconditionally in stor-layout.c.  This might be a 
simple solution.

Or maybe we can pass the union/structure type to MEMBER_TYPE_FORCES_BLK 
and modify the ia64/hpux.h version of the macro to check for the 
transparent_union attribute.


-- 


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

[Bug rtl-optimization/20097] [4.0 regression] ICE in reload_cse_simplify_operands

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-19 
23:16 ---
This seems more likely a target bug or a latent bug.

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org


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

[Bug target/20045] gcc.dg/ia64-fptr-1.c fails on ia64-hpux

[wilson at specifixinc dot com]

--- Additional Comments From wilson at specifixinc dot com  2005-02-19 
23:31 ---
Subject: Re:  New: gcc.dg/ia64-fptr-1.c fails on ia64-hpux

jsm28 at gcc dot gnu dot org wrote:
> ld: Unsatisfied symbol "_GLOBAL_OFFSET_TABLE_" in file /var/tmp//ccU3vrUt.o

DT_PLTGOT will hold the gp value if the program was dynamically linked, 
but it might be too inconvenient to get to this value.  I am not sure 
how to get it other than by running objdump and grepping the output. 
Otherwise, I don't believe the ABI provides a way to get at the value.

Another solution is to use an asm to grab the value from r1.  This 
should work fine as the functions are in the same module, and hence will 
use the same gp value.

Or we could just make this a linux specific testcase.


-- 


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

[Bug libstdc++/20091] [4.0 Regression] 18_support/14026.cc execution test fails

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-19 
23:33 ---
Confirmed:
http://gcc.gnu.org/ml/gcc-regression/2005-02/msg00067.html

-- 
   What|Removed |Added

 CC||rth at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||EH
   Last reconfirmed|-00-00 00:00:00 |2005-02-19 23:33:26
   date||
Summary|18_support/14026.cc |[4.0 Regression]
   |execution test fails|18_support/14026.cc
   ||execution test fails
   Target Milestone|--- |4.0.0


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

[Bug rtl-optimization/20097] [4.0 regression] ICE in reload_cse_simplify_operands

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 CC|pinskia at physics dot uc   |
   |dot edu |


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

[Bug target/18214] [ia64] Wrong code for function call involving copy constuctor

[jsm28 at gcc dot gnu dot org]

--- Additional Comments From jsm28 at gcc dot gnu dot org  2005-02-19 23:59 
---
Confirmed with 3.4.3.  Fixed on mainline.


-- 
   What|Removed |Added

 CC||jsm28 at gcc dot gnu dot org
 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.0.0


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

[Bug target/19061] IA64 GCC pointer confusion results in optimization error

[jsm28 at gcc dot gnu dot org]

--- Additional Comments From jsm28 at gcc dot gnu dot org  2005-02-20 00:03 
---
Confirmed with mainline and 3.4.3.


-- 
   What|Removed |Added

 CC||jsm28 at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  Known to fail||3.4.3 4.0.0
   Last reconfirmed|-00-00 00:00:00 |2005-02-20 00:03:52
   date||


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

[Bug rtl-optimization/20097] [4.0 regression] ICE in reload_cse_simplify_operands

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-20 
00:09 ---
This looks like a reload (or a target reload) issue:
We have the following RTL:
(insn 4097 4096 4098 236 (set (reg:BI 2598)
(and:BI (ne:BI (reg/v:SI 477 [ bNotLastFrame ])
(const_int 0 [0x0]))
(subreg:BI (reg:SI 2934) 0))) 66 {*cmpsi_and_0} (nil)
(nil))

Note the subreg here.  We exand it to:
(insn 5994 4096 5995 236 (set (reg:SI 2 r2)(reg:SI 131 f3 [2934])) 4 
{*movsi_internal} (nil)(nil)) 
(insn 5995 5994 5996 236 (set (reg:SI 262 p6)(reg:SI 2 r2)) 4 
{*movsi_internal} (nil) (nil))
(insn 5996 5995 4097 236 (set (reg:SI 2 r2)
(reg/v:SI 148 f20 [orig:477 bNotLastFrame ] [477])) 4 {*movsi_internal} 
(nil) (nil))(insn 
4097 5996 4098 236 (set (reg:BI 262 p6 [2598])(and:BI (ne:BI (reg:SI 2 
r2) (const_int 0 
[0x0]))(reg:BI 262 p6))) 66 {*cmpsi_and_0} (nil) (nil))

So either we have a reload issue or we have a target issue.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-02-20 00:09:20
   date||


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

[Bug c++/20098] New: Unresolved dependent "static const" symbol in template

[wwieser at gmx dot de]

Compiling the following code with gcc-4.0.0 (20050219), (ld-2.15) 
will result in an error at link time complaining about all_set being  
an unresolved symbol. This is a regression compared to the version some  
weeks ago.  
 
--- 
templatestruct A 
{ 
 static const T all_clr = T(0); 
 static const T all_set = ~all_clr; 
}; 
 
int main() 
{ 
 A bf; 
  
 return(bf.all_set); 
} 
---

-- 
   Summary: Unresolved dependent "static const" symbol in template
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wwieser at gmx dot de
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-linux-gnu
  GCC host triplet: i686-linux-gnu
GCC target triplet: i686-linux-gnu


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

[Bug c++/20098] Unresolved dependent "static const" symbol in template

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-20 
00:12 ---
Note the testcase is invalid code, this is only a missed optimization.

-- 
   What|Removed |Added

   Keywords||missed-optimization


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

[Bug c++/20098] Unresolved dependent "static const" symbol in template

[wwieser at gmx dot de]

--- Additional Comments From wwieser at gmx dot de  2005-02-20 00:31 ---
Subject: Re:  Unresolved dependent "static const" symbol in template

Thanks for a REALLY quick reply!

templatestruct A
{
 static const T all_clr = T(0);
 static const T all_set = ~all_clr;
};

int main()
{
 A bf;
 
 return(bf.all_set);
}

On Sunday 20 February 2005 01:12, pinskia at gcc dot gnu dot org wrote:
> Note the testcase is invalid code, 
>
Could you please elaborate on what exactly is invalid?

> this is only a missed optimization. 
>
(?? - The unresolved symbol is independent of the optimization level.)

Regards,
Wolfgang

--- Additional Comments From wwieser at gmx dot de  2005-02-20 00:31 ---
Subject: Re:  Unresolved dependent "static const" symbol in template

Thanks for a REALLY quick reply!

templatestruct A
{
 static const T all_clr = T(0);
 static const T all_set = ~all_clr;
};

int main()
{
 A bf;
 
 return(bf.all_set);
}

On Sunday 20 February 2005 01:12, pinskia at gcc dot gnu dot org wrote:
> Note the testcase is invalid code, 
>
Could you please elaborate on what exactly is invalid?

> this is only a missed optimization. 
>
(?? - The unresolved symbol is independent of the optimization level.)

Regards,
Wolfgang


-- 


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

[Bug c++/20098] Unresolved dependent "static const" symbol in template

[wwieser at gmx dot de]

--- Additional Comments From wwieser at gmx dot de  2005-02-20 00:31 ---
Subject: Re:  Unresolved dependent "static const" symbol in template

Thanks for a REALLY quick reply!

templatestruct A
{
 static const T all_clr = T(0);
 static const T all_set = ~all_clr;
};

int main()
{
 A bf;
 
 return(bf.all_set);
}

On Sunday 20 February 2005 01:12, pinskia at gcc dot gnu dot org wrote:
> Note the testcase is invalid code, 
>
Could you please elaborate on what exactly is invalid?

> this is only a missed optimization. 
>
(?? - The unresolved symbol is independent of the optimization level.)

Regards,
Wolfgang

--- Additional Comments From wwieser at gmx dot de  2005-02-20 00:31 ---
Subject: Re:  Unresolved dependent "static const" symbol in template

Thanks for a REALLY quick reply!

templatestruct A
{
 static const T all_clr = T(0);
 static const T all_set = ~all_clr;
};

int main()
{
 A bf;
 
 return(bf.all_set);
}

On Sunday 20 February 2005 01:12, pinskia at gcc dot gnu dot org wrote:
> Note the testcase is invalid code, 
>
Could you please elaborate on what exactly is invalid?

> this is only a missed optimization. 
>
(?? - The unresolved symbol is independent of the optimization level.)

Regards,
Wolfgang


-- 


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

[Bug c++/20098] Unresolved dependent "static const" symbol in template

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-02-20 
00:34 ---
(In reply to comment #3)
> Subject: Re:  Unresolved dependent "static const" symbol in template
> 
> Thanks for a REALLY quick reply!
> 
> templatestruct A
> {
>  static const T all_clr = T(0);
>  static const T all_set = ~all_clr;
> };
> 
> int main()
> {
>  A bf;
>  
>  return(bf.all_set);
> }
> 
> On Sunday 20 February 2005 01:12, pinskia at gcc dot gnu dot org wrote:
> > Note the testcase is invalid code, 
> >
> Could you please elaborate on what exactly is invalid?

Yes you need to have declare the storage for the static variables (even though 
they are constant you still 
need the storage area, for an example if you take the address of the variable 
where is the storage of the 
variable if you have not declared it).

-- 


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

[Bug middle-end/5169] paradoxical subreg problem

[jsm28 at gcc dot gnu dot org]

--- Additional Comments From jsm28 at gcc dot gnu dot org  2005-02-20 00:34 
---
The testcase no longer exhibits the bug, so this PR seems to represent
some underlying problem with compiler internals rather than any longer
being concerned with the failure of a particular testcase.

Jeff Law had a patch at .
The discussion doesn't indicate anything in particular wrong with it,
was there some reason it wasn't applied?

The other bugs mentioned at ,
bug 5185 and bug 5264 have both been closed on the basis that the listed
problems could no longer be reproduced, whether or not the underlying
compiler issue was still present.


-- 
   What|Removed |Added

 CC||jsm28 at gcc dot gnu dot org
  Component|target  |middle-end
Summary|[PA-RISC] Bug in optimizer  |paradoxical subreg problem


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