[Bug target/21098] .note.GNU-stack emitted

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-19 
07:07 ---
Subject: Bug 21098

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

Modified files:
gcc: ChangeLog 
gcc/config/rs6000: linux64.h rs6000.c 

Log message:
PR target/21098
* config/rs6000/rs6000.c (rs6000_elf_end_indicate_exec_stack): New.
* config/rs6000/linux64.h (TARGET_ASM_FILE_END): Use the above.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8358&r2=2.8359
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/linux64.h.diff?cvsroot=gcc&r1=1.74&r2=1.75
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000.c.diff?cvsroot=gcc&r1=1.808&r2=1.809



-- 


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

[Bug fortran/16861] segfault with doubly used module

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-19 
07:10 ---
Subject: Bug 16861

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

Modified files:
gcc/fortran: ChangeLog resolve.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gfortran.dg: pr16861.f90 

Log message:
PR fortran/16861
* resolve.c (resolve_variable): If e->symtree is not set, this
ought to be a FAILURE, and not a segfault.
* gfortran.dg/pr16861.f90: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.397&r2=1.398
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/resolve.c.diff?cvsroot=gcc&r1=1.39&r2=1.40
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5369&r2=1.5370
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/pr16861.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug fortran/16861] segfault with doubly used module

[fxcoudert at gcc dot gnu dot org]

--- Additional Comments From fxcoudert at gcc dot gnu dot org  2005-04-19 
07:24 ---
Like comment #5 says, this one is not fixed. The patch I committed only adress
part of the issue. Removed patch keyword accordingly.

-- 
   What|Removed |Added

   Keywords|patch   |
   Last reconfirmed|2005-04-18 13:12:03 |2005-04-19 07:24:32
   date||


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

[Bug target/21099] New: ICE on mmx intrinsics

[jochang at gmail dot com]

ICE on gcc 4.0.0rc2, but works on both 3.3.5 and 3.4.3.

$ /usr/local/gcc-4.0/bin/g++ -c -O -mmmx 1.cpp
1.cpp: In function 'void f()':
1.cpp:51: internal compiler error: in simplify_subreg, at simplify-rtx.c:3729

-- 
   Summary: ICE on mmx intrinsics
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jochang at gmail dot com
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=21099

[Bug target/21099] ICE on mmx intrinsics

[jochang at gmail dot com]

--- Additional Comments From jochang at gmail dot com  2005-04-19 08:05 
---
Created an attachment (id=8680)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8680&action=view)
the test case


-- 


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

[Bug target/21100] New: ICE: unrecognizable insn for -march=pentium-mmx

[jochang at gmail dot com]

ICE on gcc 4.0.0rc2, but both 3.3.5 and 3.4.3 work.
No ICE if change pentium-mmx to pentium2.

$ /usr/local/gcc-4.0/bin/g++ -c -march=pentium-mmx 2.cpp
2.cpp: In function 'void f()':
2.cpp:30: error: unrecognizable insn:
(insn 13 12 14 0 (set (mem/i:V2SI (pre_dec:SI (reg/f:SI 7 sp)) [0 S8 A64])
(reg:V2SI 61 [ a ])) -1 (nil)
(expr_list:REG_DEAD (reg:V2SI 61 [ a ])
(nil)))
2.cpp:30: internal compiler error: in extract_insn, at recog.c:2020

-- 
   Summary: ICE: unrecognizable insn for -march=pentium-mmx
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jochang at gmail dot com
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=21100

[Bug target/21100] ICE: unrecognizable insn for -march=pentium-mmx

[jochang at gmail dot com]

--- Additional Comments From jochang at gmail dot com  2005-04-19 09:05 
---
Created an attachment (id=8681)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8681&action=view)
the test case


-- 


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

[Bug target/21091] -many flag causes problems

[carlos at mind dot be]

--- Additional Comments From carlos at mind dot be  2005-04-19 09:49 ---
Subject: Re:  -many flag causes problems

On Tuesday 19 April 2005 01:34, amodra at bigpond dot net dot au wrote:
> --- Additional Comments From amodra at bigpond dot net dot au 
> 2005-04-18 23:34 --- Please supply a small testcase.  Preprocessed
> source and commands to reproduce the problem.
>
> -many shouldn't ever change which insns are emitted under control of other
> -m flags, just make available extra instructions, so this is really a gas
> bug.

anyway, the problem is fixed if I remove the -many flag from the compiler 
line, so that's why I sent the patch.

If you want to test this try the attached file (taken from the ecos source 
tree) and compile as following:

powerpc-eabi-gcc -v -c  -I/home/carlos/Builds/ecos_ml300-0.1/install/include 
-I/home/carlos/Devel/ecos--ml300--0.1/packages/hal/powerpc/arch/current 
-I/home/carlos/Devel/ecos--ml300--0.1/packages/hal/powerpc/arch/current/src 
-I/home/carlos/Devel/ecos--ml300--0.1/packages/hal/powerpc/arch/current/tests 
-I. 
-I/home/carlos/Devel/ecos--ml300--0.1/packages/hal/powerpc/arch/current/src/ 
-finline-limit=7000 
-I/home/carlos/Devel/ecos--ml300--0.1/packages/hal/powerpc/ml300/current/include/xilinx
 
-DML300 -msoft-float -mcpu=405 -Wall -Wpointer-arith -Wstrict-prototypes 
-Winline -Wundef  -g -O2 -ffunction-sections -fdata-sections  -fno-exceptions   
-Wp,-MD,src/hal_intr.tmp -o 
src/hal_powerpc_arch_hal_intr.o 
/home/carlos/Devel/ecos--ml300--0.1/packages/hal/powerpc/arch/current/src/hal_intr.c

which produces the following results:

/mind/toolchain_powerpc-eabi_gcc-3.4.3_binutils-2.14_newlib-1.13/libexec/gcc/powerpc-eabi/3.4.3/cc1
 
-quiet -v -I/home/carlos/Builds/ecos_ml300-0.1/install/include 
-I/home/carlos/Devel/ecos--ml300--0.1/packages/hal/powerpc/arch/current 
-I/home/carlos/Devel/ecos--ml300--0.1/packages/hal/powerpc/arch/current/src 
-I/home/carlos/Devel/ecos--ml300--0.1/packages/hal/powerpc/arch/current/tests 
-I. 
-I/home/carlos/Devel/ecos--ml300--0.1/packages/hal/powerpc/arch/current/src/ 
-I/home/carlos/Devel/ecos--ml300--0.1/packages/hal/powerpc/ml300/current/include/xilinx
 
-DML300 -MD 
src/hal_intr.tmp 
/home/carlos/Devel/ecos--ml300--0.1/packages/hal/powerpc/arch/current/src/hal_intr.c
 
-quiet -dumpbase hal_intr.c -msoft-float -mcpu=405 -auxbase-strip 
src/hal_powerpc_arch_hal_intr.o -g -O2 -Wall -Wpointer-arith 
-Wstrict-prototypes -Winline -Wundef -version -finline-limit=7000 
-ffunction-sections -fdata-sections -fno-exceptions -o /tmp/ccDl04KQ.s
ignoring nonexistent directory 
"/mind/toolchain_powerpc-eabi_gcc-3.4.3_binutils-2.14_newlib-1.13/lib/gcc/powerpc-eabi/3.4.3/../../../../powerpc-eabi/sys-include"
ignoring nonexistent directory 
"/home/carlos/Devel/ecos--ml300--0.1/packages/hal/powerpc/arch/current/tests"
ignoring duplicate directory 
"/home/carlos/Devel/ecos--ml300--0.1/packages/hal/powerpc/arch/current/src/"
#include "..." search starts here:
#include <...> search starts here:
 /home/carlos/Builds/ecos_ml300-0.1/install/include
 /home/carlos/Devel/ecos--ml300--0.1/packages/hal/powerpc/arch/current
 /home/carlos/Devel/ecos--ml300--0.1/packages/hal/powerpc/arch/current/src
 .
 
/home/carlos/Devel/ecos--ml300--0.1/packages/hal/powerpc/ml300/current/include/xilinx
 
/mind/toolchain_powerpc-eabi_gcc-3.4.3_binutils-2.14_newlib-1.13/lib/gcc/powerpc-eabi/3.4.3/include
 
/mind/toolchain_powerpc-eabi_gcc-3.4.3_binutils-2.14_newlib-1.13/lib/gcc/powerpc-eabi/3.4.3/../../../../powerpc-eabi/include
End of search list.
GNU C version 3.4.3 (powerpc-eabi)
compiled by GNU C version 3.3.5 (Debian 1:3.3.5-8).
GGC heuristics: --param ggc-min-expand=42 --param ggc-min-heapsize=24026
 
/mind/toolchain_powerpc-eabi_gcc-3.4.3_binutils-2.14_newlib-1.13/lib/gcc/powerpc-eabi/3.4.3/../../../../powerpc-eabi/bin/as
 
--traditional-format -m405 -many -V -Qy -o 
src/hal_powerpc_arch_hal_intr.o /tmp/ccDl04KQ.s
GNU assembler version 2.14 (powerpc-eabi) using BFD version 2.14 20030612
/tmp/ccDl04KQ.s: Assembler messages:
/tmp/ccDl04KQ.s:72: Error: Unrecognized opcode: `mfdec'
/tmp/ccDl04KQ.s:78: Error: Unrecognized opcode: `mfdec'

as you may seem, it invokes as with the -many flag, which is no required for 
405 or 403 (they are specialized ppc procesors). So when it comes to mfdec it 
complains because it is not a standard ppc instruction.


--- Additional Comments From carlos at mind dot be  2005-04-19 09:49 ---
Created an attachment (id=8682)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8682&action=view)


-- 


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

[Bug tree-optimization/19126] Missed IV optimization (redundant instruction in loop)

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2005-04-19 
09:59 ---
Will be fixed by this patch for PR 19126:
http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01959.html


-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rakdver at atrey dot karlin
   |dot org |dot mff dot cuni dot cz
 Status|NEW |ASSIGNED
   Keywords||patch


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

[Bug rtl-optimization/15248] [4.0/4.1 Regression] Reload may generate stores to read-only memory

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2005-04-19 
10:03 ---
Eric, if you confirm that this bug is fixed in 3.3 and 3.4, then this is a 
(latent) regression on mainline and 4.0.

-- 
   What|Removed |Added

  Known to work||3.4.4 3.3.5
Summary|Reload may generate stores  |[4.0/4.1 Regression] Reload
   |to read-only memory |may generate stores to read-
   ||only memory
   Target Milestone|--- |4.0.1


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

[Bug target/21100] ICE: unrecognizable insn for -march=pentium-mmx

[giovannibajo at libero dot it]

-- 
   What|Removed |Added

   Attachment #8681|text/x-c++src   |text/plain
  mime type||


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

[Bug target/21100] [4.0/4.1 Regression] ICE: unrecognizable insn for -march=pentium-mmx

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2005-04-19 
10:06 ---
it might be a typo in the MMX/SSE cleanup...

-- 
   What|Removed |Added

 CC||rth at gcc dot gnu dot org
   Keywords||rejects-valid
  Known to work||3.3.5 3.4.2
Summary|ICE: unrecognizable insn for|[4.0/4.1 Regression] ICE:
   |-march=pentium-mmx  |unrecognizable insn for -
   ||march=pentium-mmx
   Target Milestone|--- |4.0.1


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

[Bug target/21101] New: ICE: could not find a spill register on MMX intrinsics

[jochang at gmail dot com]

ICE on gcc 4.0.0rc2, but both 3.3.5 and 3.4.3 work.

$ /usr/local/gcc-4.0/bin/g++ -c -O2 -funroll-loops -march=pentium4 3.cpp
3.cpp: In function 'void f()':
3.cpp:29: error: could not find a spill register
(insn:HI 95 94 96 0 (set (reg:V4HI 29 mm0 [orig:115 D.2920 ] [115])
(vec_duplicate:V4HI (truncate:HI (subreg:SI (reg:HI 111 [ B ]) 0 817
{*vec_dupv4hi} (insn_list:REG_DEP_TRUE 88 (nil))
(expr_list:REG_DEAD (reg:HI 111 [ B ])
(nil)))
3.cpp:29: internal compiler error: in failed_reload, at reload1.c:4982

-- 
   Summary: ICE: could not find a spill register on MMX intrinsics
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jochang at gmail dot com
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=21101

[Bug target/21101] ICE: could not find a spill register on MMX intrinsics

[jochang at gmail dot com]

--- Additional Comments From jochang at gmail dot com  2005-04-19 10:15 
---
Created an attachment (id=8683)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8683&action=view)
the test case


-- 


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

[Bug libstdc++/21035] Documentation for std::basic_string::compare() incorrect

[chris at bubblescope dot net]

--- Additional Comments From chris at bubblescope dot net  2005-04-19 10:19 
---
Yup, just checked the standard, and it agrees with the code (not the comment).

-- 


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

[Bug target/21102] New: ICE: in immed_double_const, on SSE2 intrinsics

[jochang at gmail dot com]

ICE on gcc 4.0.0rc2, but both 3.3.5 and 3.4.3 work.

$ /usr/local/gcc-4.0/bin/g++ -c -O -msse2 4.cpp
4.cpp: In function 'void f()':
4.cpp:10: internal compiler error: in immed_double_const, at emit-rtl.c:467

Here is the source:

#include 
__m128i S;
void f()
{
  __m128i A;
  A = _mm_add_epi8(A,A);
  A = _mm_andnot_si128(A,A);
  A = _mm_or_si128(A,A);
  _mm_store_si128(&S,A);
}

-- 
   Summary: ICE: in immed_double_const, on SSE2 intrinsics
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jochang at gmail dot com
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=21102

[Bug SWING/21064] StyleContext.addStyle causes NullPointerException

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-19 
10:52 ---
Subject: Bug 21064

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-04-19 10:52:04

Modified files:
libjava: ChangeLog 
libjava/javax/swing/text: StyleContext.java 

Log message:
2005-04-19  Roman Kennke  <[EMAIL PROTECTED]>

PR libgcj/21064
* javax/swing/text/StyleContext.java
(NamedStyle.setResolveParent): Added null
pointer check.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&r1=1.3510&r2=1.3511
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/javax/swing/text/StyleContext.java.diff?cvsroot=gcc&r1=1.3&r2=1.4



-- 


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

[Bug middle-end/21103] New: segfault with -fdump-tree-generic

[fxcoudert at gcc dot gnu dot org]

Compiling following code:
  program chk
  character*8 a
  a = 'a string'
  end

with gfortran and the -fdump-tree-generic induces a segfault:

Program received signal SIGSEGV, Segmentation fault.
0x0857af51 in dump_function_to_file (fn=0xb7ad6438, file=0x87ce8b8, flags=512)
at ../../../gcc/gcc/tree-cfg.c:5186
5186  if (basic_block_info)
(gdb) where
#0  0x0857af51 in dump_function_to_file (fn=0xb7ad6438, file=0x87ce8b8, 
flags=512) at ../../../gcc/gcc/tree-cfg.c:5186
#1  0x084e223f in dump_function (phase=TDI_generic, fn=0xb7ad6438)
at ../../../gcc/gcc/tree-dump.c:1020
#2  0x080b420a in gfc_gimplify_function (fndecl=0xb7ad6438)
at ../../../gcc/gcc/fortran/trans-decl.c:1289

This is specific to the generic tree dump, and is solved by the following change
in gcc/tree-cfg.c, line 5186:

-  if (basic_block_info)
+  if (cfun && basic_block_info)
  /* Make a CFG based dump.  */
  else
  /* Make a tree based dump.  */

The segfault actually occurs because basic_block_info is a macro for
cfun->cfg->x_basic_block_info and cfun is NULL in that case.

I don't know if this patch isn't hiding something deeper, so I report everything
I found here (which is not much, sorry, but that part of the compiler is too
deep for me!).

PS: I'm not sure the component should be middle-end, please change it if need 
be.

-- 
   Summary: segfault with -fdump-tree-generic
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P2
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug tree-optimization/21096] copy-prop leaks memory

[cvs-commit at gcc dot gnu dot org]

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

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2005-04-19 11:43:24

Modified files:
gcc: ChangeLog tree-ssa-copy.c 

Log message:
PR tree-optimization/21096
* tree-ssa-copy.c (fini_copy_prop): Free cached_last_copy_of.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8359&r2=2.8360
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-copy.c.diff?cvsroot=gcc&r1=2.26&r2=2.27



-- 


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

[Bug tree-optimization/21096] copy-prop leaks memory

[kazu at cs dot umass dot edu]

--- Additional Comments From kazu at cs dot umass dot edu  2005-04-19 11:44 
---
Just checked in a patch.


-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug fortran/21104] New: Segmentation fault on correct code

[paulthomas2 at wanadoo dot fr]

The following reduced program causes a segmentation fault at runtime.  It runs 
correctly if the *x on line 11 is removed.  From this, I would surmise that 
something is not right with the allocation of space for the temporary.  Further 
simplification of the structure of the program eliminates the fault; eg. making 
the function public and moving the expression from the subroutine to the main 
program works correctly.

A quick look with -fdump-tree-original indicates that, in the faulty case, no 
memory is allocated to the function output and its pointer remains NULL.

I have tried putting an explicit interface for generalized_hookes_law in the 
subroutine perdida but this has no effect.

$ cat test_intr.f90
!
!  Copyright (C) 1997 by Quetzal Computational Associates, Inc.
!
module perdida_m
private :: generalized_hookes_law
public  :: perdida
integer, parameter, private  :: LONGreal = selected_real_kind (15, 90)

contains

  subroutine perdida (z, x)
real (kind = LONGreal), dimension (:,:), intent (inOUT) :: z
real (kind = LONGreal), dimension (:,:), intent (inOUT) :: x
z = generalized_hookes_law (x) * x
  end subroutine perdida

  function generalized_hookes_law (x) result (z)
real (kind = LONGreal), dimension (3,3) :: z
real (kind = LONGreal), dimension (:,:), intent (in) :: x
z = x
  end function generalized_hookes_law

end module perdida_m

program iztaccihuatl
  use perdida_m
  integer, parameter  :: LONGreal = selected_real_kind (15, 90)
  real (kind = LONGreal)   ::  x(3,3) = 42.0_LONGreal
  real (kind = LONGreal)   ::  y(3,3)
  call perdida (y, x)
end program iztaccihuatl
[EMAIL PROTECTED] /cygdrive/d/gfortran
$ d:/check/bin/gfortran -std=f95 test_intr.f90

[EMAIL PROTECTED] /cygdrive/d/gfortran
$ ./a
Segmentation fault (core dumped)

-- 
   Summary: Segmentation fault on correct code
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: paulthomas2 at wanadoo dot fr
CC: Thomas dot Koenig at online dot de,gcc-bugs at gcc dot
gnu dot org


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

[Bug middle-end/21049] [4.1 Regression] ICE with -fdump-tree-all and fortran

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-19 
12:04 ---
*** Bug 21103 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org


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

[Bug middle-end/21103] segfault with -fdump-tree-generic

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-19 
12:04 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug fortran/21104] Segmentation fault on correct code

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-19 
12:21 ---
I don't think this is correct code.  See PR 20960.  Yes ICC does not seg fault 
on it.  I will note that XLC 
does the same thing as gfortran.

I also think this is a dup of bug 18197.

-- 


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

[Bug java/20768] Bytecode -> native code doesn't handle exception properly

[aph at gcc dot gnu dot org]

--- Additional Comments From aph at gcc dot gnu dot org  2005-04-19 12:33 
---
Should be fixed by

2005-04-18  Andrew Haley  <[EMAIL PROTECTED]>

* java-except.h (struct eh_range.handler): Remove unused field.
(handle_nested_ranges): Remove function declaration.
(sanity_check_exception_range): Add function declaration.
* verify.c (verify_jvm_instructions): Remove call to
handle_nested_ranges.
* verify-glue.c (verify_jvm_instructions_new): Call
sanity_check_exception_range.
* except.c (link_handler, eh_range_freelist, link_handler,
handle_nested_ranges): Remove.
(add_handler): Rewrite.
(sanity_check_exception_range): New function.
(print_ranges): New function.



-- 


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

[Bug SWING/21064] [4.0 only] StyleContext.addStyle causes NullPointerException

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-04-19 12:40:34
   date||
Summary|StyleContext.addStyle causes|[4.0 only]
   |NullPointerException|StyleContext.addStyle causes
   ||NullPointerException
   Target Milestone|--- |4.0.1


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

[Bug c/21105] New: Compiling of large array fails

[e9925248 at stud4 dot tuwien dot ac dot at]

Compiling
void
foo ()
{
  float c[20480][4];
}

fails with
t3.c: In function 'foo':
t3.c:16: internal compiler error: in tree_low_cst, at tree.c:3846

All current CVS versions (4.X fail).
At least some 3.x versions are not affected
GCC 2.96 shows an other error.

Affected Versions, which I tested:
4.1.0 20050416
4.1.0 20050302
2.96 2731 (Red Hat Linux 7.2 2.96-112.7.2)

Non Affected Version:
3.3.3 20040412 (Red Hat Linux 3.3.3-7)

-- 
   Summary: Compiling of large array fails
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: e9925248 at stud4 dot tuwien dot ac dot at
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=21105

[Bug middle-end/21105] [4.0/4.1 Regression] Compiling of large array fails

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-19 
13:08 ---
Confirmed, this is most likely caused by the tree-ssa merge.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|c   |middle-end
 Ever Confirmed||1
   Keywords||ice-on-invalid-code
  Known to fail||4.0.0 4.1.0 3.0.4
  Known to work||3.4.0 3.3.3
   Last reconfirmed|-00-00 00:00:00 |2005-04-19 13:08:31
   date||
Summary|Compiling of large array|[4.0/4.1 Regression]
   |fails   |Compiling of large array
   ||fails
   Target Milestone|--- |4.0.1


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

[Bug debug/21106] New: internal compiler error at dwarf2out.c:8362

[e9925248 at stud4 dot tuwien dot ac dot at]

The dwarf2 output for a type attribute for an array fails.
Eg:
$cat x.c
typedef unsigned char GROUP9_T[3];
typedef GROUP9_T EGROUP9_T __attribute ((eeprom));
$./cc1 --version
GNU C version 4.1.0 20050416 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.1.0 20050302 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
$./cc1 -g x.c
x.c:2: internal compiler error: in modified_type_die, at dwarf2out.c:8362
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

The eeprom attribute was defined in the following way:

[EMAIL PROTECTED]:/tmp/gcc/gcc]$cvs diff -u config/i386/i386.c
Index: config/i386/i386.c
===
RCS file: /cvs/gcc/gcc/gcc/config/i386/i386.c,v
retrieving revision 1.808
diff -u -r1.808 i386.c
--- config/i386/i386.c  12 Apr 2005 01:46:28 -  1.808
+++ config/i386/i386.c  16 Apr 2005 12:37:52 -
@@ -1608,9 +1608,19 @@
 #endif
 }


+
+static tree
+m68hc05_handle_eeprom_attribute (tree * node, tree name,
+tree args ATTRIBUTE_UNUSED,
+int flags ATTRIBUTE_UNUSED,
+bool * no_add_attrs)
+{
+  return NULL_TREE;
+}
 /* Table of valid machine attributes.  */
 const struct attribute_spec ix86_attribute_table[] =
 {
+  {"eeprom", 0, 0, false, true, false, m68hc05_handle_eeprom_attribute},
   /* { name, min_len, max_len, decl_req, type_req, fn_type_req, handler } */
   /* Stdcall attribute says callee is responsible for popping arguments
  if they are not variable.  */

James E Wilson said about the problem:
I debugged this a bit more. The situation seems to be this:
 1) We create a first array type when we parse the array decl in the first line
(build_array_type).
 2) We create a second array type when handling the typedef
(clone_underlying_type). This one gets TYPE_NAME set to the typedef, and
DECL_ORIGINAL_TYPE of the typedef points to the first one.
 3) We create a third array type when parsing the attributes. See the call to
build_type_attribute_variant in attribs.c. This is a complete copy, so it still
has the GROUP9_T TYPE_NAME.
 4) We create a fourth array type when handling the second typedef. This gets
the TYPE_NAME EGROUP9_T, and the typedef has DECL_ORIGINAL_TYPE set to point to
the third array type.
 
When we emit debug info, we emit debug info for the types used by the typedefs,
which are the second and fourth one. The debug info for the second one is OK.
The debug info for the fourth one runs into trouble. We follow
DECL_ORIGINAL_TYPE to get the third array type, and then we follow TYPE_NAME to
get the second array type, and then we notice that we already emitted debug info
for this type. After we return, we double check to make sure we have debug info
for this type, and fail, because this is not the same array type as we emitted
earlier.
 
I think the broken type is the 3rd one. I mentioned in an earlier message that
you had two types with the same TYPE_NAME which was wrong. This is happening in
build_type_attribute_variant. Clearing TYPE_NAME here seems to solve the
problem, though I haven't done any testing to see if this is safe.

Maybe a bug report to keep track of this info would be useful.

-- 
   Summary: internal compiler error at dwarf2out.c:8362
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: e9925248 at stud4 dot tuwien dot ac dot at
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug java/21022] ICE while compiling GdkFontMetrics.class with stabs debugging

[aph at gcc dot gnu dot org]

--- Additional Comments From aph at gcc dot gnu dot org  2005-04-19 13:26 
---
See http://gcc.gnu.org/ml/gcc/2005-04/msg01068.html


-- 


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

[Bug fortran/21104] Segmentation fault on correct code

[paulthomas2 at wanadoo dot fr]

--- Additional Comments From paulthomas2 at wanadoo dot fr  2005-04-19 
13:31 ---
Subject: Re:  Segmentation fault on correct code

>
> --- Additional Comments From pinskia at gcc dot gnu dot org 
> 2005-04-19 12:21 ---
> I don't think this is correct code.  See PR 20960.  Yes ICC does not seg 
> fault on it.  I will note that XLC
> does the same thing as gfortran.
>
I am not sure if it is correct or not; probably not - see below.  This PR, 
20960 and 18197 are clearly related - I did not find them because I looked 
in the summary for segmentation fault rather than bus error.

The difference with 20960 is that an interface for the function, in the 
subroutine, did not fix the problem.  At module level, the private 
declaration prohibits the interface.

> I also think this is a dup of bug 18197.

I agree.  I am just out of the door and on the road for a couple of days. 
As soon as I am back, I willl run these by the Digital compiler, with 
/strict set.  These usually sorts out the wolves in sheep's clothing. 




-- 


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

[Bug c++/17445] too few template-parameter-lists

[bangerth at dealii dot org]

--- Additional Comments From bangerth at dealii dot org  2005-04-19 14:08 
---
Why? This code as always wrong. It has nothing to do with gcc3.4.x. 
W. 

-- 


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

[Bug c/21107] New: internal compiler error: in expand_one_stack_var_at, at cfgexpand.c:476

[e9925248 at stud4 dot tuwien dot ac dot at]

If Pmode is smaller than the HOST_BITS_PER_WIDE_INT (ie for i686 as host all
targets, which use HImode or QImode as Pmode), a stack overflow produce the
following internal compiler error:

$./cc1 t4.c
 check1972

/homes/mkoegler/m68hc05/src/host-i686-pc-linux-gnu/gcc/test/t4.c: In function
'check1972':
/homes/mkoegler/m68hc05/src/host-i686-pc-linux-gnu/gcc/test/t4.c:7: internal
compiler error: in expand_one_stack_var_at, at cfgexpand.c:476
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
$cat t4.c
union S1972
{
  char b[24000];
};
void
check1972 ()
{
  union S1972 ret;
  union S1972 b1;
  union S1972 b2;
}

$./cc1 --version
GNU C version 4.1.0 20050416 (experimental) (avr)
compiled by GNU C version 4.1.0 20050302 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

-- 
   Summary: internal compiler error: in expand_one_stack_var_at, at
cfgexpand.c:476
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: e9925248 at stud4 dot tuwien dot ac dot at
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: avr-unknown-none


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

[Bug middle-end/21107] internal compiler error: in expand_one_stack_var_at, at cfgexpand.c:476

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-19 
14:47 ---
  /* If this fails, we've overflowed the stack frame.  Error nicely?  */
  gcc_assert (offset == trunc_int_for_mode (offset, Pmode));

Hmm, I wonder if this is a regression or not.

-- 
   What|Removed |Added

  Component|c   |middle-end
   Keywords||ice-on-invalid-code


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

[Bug libfortran/20970] gfortran - bus error -fdefault-integer-8

[fxcoudert at gcc dot gnu dot org]

--- Additional Comments From fxcoudert at gcc dot gnu dot org  2005-04-19 
14:53 ---
Confirmed on i386-linux.

Same thing happens without -fdefault-integer-8 on:
  character(len=6_8) hed, final
  data final /'foo'/
  data hed /'bar'/
  if (hed == final) call abort
  end

This happens with all character functions (like gfortran_copy_string, see PR
21083): using an integer(8) variable for the length of a string does not work.
We need a global fix for that.

-- 
   What|Removed |Added

   GCC host triplet|powerpc-apple-darwin7.8.0   |
   Last reconfirmed|2005-04-18 03:51:27 |2005-04-19 14:53:20
   date||


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

[Bug libfortran/21083] gfortran -fdefault-integer-8 segmentation fault

[fxcoudert at gcc dot gnu dot org]

--- Additional Comments From fxcoudert at gcc dot gnu dot org  2005-04-19 
14:53 ---
Exactly the same segfault happens without -fdefault-integer-8 on:
  character(len=8_8) a
  a = '12345678'
  end

Using a integer(8) as length for a string is broken, and that's why
-fdefault-integer-8 doesn't work here. Thus, this bug is a dup of 20970 (though
one is in gfortran_compare_string and the other is in gfortran_copy_string).

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

-- 
   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
  BugsThisDependsOn|20970   |
 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug libobjc/11572] [3.4 regression]: GNU libobjc no longer compiled on Darwin

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-19 
14:53 ---
I am no longer working on this.

-- 
   What|Removed |Added

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


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

[Bug libfortran/20970] gfortran - bus error -fdefault-integer-8

[fxcoudert at gcc dot gnu dot org]

--- Additional Comments From fxcoudert at gcc dot gnu dot org  2005-04-19 
14:53 ---
*** Bug 21083 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

OtherBugsDependingO|21083   |
  nThis||
 CC||edward dot e dot meyer at
   ||comcast dot net


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

[Bug rtl-optimization/13987] [3.4 Regression] compile time regression while compile fold-const.i

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-19 
14:54 ---
I am no longer working on this.

-- 
   What|Removed |Added

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


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

[Bug middle-end/21082] &a[b] - &a[c] is not folded to b - c

[phython at gcc dot gnu dot org]

--- Additional Comments From phython at gcc dot gnu dot org  2005-04-19 
14:57 ---
 Yup, the dumps from the c++ front end is:
;; Function size_t f(size_t, size_t) (_Z1fjj)

size_t f(size_t, size_t) (b, c)
{
:
  return (size_t) (((int) &a[b] - (int) &a[c]) /[ex] 4);

}

 and the C front-end dump is:
;; Function f (f)

f (b, c)
{
:
  return (size_t) (b - c);

}


-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-04-19 14:57:39
   date||


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

[Bug c++/21008] [3.4/4.0/4.1 Regression] Acess failure in accessing data member of base class from derived template class

[sebor at roguewave dot com]

--- Additional Comments From sebor at roguewave dot com  2005-04-19 15:39 
---
I discussed this with Mike Miller of EDG. His response to my query on the issue
(copied with his permission) is below.

Mike Miller wrote:
...
> There were a couple of different examples in that thread, 
> so just to avoid confusion, here's the one I'll refer to:
> 
> struct A {
>   int foo_;
> };
> template  struct B: public A { };
> template  struct C: B {
>   int foo() {
> return A::foo_;  // #1
>   }
> };
> 
> The question is how the reference on line #1 is treated. Wolfgang's 
> analysis isn't quite right.  While it's true that "A" is non-dependent 
> and thus is bound to ::A at template definition time, that is 
> irrelevant.  When C::foo() (for instance) is instantiated, it turns 
> out that the reference to ::A::foo_ is, in fact, a non-static member of 
> a base class (9.3.1p3), so the reference is transformed into 
> (*this).::A::foo_ and there is no error.  This is not a violation of 
> 14.6.2p3 -- there's no lookup in a dependent base class involved, as 
> Wolfgang's comments assume, and the description "the access is assumed 
> to be from the outside, not within the class hierarchy through this->" 
> doesn't accurately describe how 9.3.1p3 works.
> 
> In fact, though, this just sort of happens to work because A is both 
> visible in the definition context and a base class of the instantiated 
> template.  If you add an explicit specialization
> 
> template<> struct B { };
> 
> as suggested in Andrew's comment, so A is not a base class, or if you 
> change the program so that A is not visible in the definition context 
> (by making it a member of a namespace, for instance), we do report an 
> error in the instantiated C::foo().  (There's no requirement to 
> report errors in uninstantiated templates, of course, contrary to 
> Andrew's observation.)
> 
> This is sort of contrary to the "spirit" of two-stage lookup, though -- 
> Wolfgang's expectation is not unreasonable, I think, even though the 
> details of his reasoning are incorrect.  I'm probably going to open a 
> core issue on this, especially in light of the differences between 
> implementations.


-- 


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

[Bug c++/21008] [3.4/4.0/4.1 Regression] Acess failure in accessing data member of base class from derived template class

[sebor at roguewave dot com]

--- Additional Comments From sebor at roguewave dot com  2005-04-19 15:41 
---
Here's a followup email from Mike with some calarifying comments:

Mike Miller wrote:
> Martin Sebor wrote:
> 
>> Thanks a lot for the detailed analysis! I wonder if your reasoning
>> would be the same given a slightly different test case (one that's
>> closer to the original in comment #1):
>>
>>>
>>> struct A {
>>
>>
>>   protected: // <<< ADDED <<<
>>
>>>   int foo_;
>>> };
>>> template  struct B: public A { };
>>> template  struct C: B {
>>>   int foo() {
>>> return A::foo_;  // #1
>>>   }
>>> };
> 
> 
> No, I don't think that changes things.  Again, the situation is the 
> same: whether A is the global class or the injected-class-name doesn't 
> affect whether C (or whatever) has access to A::foo_.  (There are 
> cases where it does matter, but this isn't one of them.  Those typically 
> involve private or protected inheritance, where the access from 
> "outside" is greater than the inherited access.)
> 
> The general principle is that non-dependent names are looked up and 
> bound in the definition context (14.6.3), but that's really the only 
> semantic effect.  In cases like this one, it's as if "A" were replaced 
> by "::A".  If the result of using "::A" is well-formed, then the version 
> with just "A" is, too.
> 
>> But if an implementation is permitted to diagnose access violations
>> at definition time wouldn't the gcc compilation error be justified?
> 
> 
> I think the general rule is that you should only issue a diagnostic if 
> you can tell that no well-formed instantiation is possible (14.6p7).  In 
> these cases, at least some specializations will have well-formed 
> instantiations, so no diagnostic is permitted.

-- 


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

[Bug java/21022] ICE while compiling GdkFontMetrics.class with stabs debugging

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-19 
15:43 ---
Subject: Bug 21022

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

Modified files:
gcc: dbxout.c ChangeLog 

Log message:
2005-04-19  Andrew Haley  <[EMAIL PROTECTED]>

PR java/21022
* dbxout.c (dbxout_type_fields): Check DECL_IGNORED_P before
looking at a field's bitpos.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/dbxout.c.diff?cvsroot=gcc&r1=1.227&r2=1.228
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8361&r2=2.8362



-- 


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

[Bug middle-end/21018] Initializing string literal data improperly marked frame-relative?, should be readonly static const.

[ericw at evcohs dot com]

-- 
   What|Removed |Added

 CC||ericw at evcohs dot com


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

[Bug target/21078] Testsuite reports excecution failure for gcc.c-torture/excecute/20010122.c for some optimization levels

[ericw at evcohs dot com]

-- 
   What|Removed |Added

 CC||ericw at evcohs dot com


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

[Bug target/21079] avr-gcc lacks support for builtin ffs function

[ericw at evcohs dot com]

--- Additional Comments From ericw at evcohs dot com  2005-04-19 15:49 
---
Björn,

That sounds like a reasonable approach. Submit a bug report to the avr-libc
project on Savannah:


Eric

-- 
   What|Removed |Added

 CC||ericw at evcohs dot com


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

[Bug middle-end/21107] internal compiler error: in expand_one_stack_var_at, at cfgexpand.c:476

[ericw at evcohs dot com]

-- 
   What|Removed |Added

 CC||ericw at evcohs dot com


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

[Bug fortran/21104] Segmentation fault on correct code

[fxcoudert at gcc dot gnu dot org]

--- Additional Comments From fxcoudert at gcc dot gnu dot org  2005-04-19 
16:15 ---
Further reduced testcase:

module perdida_m
contains
  subroutine perdida (z, x)
real, dimension (:) :: x, z
z = generalized_hookes_law (x) + 1.0
  end subroutine perdida

  function generalized_hookes_law (x) result (z)
real, dimension (3) :: z, x
z = x
  end function generalized_hookes_law
end module perdida_m

program test
  use perdida_m
  real ::  x(3) = 42.0
  real ::  y(3)
  call perdida (y, x)
  print *, y
end


Lahey/Fujitsu Fortran 95 Source Check Output

Compiling program unit perdida_m at line 1:
Compiling program unit test at line 13:
Encountered 0 errors, 0 warnings, 0 informations in file SOURCE.F90.
Compiling file SOURCE.F90.

-- 


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

[Bug target/21097] __sync_bool_compare_and_swap doesn't work with -m32

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2005-04-19 16:21 
---
When, exactly, did you think that cmpxchg was added?  Use -march=i486.  Duh.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug target/21097] __sync_bool_compare_and_swap doesn't work with -m32

[hjl at lucon dot org]

--- Additional Comments From hjl at lucon dot org  2005-04-19 16:28 ---
But there is no __sync_bool_compare_and_swap_4 in source code.
If it isn't available, shouldn't gcc leave __sync_bool_compare_and_swap
alone.

-- 
   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug target/21069] [4.1 Regression] gcc.dg/ia64-sync-*.c execution tests fail

[rth at gcc dot gnu dot org]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rth at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-04-19 16:46:31
   date||


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

[Bug regression/20973] [4.0/4.1 Regression] kdelibs (khtml) miscompiled by reload

[matz at suse dot de]

--- Additional Comments From matz at suse dot de  2005-04-19 16:51 ---
I agree with most of what Jim said.  Except for the part that we maybe don't 
have to fix the reload issue, when we fix usage of the uninitialized register 
for piecewise struct initialization.  The latter will fix this particular 
instance of the problem, but reload still would be confused by uninitialized 
registers.  I think they can happen also for other reasons, like the user 
having some uninitialized variables, which perhaps never are used at runtime, 
but still could result in reload miscompiling the program the same way as  
seen here.  As reload bugs are particular hard to track down, I really think 
we should fix this one for good, that it doesn't come back biting us in the 
future. 
 
If agreed I will cleanup the patch to comment both locations (I don't think 
it would deserve an own subfunction). 

-- 


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

[Bug target/16888] [3.3/3.4/4.0/4.1 Regression] ICE: in print_reg, at config/i386/i386.c:7254

[aoliva at redhat dot com]

--- Additional Comments From aoliva at gcc dot gnu dot org  2005-04-19 
17:08 ---
Subject: [PR target/16888] clear reg names of unavailable regs

We used to crash at print_operand time, because the register asm
variable named a REX register, not available in 32-bit mode.

This patch arranges for us to clear the names of registers not
available for the given command-line options or defaults, which gets
us an error message at the point of the register var declaration.

An alternative would be to introduce a new target hook to validate
register names, but this didn't sound worth the effort.

Bootstrapped and regtested on amd64-linux-gnu.  Ok to install?

Index: gcc/ChangeLog
from  Alexandre Oliva  <[EMAIL PROTECTED]>
PR target/16888
* config/i386/i386.h (CONDITIONAL_REGISTER_USAGE): Clear reg names
for unavailable registers.

Index: gcc/config/i386/i386.h
===
RCS file: /cvs/gcc/gcc/gcc/config/i386/i386.h,v
retrieving revision 1.428
diff -u -p -r1.428 i386.h
--- gcc/config/i386/i386.h 14 Apr 2005 23:42:45 - 1.428
+++ gcc/config/i386/i386.h 19 Apr 2005 06:03:00 -
@@ -1042,14 +1042,14 @@ do {
\
int i;  \
 for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)\
   if (TEST_HARD_REG_BIT (reg_class_contents[(int)MMX_REGS], i))
\
-   fixed_regs[i] = call_used_regs[i] = 1;  \
+   fixed_regs[i] = call_used_regs[i] = 1, reg_names[i] = "";   \
   }
\
 if (! TARGET_SSE)  \
   {
\
int i;  \
 for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)\
   if (TEST_HARD_REG_BIT (reg_class_contents[(int)SSE_REGS], i))
\
-   fixed_regs[i] = call_used_regs[i] = 1;  \
+   fixed_regs[i] = call_used_regs[i] = 1, reg_names[i] = "";   \
   }
\
 if (! TARGET_80387 && ! TARGET_FLOAT_RETURNS_IN_80387) \
   {
\
@@ -1058,7 +1058,15 @@ do { 
\
 COPY_HARD_REG_SET (x, reg_class_contents[(int)FLOAT_REGS]);\
 for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)\
   if (TEST_HARD_REG_BIT (x, i))\
-   fixed_regs[i] = call_used_regs[i] = 1;  \
+   fixed_regs[i] = call_used_regs[i] = 1, reg_names[i] = "";   \
+  }
\
+if (! TARGET_64BIT)
\
+  {
\
+   int i;  \
+   for (i = FIRST_REX_INT_REG; i <= LAST_REX_INT_REG; i++) \
+ reg_names[i] = "";\
+   for (i = FIRST_REX_SSE_REG; i <= LAST_REX_SSE_REG; i++) \
+ reg_names[i] = "";\
   }
\
   } while (0)
 
Index: gcc/testsuite/ChangeLog
from  Alexandre Oliva  <[EMAIL PROTECTED]>

PR target/16888
* gcc.target/i386/asm-1.c: New test.

Index: gcc/testsuite/gcc.target/i386/asm-1.c
===
RCS file: gcc/testsuite/gcc.target/i386/asm-1.c
diff -N gcc/testsuite/gcc.target/i386/asm-1.c
--- /dev/null   1 Jan 1970 00:00:00 -
+++ gcc/testsuite/gcc.target/i386/asm-1.c 19 Apr 2005 06:03:15 -
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-options "-m32" } */
+
+register unsigned int EAX asm ("r14"); /* { dg-error "register name" } */
+
+void foo ()
+{
+  EAX = 0;
+}

-- 
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}


-- 


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

[Bug java/21022] ICE while compiling GdkFontMetrics.class with stabs debugging

[andreast at gcc dot gnu dot org]

--- Additional Comments From andreast at gcc dot gnu dot org  2005-04-19 
17:53 ---
Completed a build of HEAD with awt-gtk enabled on darwin7.9.

Thanks!

I run now a build on 4.0, even if we may not get this fix in for 4.0.

-- 


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

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

[law at redhat dot com]

--- Additional Comments From law at redhat dot com  2005-04-19 17:59 ---
An update.  The jump threading changes are blocked pending resolution of
a semi-latent bug in reload which is exposed by the combination of the
jump threading changes plus the recent merges from TCB.

I'm testing a patch which resolves the semi-latent bug and hope to remove
that blocker by COB today.

jeff

-- 


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

[Bug c++/21008] [3.4/4.0/4.1 Regression] Acess failure in accessing data member of base class from derived template class

[bangerth at dealii dot org]

--- Additional Comments From bangerth at dealii dot org  2005-04-19 18:25 
---
Martin & Mike, 
I'm happy to reopen this PR. I understand your analysis, and in fact thought 
about it when I wrote my comment. Independently of whether it may be strictly 
mandated by the standard, I do have to admit that I find it confusing to see 
the semantics of something change at the time of instantiation, even though 
it was already bound at template definition time. I do think that this is 
a further complication of the already not quite so intuitive two-stage 
name lookup rules. 
 
But I guess that's immaterial. We're not into intuitive things, but into 
the letter of the law. Some people in this country already claim that  
lawyers stray too far from the letter of the law anyway, so we won't give 
them more reason to complain. 
 
Incidentally, two question: 
a) your reference to 9.3.1p3 must have been to something else. In TC1,  
   9.3.1 is on const and volatile member functions. 
 
b) how does your interpretation affect the validity of the following program: 
-- 
struct A { 
int foo_; 
}; 
typedef int A::* pAi; 
 
template  struct B: public A { }; 
template  struct C: B { 
 pAi foo() { 
  return &A::foo_; 
} 
}; 
- 
If A::foo_ refers to the member variable *of the present object*, then  
taking its address returns an int*, not an "int A::*" object, right? However, 
I can't seem to find a compiler that would reject the code. 
 
Thanks 
  Wolfgang 
 
 

-- 
   What|Removed |Added

 CC||sebor at roguewave dot com,
   ||bangerth at dealii dot org
 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug debug/21022] [4.0 only] ICE while compiling GdkFontMetrics.class with stabs debugging

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|java|debug
Summary|ICE while compiling |[4.0 only] ICE while
   |GdkFontMetrics.class with   |compiling
   |stabs debugging |GdkFontMetrics.class with
   ||stabs debugging
   Target Milestone|--- |4.0.1


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

[Bug fortran/18452] -fno-second-underscore induces warning for fortran that needs preprocessing

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2005-04-19 18:34 
---
Probably the right way to solve this is to call the code in c-ppoutput.c from
the Fortran frontend.

-- 


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

[Bug fortran/18857] MATMUL failing with ALLOCATED matrices, unless base indices given

[tkoenig at gcc dot gnu dot org]

--- Additional Comments From tkoenig at gcc dot gnu dot org  2005-04-19 
18:51 ---
descriptor.offset (in the front end) aka descriptor->base
in the library is currently useless.

Look at this:

$ cat offset.f90
program main
  real :: a(2,2)
  real, allocatable :: b(:,:)
  real, pointer :: c(:,:)
  call foo(a)
  allocate(b(2,2),c(2,2))
  call foo(b)
  call foo(c)
contains
  subroutine foo(a)
real, dimension(:,:) :: a
a(1,1) = 1.0
  end subroutine foo
end program main
$ gfortran -fdump-tree-original offset.f90

>From the .original file:

foo (a)
{
  int4 ubound.0;
  int4 stride.1;
  int4 ubound.2;
  int4 stride.3;
  int4 offset.4;
  real4[0:] * a.0;

  {
int4 D.484;

D.484 = a->dim[0].stride;
stride.1 = D.484 == 0 ? 1 : D.484;
a.0 = (real4[0:] *) a->data;
ubound.0 = a->dim[0].ubound - a->dim[0].lbound + 1;
stride.3 = a->dim[1].stride;
ubound.2 = a->dim[1].ubound - a->dim[1].lbound + 1;
offset.4 = -stride.1 - NON_LVALUE_EXPR ;
  }
  (*a.0)[NON_LVALUE_EXPR  + NON_LVALUE_EXPR  + offset.4] =
1.0e+0;
}

You can see that offset.4 is calculated without a reference to a->offset.
This is a good thing, because the offset is only calculated correctly
for static arrays:

MAIN__ ()
{
  struct array2_real4 c;
  real4 a[4];
  struct array2_real4 b;
  static void foo (struct array2_real4 &);

  c.data = 0B;
  b.data = 0B;
  {
struct array2_real4 parm.5;

parm.5.dtype = 282;
parm.5.dim[0].lbound = 1;
parm.5.dim[0].ubound = 2;
parm.5.dim[0].stride = 1;
parm.5.dim[1].lbound = 1;
parm.5.dim[1].ubound = 2;
parm.5.dim[1].stride = 2;
parm.5.data = (real4[0:] *) (real4[0:] *) &a[0];
parm.5.offset = 0;
 ^^
 This is wrong.
foo (&parm.5);
  }

For allocated and pointer arrays, this is done correctly:
 {
real4[0:] * * D.504;

b.dtype = 282;
b.dim[0].lbound = 1;
b.dim[0].ubound = 2;
b.dim[0].stride = 1;
b.dim[1].lbound = 1;
b.dim[1].ubound = 2;
b.dim[1].stride = 2;
D.504 = &b.data;
_gfortran_allocate (D.504, 16, 0);
b.offset = -3;
 ^^^
 correct
  }
  {
real4[0:] * * D.505;

c.dtype = 282;
c.dim[0].lbound = 1;
c.dim[0].ubound = 2;
c.dim[0].stride = 1;
c.dim[1].lbound = 1;
c.dim[1].ubound = 2;
c.dim[1].stride = 2;
D.505 = &c.data;
_gfortran_allocate (D.505, 16, 0);
c.offset = -3;
 ^^
 correct
  }
  foo (&b);
  foo (&c);

The assert is therefore false and should be removed.

The question remains: What to do with the offset field?
Fix it in the front end for static arrays, or remove it
altogether?

-- 
   What|Removed |Added

 CC||Thomas dot Koenig at online
   ||dot de


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

[Bug fortran/21104] Segmentation fault on correct code

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-19 
19:23 ---
(In reply to comment #3)
> Further reduced testcase:
> Lahey/Fujitsu Fortran 95 Source Check Output

I think everyone should read 
 which David E. 
send me to show why PR 20960 was undefined/invalid code.

-- 


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

[Bug target/21097] __sync_bool_compare_and_swap doesn't work with -m32

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2005-04-19 19:34 
---
No, because __sync_bool_compare_and_swap is overloaded.
This expansion to __sync_bool_compare_and_swap_N is documented.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

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

[tsv at solvo dot ru]

--- Additional Comments From tsv at solvo dot ru  2005-04-19 19:38 ---
I was able to fix the problem by applying the following patch:
--- gcc-3.4.3-20050222/boehm-gc/include/private/gcconfig.h.orig 2005-04-19
19:40:06.0 +0400
+++ gcc-3.4.3-20050222/boehm-gc/include/private/gcconfig.h  2005-04-19
19:40:59.0 +0400
@@ -1514,7 +1514,7 @@
#   endif
#   ifdef LINUX
#   define OS_TYPE "LINUX"
-#   define STACKBOTTOM ((ptr_t) 0x12000)
+#   define LINUX_STACKBOTTOM
#   ifdef __ELF__
#define SEARCH_FOR_DATA_START
# define DYNAMIC_LOADING

My environment is:
gcc version 3.4.3 20050221 (Red Hat 3.4.3-20)
GNU ld version 2.15.94.0.2 20041220
glibc 2.3.4

Thank you

-- 


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

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

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-19 
19:40 ---
Then this is fixed for 3.4.4 and above by the following patch (which does the 
same):
2005-04-11  Richard Henderson  <[EMAIL PROTECTED]>

* include/private/gcconfig.h (alpha-linux): Use LINUX_STACKBOTTOM.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |3.4.4


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

[Bug java/21016] Indirect dispatch code generated when using -findirect-dispatch has wrong line numbers

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Keywords||wrong-debug


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

[Bug middle-end/21106] ICE at dwarf2out.c:8362 with type attributes and arrays

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|debug   |middle-end
   Keywords||ice-on-valid-code
Summary|internal compiler error at  |ICE at dwarf2out.c:8362 with
   |dwarf2out.c:8362|type attributes and arrays


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

[Bug target/21102] ICE: in immed_double_const, on SSE2 intrinsics

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Keywords||ice-on-valid-code, ssemmx


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

[Bug target/21101] ICE: could not find a spill register on MMX intrinsics

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Keywords||ice-on-valid-code, ssemmx


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

[Bug target/21100] [4.0/4.1 Regression] ICE: unrecognizable insn for -march=pentium-mmx

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Keywords|rejects-valid   |ice-on-valid-code, ssemmx


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

[Bug target/21099] ICE on mmx intrinsics

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Keywords||ice-on-valid-code, ssemmx


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

[Bug target/21098] [3.4/4.0 only] .note.GNU-stack emitted

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

Summary|.note.GNU-stack emitted |[3.4/4.0 only] .note.GNU-
   ||stack emitted
   Target Milestone|--- |4.0.0


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

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

[tsv at solvo dot ru]

--- Additional Comments From tsv at solvo dot ru  2005-04-19 19:57 ---
(In reply to comment #4)
> Then this is fixed for 3.4.4 and above by the following patch (which does the
same):
> 2005-04-11  Richard Henderson  <[EMAIL PROTECTED]>
> 
> * include/private/gcconfig.h (alpha-linux): Use LINUX_STACKBOTTOM.

Thank you much. Sorry I missed the patch from Richard.


-- 


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

[Bug tree-optimization/21030] [4.1 Regression] ICE in set_value_range building 176.gcc with -O2

[wanderer at rsu dot ru]

--- Additional Comments From wanderer at rsu dot ru  2005-04-19 20:08 
---
Proposed patch (in #4) work fine at FreeBSD 5.1

And fix my tescase variant:

__inline void f(int a)
{
  int i;

  if (a < 0) {
for (i = 0, a = ~a; a; i++) {
  if ((a & 1) != 0) {
f(i);
  }
}
  }
}

void g(void) { f(0); }

Without proposed patch i can't bootstrap LLVM using gcc CVS mainline.
bootstrap die at build of gcc version 3.4-llvm 20030924 (part of LLVM 
distribution):

gcc/haifa-sched.c:737: internal compiler error: in set_value_range, at tree-
vrp.c:124

Note: haifa-sched.c isn't modified.


-- 


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

[Bug driver/21055] Option -Wl,-wrap when no input file

[wilson at gcc dot gnu dot org]

--- Additional Comments From wilson at gcc dot gnu dot org  2005-04-19 
20:09 ---
This is due to an internal implementation detail.  The -Wl options are handled
by pretending that the argument to the -Wl option is an object file name.  This
works because the only thing we do with object file names on the command line is
to pass them to the linker.  Search gcc.c for "-Wl", and note that the code
increments n_infiles.  Once n_infiles has been incremented, it is impossible for
the gcc driver to tell whether or not the user has specified any input files.

This is clearer without the other arguments.
aretha$ gcc
gcc: no input files
aretha$ gcc -Wl,-wrap
/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/../../../../lib64/crt1.o(.text+0x21):
In function `_start':
../sysdeps/x86_64/elf/start.S:92: undefined reference to `main'
collect2: ld returned 1 exit status

The -Xlinker/-Xassembler/-Xpreprocessor options have the same problem.  

Incidentally, -Xassembler/-Xpreprocessor can't possibly work, as they aren't
supposed to be passing options to the linker.  It looks like they have never
worked.  The original patch from Apple has the same bug.  This probably deserves
another bug report.

-- 
   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug libfortran/21108] New: reshape with order causes memory corruption

[tkoenig at gcc dot gnu dot org]

... or so it seems.

This doesn't work:

$ cat reshape-2.f90
program resh
  real, dimension (0:1,0:2) :: a,c
  real, dimension (12) :: b
  b = (/(i,i=1,12)/)
  a = reshape(b(1:12:2),shape(a),order=(/2,1/))
  print '(6F8.3)',a
  c = reshape(b(1:12:2),shape(a),order=(/2,1/))
  print '(6F8.3)',c
end
$ gfortran reshape-2.f90
$ ./a.out
   0.000   0.000   0.000   2.029   2.027   2.025
  -2.000   2.022   0.000   2.166   0.000   0.000

This works:
$ cat reshape-2.f90
program resh
  real, dimension (0:1,0:2) :: a,c
  real, dimension (12) :: b
  b = (/(i,i=1,12)/)
  a = reshape(b(1:12:2),shape(a),order=(/2,1/))
  print '(6F8.3)',a
  c = reshape(b(1:12:2),shape(a),order=(/2,1/))
  print '(6F8.3)',c
end
$ gfortran reshape-2.f90
$ ./a.out
   0.000   0.000   0.000   2.029   2.027   2.025
  -2.000   2.022   0.000   2.166   0.000   0.000
$ gfortran -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1/configure --enable-languages=c,f95 
--prefix=/home/ig25
Thread model: posix
gcc version 4.1.0 20050419 (experimental)

Reshape is trickier than I thought, apparently.

-- 
   Summary: reshape with order causes memory corruption
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug bootstrap/21109] New: Symbol defined in discarded section

[schwab at suse dot de]

Current mainline fails to bootstrap with this error while linking libgcj.la:

`.L_ZN4java4util7logging6Logger7getNameEv13' referenced in section `.data.rel' 
of ./.libs/libgcj0_convenience.a(Logger.o): defined in discarded section 
`.gnu.linkonce.t._ZN4java4util7logging6Logger7getNameEv[java::util::logging::Logger::getName()]'
 of ./.libs/libgcj0_convenience.a(Logger.o)

-- 
   Summary: Symbol defined in discarded section
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P2
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schwab at suse dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: ia64-*-*


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

[Bug other/21110] New: incorrect documentat for high and lo_sum RTL operators

[wilson at gcc dot gnu dot org]

The documentation in rtl.texi for the HIGH and LO_SUM operators incorrectly say
that they should use Pmode.  There is no such restriction.  They can be used
with any mode.  Pmode is only necessary if the operand is an address, such as a
SYMBOL_REF or a LABEL_REF.  The text will need some rewording to make this 
clear.

-- 
   Summary: incorrect documentat for high and lo_sum RTL operators
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wilson at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug debug/21022] [4.0 only] ICE while compiling GdkFontMetrics.class with stabs debugging

[andreast at gcc dot gnu dot org]

--- Additional Comments From andreast at gcc dot gnu dot org  2005-04-19 
20:26 ---
Add on, a full bootstrap on 4.0 branch with the following config completed
successfully:

 /Volumes/src/gcc/gcc-4.0-branch/gcc/configure
--prefix=/Volumes/src/gcc/gcc-4.0-branch/testbin --enable-languages=c,c++,java
--enable-java-awt=gtk,xlib --enable-gtk-cairo --disable-checking
--enable-libgcj-multifile

[wolfram:gcc/gcc-4.0-branch/objdir] andreast% cat ../gcc/LAST_UPDATED 
Tue Apr 19 19:48:59 CEST 2005
Tue Apr 19 17:48:59 UTC 2005

And the dbxout patch from aph.

-- 


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

[Bug middle-end/21111] New: IA-64 NaT consumption faults due to uninitialized register reads

[wilson at gcc dot gnu dot org]

Because of the decomposition of structures in tree-ssa, the middle end is
emitting RTL code that can read uninitialized registers.  On IA-64, this can
result in a NaT consumption fault if the uninitialized register has its NaT bit 
set.

Before tree-ssa, we would have had a constructor, and store_constructor takes
pains to ensure that a register is initialized to zero before we start setting
fields in it.

Since we do not yet have speculation support in the IA-64 backend, this problem
will be very hard to trigger without a synthetic example.  There is some hand
written code in glibc that uses speculation, and hence can generate NaT bits. 
Also, there is code in the kernel that can generate NaT bits.

-- 
   Summary: IA-64 NaT consumption faults due to uninitialized
register reads
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wilson at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: ia64-linux


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

[Bug middle-end/21111] IA-64 NaT consumption faults due to uninitialized register reads

[wilson at gcc dot gnu dot org]

--- Additional Comments From wilson at gcc dot gnu dot org  2005-04-19 
20:41 ---
Created an attachment (id=8684)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8684&action=view)
synthetic IA-64 testcase to generate NaT consumption fault

Compile this with -O, and it will fail with gcc-2.96 and gcc-4.0.0.  We get an
illegal instruction signal.  It works with gcc-3.0 and gcc-3.3 and presumably
with every other gcc-3.x release.

If you use gcc-4.0.0 to compile with -O -S, and look at the assembly code, you
can see that r8 is being used uninitialized, which fails if r8 happens to have
the NaT bit set.

-- 


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

[Bug middle-end/21111] IA-64 NaT consumption faults due to uninitialized register reads

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-19 
20:47 ---
To me, the target specific code should be the one to fix this problem up and 
not the middle-end or at 
least have a hook for it so you don't mess around with other targets getting 
the speed up.  Anyways 
seems like someone thought it would be cool if they did this, oh well.

-- 


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

[Bug driver/21112] New: Xassebler and Xpreprocessor have never (?) worked

[wilson at gcc dot gnu dot org]

The Xassembler and Xpreprocessor options don't work.  They accidentally pass
options to the linker in addition to the assembler and preprocessor.

For example, on linux, the assembler ignores the -D option, but the linker does
not.  If I try using -Xassembler to pass the -D option to the assembler, I get a
linker error.
aretha$ ./xgcc -B./ -Xassembler -D tmp.c
/usr/bin/ld: unrecognized option '-D'
/usr/bin/ld: use the --help option for usage information
collect2: ld returned 1 exit status

Adding the -v option confirms that -D got passed to both the assembler and the
linker, which is wrong.

The -Xpreprocessor option has the same implementation as -Xassembler, and hence
the same problem.

-- 
   Summary: Xassebler and Xpreprocessor have never (?) worked
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wilson at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug driver/21112] [3.4/4.0/4.1 Regression] Xassebler and Xpreprocessor does not worked

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-19 
20:54 ---
Confirmed.  -Xassebler did not exist in 3.3.3 but -Xpreprocessor did and works 
as expected.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  Known to fail||3.4.0 4.0.0 4.1.0
  Known to work||3.3.3
   Last reconfirmed|-00-00 00:00:00 |2005-04-19 20:54:06
   date||
Summary|Xassebler and Xpreprocessor |[3.4/4.0/4.1 Regression]
   |have never (?) worked   |Xassebler and Xpreprocessor
   ||does not  worked
   Target Milestone|--- |3.4.4


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

[Bug bootstrap/21109] Symbol defined in discarded section

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-19 
20:57 ---


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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug java/21070] [4.1 Regression]: java compiler generates wrong code on ia64

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-19 
20:57 ---
*** Bug 21109 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||schwab at suse dot de


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

[Bug c++/21113] New: Jumps into VLA or VM scope not rejected for C++

[jsm28 at gcc dot gnu dot org]

Jumps into the scope of an identifier with variably modified type (with goto or
switch) are not rejected by the C++ front end.  Bug 12913 describes this problem
for C, but there should be a separate bug for C++ since bug 16989 only depends
on the issue being fixed for C and not for C++.  The examples in bug 12913 
apply:

void f(int l) { 
  goto label; 
  int a[l]; 
 label:; 
} 

void g (int l) {
  switch (l) {
  case 1:;
int a[l];
  default:;
  }
}

(and note that if we follow the C99 rules, which I think is the sensible thing
for the C++ front end to do, the same applies for identifiers of variably
modified type, e.g. int (*a)[l], not just VLAs: cases where the temporary
variable with the array size might not get initialized are all covered, not just
cases where memory for a VLA might not be allocated).

-- 
   Summary: Jumps into VLA or VM scope not rejected for C++
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
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=21113

[Bug preprocessor/20907] [4.0/4.1 Regression] long comments throw off line numbers

[bothner at gcc dot gnu dot org]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bothner at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-04-08 20:30:31 |2005-04-19 21:30:11
   date||


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

[Bug c++/21087] [4.0/4.1 Regression] ICE in do_nonmember_using_decl

[aoliva at redhat dot com]

--- Additional Comments From aoliva at gcc dot gnu dot org  2005-04-19 
21:45 ---
Subject: [PR c++/21087] don't keep builtin anticipated decl, override it with 
actual declaration

When push_overloaded_decl() was passed a new declaration that matches
a builtin decl, it would verify that the declarations matched and, if
so, leave the existing (built-in) declaration alone.

The intended behavior is to merge the built-in declaration with the
new declaration, into the location of the built-in declaration.

The problem is that duplicate_decl() doesn't perform such merging when
the new declaration is a template decl, and then we end up with an
overload involving the template decl and the anticipated built-in
decl.  However, overloads involving anticipated decls are something we
try to avoid, and actually check for elsewhere.

This patch fixes the code such that, if the existing decl is
anticipated and the two decls weren't merged, we discard the built-in
and use the new decl by itself.

Bootstrapped and regtested on amd64-linux-gnu.  Ok to install?

Index: gcc/cp/ChangeLog
from  Alexandre Oliva  <[EMAIL PROTECTED]>

PR c++/21087
* name-lookup.c (push_overloaded_decl): Do not overload with
non-duplicate anticipated built-in.

Index: gcc/cp/name-lookup.c
===
RCS file: /cvs/gcc/gcc/gcc/cp/name-lookup.c,v
retrieving revision 1.113
diff -u -p -r1.113 name-lookup.c
--- gcc/cp/name-lookup.c 14 Mar 2005 14:51:14 - 1.113
+++ gcc/cp/name-lookup.c 19 Apr 2005 19:20:11 -
@@ -1883,6 +1883,13 @@ push_overloaded_decl (tree decl, int fla
  if (duplicate_decls (decl, fn) == fn)
POP_TIMEVAR_AND_RETURN (TV_NAME_LOOKUP, fn);
}
+
+ /* We don't overload implicit built-ins.  duplicate_decls()
+may fail to merge the decls if the new decl is e.g. a
+template function.  */
+ if (TREE_CODE (old) == FUNCTION_DECL
+ && DECL_ANTICIPATED (old))
+   old = NULL;
}
   else if (old == error_mark_node)
/* Ignore the undefined symbol marker.  */
Index: gcc/testsuite/ChangeLog
from  Alexandre Oliva  <[EMAIL PROTECTED]>

PR c++/21087
* g++.dg/lookup/builtin2.C: New test.

Index: gcc/testsuite/g++.dg/lookup/builtin2.C
===
RCS file: gcc/testsuite/g++.dg/lookup/builtin2.C
diff -N gcc/testsuite/g++.dg/lookup/builtin2.C
--- /dev/null   1 Jan 1970 00:00:00 -
+++ gcc/testsuite/g++.dg/lookup/builtin2.C 19 Apr 2005 19:20:27 -
@@ -0,0 +1,19 @@
+/* { dg-do compile } */
+
+/* PR c++/21087 */
+
+/* We used to overload the template function with the built-in
+   declaration, instead of replacing it as we should, and then barf at
+   the using decl because of a test that none of the overload set
+   members were anticipated built-ins.  */
+
+extern "C" signed int toupper(signed int __c) throw();
+namespace std
+{
+  template< typename a > a toupper(a,int){}
+  using ::toupper;
+}
+
+int f () {
+  std::toupper((signed int)'a');
+}

-- 
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}


-- 


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

[Bug target/21114] New: gcc generated movaps instruction used on unaligned stack variable

[zwane at arm dot linux dot org dot uk]

In functions utilising varargs gcc generates the below prologue, which
unfortunately results in movaps operating on a non 16byte aligned memory
address. In this particular case we should either be ensuring alignment on the
stack variable, or using movups. I have reason to believe, from discussion on
#gcc that this bug may be present in mainline.

Thanks, Zwane


/usr/bin/gcc -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/3.4.2/include/
-Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common
-march=nocona -mno-red-zone -mcmodel=kernel -pipe -fno-reorder-blocks
-Wno-sign-compare -fno-asynchronous-unwind-tables -funit-at-a-time -DMODULE -O2
-c -o test.o test.c

int z_printf(int fd, const char * fmt, ...)
{
__asm__ __volatile__("nop");
return 0;
}

 :
   0:   48 81 ec b8 00 00 00sub$0xb8,%rsp
   7:   48 89 54 24 10  mov%rdx,0x10(%rsp)
   c:   0f b6 d0movzbl %al,%edx
   f:   48 89 4c 24 18  mov%rcx,0x18(%rsp)
  14:   48 8d 04 95 00 00 00lea0x0(,%rdx,4),%rax
  1b:   00
  1c:   48 c7 c2 00 00 00 00mov$0x0,%rdx
  23:   4c 89 44 24 20  mov%r8,0x20(%rsp)
  28:   48 29 c2sub%rax,%rdx
  2b:   48 8d 84 24 af 00 00lea0xaf(%rsp),%rax
  32:   00
  33:   4c 89 4c 24 28  mov%r9,0x28(%rsp)
  38:   ff e2   jmpq   *%edx
  3a:   0f 29 78 f1 movaps %xmm7,0xfff1(%rax)
  3e:   0f 29 70 e1 movaps %xmm6,0xffe1(%rax)
  42:   0f 29 68 d1 movaps %xmm5,0xffd1(%rax)
  46:   0f 29 60 c1 movaps %xmm4,0xffc1(%rax)
  4a:   0f 29 58 b1 movaps %xmm3,0xffb1(%rax)
  4e:   0f 29 50 a1 movaps %xmm2,0xffa1(%rax)
  52:   0f 29 48 91 movaps %xmm1,0xff91(%rax)
  56:   0f 29 40 81 movaps %xmm0,0xff81(%rax)
  5a:   90  nop
  5b:   31 c0   xor%eax,%eax
  5d:   48 81 c4 b8 00 00 00add$0xb8,%rsp
  64:   c3  retq

Giving us;
> -0xb8 + 0xa5 + -15
-34 [0xffde]

-- 
   Summary: gcc generated movaps instruction used on unaligned stack
variable
   Product: gcc
   Version: 3.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zwane at arm dot linux dot org dot uk
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: x86_64-redhat-linux
  GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux


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

[Bug c++/21113] Jumps into VLA or VM scope not rejected for C++

[pinskia at gcc dot gnu dot org]

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||accepts-invalid
   Last reconfirmed|-00-00 00:00:00 |2005-04-19 21:56:59
   date||


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

[Bug tree-optimization/21081] [4.1 Regression] internal compiler error: verify_stmts failed.

[f dot demiralp at gmail dot com]

--- Additional Comments From f dot demiralp at gmail dot com  2005-04-19 
22:14 ---
Subject: RE:  [4.1 Regression] internal compiler error: verify_stmts failed.



I updated gcc from the cvs repository today and I gave a try again.
but I still have got no luck. I have got the same error.

here is the version info of g++ I build today

$ g++ -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with:
/usr/cvs-src/gcc/configure --verbose --enable-languages=c,c++ --enable-nls -
-without-included-gettext --with-system-zlib --enable-interpreter --enable-t
hreads=posix --enable-sjlj-exceptions --disable-version-specific-runtime-lib
s --disable-win32-registry
Thread model: posix
gcc version 4.1.0 20050419 (experimental)


on the other hand I have tried to compile same file by the gcc that is
distributes with cygwin, I works.
the problem I report disappears.

here is the version info of g++ that is distributed with cygwin.

$ /bin/g++ -v
Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/specs
Configured with:
/gcc/gcc-3.3.3-3/configure --verbose --prefix=/usr --exec-prefix=/usr --sysc
onfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man 
--infodir=/usr/share/info --enable-languages=c,ada,c++,d,f77,java,objc,pasca
l --enable-nls --without-included-gettext --enable-libgcj --with-system-zlib
 --enable-interpreter --enable-threads=posix --enable-java-gc=boehm --enable
-sjlj-exceptions --disable-version-specific-runtime-libs --disable-win32-reg
istry
Thread model: posix
gcc version 3.3.3 (cygwin special)

I think I should not use experimental version of g++ with cygwin.

thank you very much anyway



-- 


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

[Bug java/21115] New: false boolean argument passed from pre-compiled to interpreted method is true

[mark at gcc dot gnu dot org]

This is reduced from the eclipse problem I was seeing.
Compile the following Test.java with gcj --main=Test Test.java

public abstract class Test
{
  public static void main(String[] args) throws Exception
  {
Class c = Class.forName("Invoke");
Object o = c.newInstance();
Test t = (Test) o;
t.test("FALSE", false);
t.test("TRUE", true);
  }

  public abstract boolean test(String s, boolean b);
}

Compile the Invoke.java class with gcj -C:

public class Invoke extends Test
{
  public boolean test(String s, boolean b)
  {
if (b)
  System.out.println(s + ": TRUE!");
else
  System.out.println(s + ": FALSE!");
return b;
  }
}

Then run the expected output is:

FALSE: FALSE!
TRUE: TRUE!

But when running ./a.out you will get:

FALSE: TRUE!
TRUE: TRUE!

Running this completely interpreted (gcj -C Test.java; gij Test) produces the
correct output. It also works correctly on powerpc-unknown-linux-gnu (either
partly pre-compiled or fully interpreted).

-- 
   Summary: false boolean argument passed from pre-compiled to
interpreted method is true
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mark at gcc dot gnu dot org
CC: aph at redhat dot com,gcc-bugs at gcc dot gnu dot
org,java-prs at gcc dot gnu dot org,tromey at redhat dot
com


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

[Bug tree-optimization/21116] New: tree-ssa-phiopt.c:193 has wrong translation from EDGE_COUNT to single_succ_p.

[kazu at cs dot umass dot edu]

http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-phiopt.c.diff?r1=2.25&r2=2.26&only_with_tag=MAIN

-  if (EDGE_COUNT (bb1->succs) > 1
+  if (!single_succ_p (bb1) > 1

We don't need "> 1".

-- 
   Summary: tree-ssa-phiopt.c:193 has wrong translation from
EDGE_COUNT to single_succ_p.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug java/21115] false boolean argument passed from pre-compiled to interpreted method is true

[daney at gcc dot gnu dot org]

--- Additional Comments From daney at gcc dot gnu dot org  2005-04-19 22:55 
---
Replacing Test.java with this seems to work:

import java.lang.reflect.*;

public abstract class Test
 {
   public static void main(String[] args) throws Exception
   {
 Class c = Class.forName("Invoke");
 Method m = c.getMethod ("test", new Class[]{String.class, Boolean.TYPE});
 Object o = c.newInstance();

 Object r = m.invoke(o, new Object[] {"FALSE", Boolean.FALSE});

 System.out.println("false == " + r);

 r = m.invoke(o, new Object[] {"TRUE", Boolean.TRUE});

 System.out.println("true == " + r);
   }
   public abstract boolean test(String s, boolean b);
 }

My tests were with 3.4.2 

-- 


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

[Bug tree-optimization/21116] tree-ssa-phiopt.c:193 has wrong translation from EDGE_COUNT to single_succ_p.

[kazu at cs dot umass dot edu]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |kazu at cs dot umass dot edu
   |dot org |
 Status|UNCONFIRMED |ASSIGNED


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

[Bug middle-end/21111] IA-64 NaT consumption faults due to uninitialized register reads

[wilson at specifixinc dot com]

--- Additional Comments From wilson at specifixinc dot com  2005-04-19 
23:05 ---
Subject: Re:  IA-64 NaT consumption faults due to uninitialized
 register reads

pinskia at gcc dot gnu dot org wrote:
> --- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-19 
> 20:47 ---
> To me, the target specific code should be the one to fix this problem up and 
> not the middle-end or at 
> least have a hook for it so you don't mess around with other targets getting 
> the speed up.  Anyways 
> seems like someone thought it would be cool if they did this, oh well.

The change I am suggesting should not hurt performance, and I expect 
that it would actually help performance in many cases.

Currently, the first assignment to a structure is a bitfield insert.

If we zero the structure before the first assignment, then combine will 
give us a simple assignment instead, which will be faster than a 
bitfield insert for most targets.  This may also allow other assignments 
to be combined in, giving further benefits.  (There can be multiple 
first assignments if there are multiple blocks where the structure 
becomes live.)

I agree that the optimizations being performed by tree-ssa are useful 
here, but one must not be confused by the big picture issues here into 
ignoring the details.  Emitting a bit-field insert when only a simple 
assignment is needed is wrong.  It may cause performance loss on many 
targets, and it causes core dumps on IA-64.

Take a look at this example.
struct s { unsigned long i : 32; unsigned long j : 32;};
int i;
struct s
sub (void)
{
   struct s foo;
   foo.i = i;
   return foo;
}
Compiling this for x86-64 on mainline, I get 10 instructions, which 
perform two bit-field insertions.  Compiling this with gcc-3.3, I get 7 
instructions which perform one bit-field insertion.

I think the optimal code is two instructions, one to load i into the low 
part of the return register, and one to return.  The upper bits of the 
structure are don't care bits, so we can set them to anything we want. 
There is no need for any bitfield insertion here at all.

Mainline does even worse than gcc-3 here because in order to decompose 
the structure it creates a fake j assignment, and then we end up 
emitting bitfield insertion code for the fake j assignment, even though 
this code is completely useless.  Furthermore, the RTL optimizer is not 
able to delete this fake j assignment, because it is a bitfield insert.


-- 


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

[Bug tree-optimization/21116] [4.1 Regression] tree-ssa-phiopt.c:193 has wrong translation from EDGE_COUNT to single_succ_p.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-19 
23:28 ---
This is a regression.

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
Summary|tree-ssa-phiopt.c:193 has   |[4.1 Regression] tree-ssa-
   |wrong translation from  |phiopt.c:193 has wrong
   |EDGE_COUNT to single_succ_p.|translation from EDGE_COUNT
   ||to single_succ_p.
   Target Milestone|--- |4.1.0
Version|unknown |4.1.0


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

[Bug libgcj/21115] false boolean argument passed from pre-compiled to interpreted method is true

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-19 
23:35 ---
I want to say this is libffi bug as other have pointed out on #gcj.

-- 
   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
  Component|java|libgcj


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

[Bug tree-optimization/21081] [4.1 Regression] internal compiler error: verify_stmts failed.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-19 
23:48 ---
Ok, I can reproduce this with a cross compiler, reducing.

-- 


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

[Bug c/12913] Jumps into variable length array scope not rejected

[jsm28 at gcc dot gnu dot org]

--- Additional Comments From jsm28 at gcc dot gnu dot org  2005-04-19 23:53 
---
Testing a fix.  Note that the first case is a regression in 4.0 relative to
previous releases, so I'll propose the fix for 4.0.1.


-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jsm28 at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-04-07 08:06:31 |2005-04-19 23:53:18
   date||
   Target Milestone|--- |4.0.1


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

[Bug tree-optimization/21081] [4.1 Regression] internal compiler error: verify_stmts failed.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-20 
00:08 ---
Do you know if this also works with the 4.0 branch?

Reduced testcase:
class wxString;

extern __attribute__((dllimport)) char* wxEmptyString;

struct wxString {};

inline wxString& wxGetEmptyString()
{
return *(wxString *)&wxEmptyString;
}
wxString GetHeader()
{
return wxGetEmptyString();
}

This is very target dependent as the __attribute__ is which is causing the 
problem.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2005-04-20 00:08:40
   date||


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