[Bug middle-end/39958] [4.5 Regression] OMP tasking creates invalid gimple

[reichelt at gcc dot gnu dot org]

--- Comment #1 from reichelt at gcc dot gnu dot org  2009-05-06 06:59 
---
Confirmed. Simple testcase (just compile with -fopenmp:

=
void foo(int n)
{
  int x[n];

  #pragma omp parallel private(x)
x[0] = 0;
}
=

Only the C++ frontend seems to be affected, not the C frontend.


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||reichelt at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code, openmp
   Last reconfirmed|-00-00 00:00:00 |2009-05-06 06:59:43
   date||


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

[Bug ada/38874] gnatmake doesn't pass through --param options

[laurent at guerby dot net]

--- Comment #4 from laurent at guerby dot net  2009-05-06 07:07 ---
The form "--param varname=value" is still not supported so I'm leaving this Pr
open.


-- 


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

[Bug fortran/40037] New: gfortran -O3 optimization generates code that seg faults on unaligned array data

[mick at nag dot co dot uk]

The program below compiled with gfortran 4.4.0 (and 4.3.2) and using the
-O3 optimization flag generates, in subroutine SMALL, sse instructions
which assume that the data array C is aligned on a 16 byte boundary.
For example:  mulpd  (%rax,%rcx,1),%xmm0
where register %rax may not be 16-byte aligned.

This leads to a segmentation violation at run time.

The test program deliberately forces array C to be unaligned before
being passed to subroutine SMALL. In a real situation one would
not do this, of course, but when the memory holding array C comes from
somewhere else (e.g. a program written in a different language) there
is no guarantee of alignment.

gfortran version 4.2.0 did not display this problem - the code
generated for SMALL did not assume alignment.

C Declare a REAL array as workspace. We pass it to a routine
C expecting a DOUBLE PRECISION array. This allows us to pass
C data aligned or not aligned on a 16 byte boundary.
  real c(100)
  integer m
  external tt
  m = 2
C Call tt with array C aligned on 16 byte boundary
  call tt(m, c(1))
C Call tt with array C not aligned on 16 byte boundary
  call tt(m, c(2))
  end

  subroutine tt(m, c)
  double precision c(m,m)
  external small
  do i = 1, m
 do j = 1, m
c(i,j) = 1.0d0
 end do
  end do
  call small(m, c)
  write (*,*) 'After call small(m, c), c(1,1) = ', c(1,1)
  end

  subroutine small(m, c)
  integer  m
  double precision c(m,*)
  integer  i
  do 70, i = 1, m
 c(i,1) = c(i,1) + c(i,1)
  70  continue
  return
  end

Here's the output from the -v flag of the compiler:

% gfortran -v -O3 align.f
Driving: gfortran -v -O3 align.f -lgfortranbegin -lgfortran -lm -shared-libgcc
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /opt/gcc-4.4.0-build/gcc-4.4.0/configure
--enable-languages=c,fortran,c++ --prefix=/opt/gcc-4.4.0
--with-mpfr=/opt/mpfr-2.4.1 --with-gmp=/opt/gmp-4.1.4
Thread model: posix
gcc version 4.4.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-O3' '-shared-libgcc' '-mtune=generic'
 /opt/gcc-4.4.0/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/f951 align.f
-ffixed-form -quiet -dumpbase align.f -mtune=generic -auxbase align -O3
-version -fintrinsic-modules-path
/opt/gcc-4.4.0/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/finclude -o
/tmp/cc9eHSWv.s
GNU Fortran (GCC) version 4.4.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.4.0, GMP version 4.1.4, MPFR version 2.4.1.
warning: GMP header version 4.1.4 differs from library version 4.2.
warning: MPFR header version 2.4.1 differs from library version 2.2.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
COLLECT_GCC_OPTIONS='-v' '-O3' '-shared-libgcc' '-mtune=generic'
 as -V -Qy -o /tmp/cc05mKcU.o /tmp/cc9eHSWv.s
GNU assembler version 2.19 (x86_64-unknown-linux-gnu) using BFD version (GNU
Binutils) 2.19
COMPILER_PATH=/opt/gcc-4.4.0/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/:/opt/gcc-4.4.0/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/:/opt/gcc-4.4.0/libexec/gcc/x86_64-unknown-linux-gnu/:/opt/gcc-4.4.0/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/:/opt/gcc-4.4.0/lib/gcc/x86_64-unknown-linux-gnu/
LIBRARY_PATH=/opt/gcc-4.4.0/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/:/opt/gcc-4.4.0/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/opt/gcc-4.4.0/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-O3' '-shared-libgcc' '-mtune=generic'
 /opt/gcc-4.4.0/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/collect2
--eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2
/usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o
/opt/gcc-4.4.0/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/crtbegin.o
-L/opt/gcc-4.4.0/lib/gcc/x86_64-unknown-linux-gnu/4.4.0
-L/opt/gcc-4.4.0/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/opt/gcc-4.4.0/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../..
/tmp/cc05mKcU.o -lgfortranbegin -lgfortran -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/opt/gcc-4.4.0/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/crtend.o
/usr/lib/../lib64/crtn.o


-- 
   Summary: gfortran -O3 optimization generates code that seg faults
on unaligned array data
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mick at nag dot co dot uk
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug libstdc++/40038] New: [4.4/4.5 regression] symbols ce...@glibcxx_3.4.3 and ta...@glibcxx_3.4 not exported

[debian-gcc at lists dot debian dot org]

seen in

https://buildd.debian.org/fetch.cgi?&pkg=gcc-4.4&ver=4.4.0-3&arch=mips&stamp=1241547561&file=log

PR26926 mentions these exports as unnecessary, but afaiu these are not supposed
to be removed in libstdc++.so.6.

  Matthias


-- 
   Summary: [4.4/4.5 regression] symbols ce...@glibcxx_3.4.3 and
ta...@glibcxx_3.4 not exported
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
GCC target triplet: mips-linux-gnu mipsel-linux-gnu


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

[Bug middle-end/40029] [4.5 Regression] Big degradation on swim/mgrid on powerpc 32/64 after alias improvement merge (gcc r145494)

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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

[Bug target/40031] [4.5 Regression] ARM broken with addresses in PHIs with -fPIC

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-05-06 08:28 ---
What's the ICE?


-- 


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

[Bug middle-end/40022] [4.4 Regression] Alpine miscompilation

[rguenth at gcc dot gnu dot org]

--- Comment #13 from rguenth at gcc dot gnu dot org  2009-05-06 08:32 
---
Fixed now.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to fail||4.4.0
  Known to work|4.5.0   |4.4.1 4.5.0
 Resolution||FIXED


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

[Bug middle-end/40022] [4.4 Regression] Alpine miscompilation

[rguenth at gcc dot gnu dot org]

--- Comment #14 from rguenth at gcc dot gnu dot org  2009-05-06 08:33 
---
Subject: Bug 40022

Author: rguenth
Date: Wed May  6 08:32:24 2009
New Revision: 147153

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147153
Log:
2009-05-06  Richard Guenther  

PR tree-optimization/40022
* tree-ssa-phiprop.c (phivn_valid_p): Fix tuplification error.

* gcc.c-torture/execute/pr40022.c: New testcase.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr40022.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/gcc/tree-ssa-phiprop.c


-- 


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

[Bug fortran/40037] gfortran -O3 optimization generates code that seg faults on unaligned array data

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-05-06 08:34 ---
I think this is not a valid Fortran program.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/40037] gfortran -O3 optimization generates code that seg faults on unaligned array data

[mick at nag dot co dot uk]

--- Comment #2 from mick at nag dot co dot uk  2009-05-06 08:45 ---
(In reply to comment #1)
> I think this is not a valid Fortran program.
> 

The main program is illegal because it passes a REAL array argument
to a subroutine expecting DOUBLE PRECISION array. However, the subroutine
SMALL is not illegal, but causes bad code to be generated. The main
program is only present for easy demonstration of the bug in SMALL.

Mick Pont


-- 

mick at nag dot co dot uk changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug target/40031] [4.5 Regression] ARM broken with addresses in PHIs with -fPIC

[ramana at gcc dot gnu dot org]

--- Comment #2 from ramana at gcc dot gnu dot org  2009-05-06 08:46 ---
Can't replicate this with a stage2 or stage3 compiler with O2, O3, Os -fPIC
{-mthumb} with r147121. 

However while bootstrapping the above mentioned revision, I get a segfault as
in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39929#c12 but with . 

ram...@gcc55:~/build-20090505/armv5tel-unknown-linux-gnueabi/libstdc++-v3/libsupc++\ram...@gcc55
~/build-20090505/armv5tel-unknown-linux-gnueabi/libstdc++-v3/libsupc++ $
gdb --args  /home/ramana/build-20090505/./gcc/cc1 -quiet -v -I..
-I/home/ramana/trunk/libstdc++-v3/../libiberty
-I/home/ramana/trunk/libstdc++-v3/../include
-I/home/ramana/build-20090505/armv5tel-unknown-linux-gnueabi/libstdc++-v3/include/armv5tel-unknown-linux-gnueabi
-I/home/ramana/build-20090505/armv5tel-unknown-linux-gnuea 
bi/libstdc++-v3/include -I/home/ramana/trunk/libstdc++-v3/libsupc++ -iprefix
/home/ramana/build-20090505/gcc/../lib/gcc/armv5tel-unknown-linux-gnueabi/4.5.0/
-isystem /home/ramana/build-20090505/./gcc/include -isystem
/home/ramana/build-20090505/./gcc/include-fixed -DHAVE_CONFIG_H -DIN_GLIBCPP_V3
-DPIC -isystem /usr/local/armv5tel-unknown-linux-gnueabi/include -isystem
/usr/local/armv5tel-unknown-linux-gnueabi/sys-include cp-demangle.c -quiet
-dumpbase cp-demangle.c -auxbase-strip cp-demangle.o -g -O2 -Wno-error -version
-fPIC -o /tmp/ccIO2OGk.s


(gdb) r

Starting program: /home/ramana/build-20090505/gcc/cc1 -quiet -v -I..
-I/home/ramana/trunk/libstdc++-v3/../libiberty
-I/home/ramana/trunk/libstdc++-v3/../include
-I/home/ramana/build-20090505/armv5tel-unknown-linux-gnueabi/libstdc++-v3/include/armv5tel-unknown-linux-gnueabi
-I/home/ramana/build-20090505/armv5tel-unknown-linux-gnueabi/libstdc++-v3/include
-I/home/ramana/trunk/libstdc++-v3/libsupc++ -iprefix
/home/ramana/build-20090505/gcc/../lib/gcc/armv5tel-unknown-linux-gnueabi/4.5.0/
-isystem /home/ramana/build-20090505/./gcc/include -isystem
/home/ramana/build-20090505/./gcc/include-fixed -DHAVE_CONFIG_H -DIN_GLIBCPP_V3
-DPIC -isystem /usr/local/armv5tel-unknown-linux-gnueabi/include -isystem
/usr/local/armv5tel-unknown-linux-gnueabi/sys-include cp-demangle.c -quiet
-dumpbase cp-demangle.c -auxbase-strip cp-demangle.o -g -O2 -Wno-error -version
-fPIC -o /tmp/ccIO2OGk.s

GNU C (GCC) version 4.5.0 20090505 (experimental) [trunk revision 147121]
(armv5tel-unknown-linux-gnueabi)

compiled by GNU C version 4.5.0 20090505 (experimental) [trunk revision
147121], GMP version 4.2.4, MPFR version 2.3.2.

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096


Program received signal SIGSEGV, Segmentation fault.
emit_insn_after_1 (first=0x403790f0, after=0x40588f50, bb=0xa5a5a5a5) at
../../trunk/gcc/emit-rtl.c:4129
4129  if (BB_END (bb) == after)
(gdb) bt
#0  emit_insn_after_1 (first=0x403790f0, after=0x40588f50, bb=0xa5a5a5a5) at
../../trunk/gcc/emit-rtl.c:4129
#1  0x0053cc60 in legitimize_pic_address (orig=0x40595b80, mode=, reg=0x0) at ../../trunk/gcc/config/arm/arm.c:3600
#2  0x00602060 in gen_movsi (operand0=0x0, operand1=) at
../../trunk/gcc/config/arm/arm.md:4966
#3  0x001e72c0 in emit_move_insn_1 (x=0x40706d38, y=0x40595b80) at
../../trunk/gcc/expr.c:3337
#4  0x001e756c in emit_move_insn (x=0x40706d38, y=0x40595b80) at
../../trunk/gcc/expr.c:3425
#5  0x001c3a60 in force_reg (mode=SImode, x=0x40595b80) at
../../trunk/gcc/explow.c:663
#6  0x001c4a90 in use_anchored_address (x=0x403d8350) at
../../trunk/gcc/explow.c:583
#7  0x001dd558 in expand_expr_real_1 (exp=0x404a8b40, target=, tmode=, modifier=, alt_rtl=0x0)
at ../../trunk/gcc/expr.c:7329
#8  0x001e6110 in expand_expr_real (exp=0x404a8b40, target=0x40588f50,
tmode=VOIDmode, modifier=EXPAND_WRITE, alt_rtl=0x0) at
../../trunk/gcc/expr.c:7114
#9  0x001ea070 in expand_expr_addr_expr_1 (exp=0x404a8b40, target=0x0,
tmode=SImode, modifier=EXPAND_NORMAL) at ../../trunk/gcc/expr.h:539
#10 0x001e9e14 in expand_expr_addr_expr_1 (exp=0x405fb690, target=0x40706630,
tmode=SImode, modifier=EXPAND_NORMAL) at ../../trunk/gcc/expr.c:6838
#11 0x001db5d4 in expand_expr_real_1 (exp=0x405c1fc0, target=0x40706630,
tmode=, modifier=, alt_rtl=0x0) at
../../trunk/gcc/expr.c:6897
#12 0x001e6110 in expand_expr_real (exp=0x405c1fc0, target=0x40588f50,
tmode=VOIDmode, modifier=EXPAND_WRITE, alt_rtl=0x0) at
../../trunk/gcc/expr.c:7114
#13 0x0072be90 in eliminate_phi (e=0x405fb900, g=0xa39f08) at
../../trunk/gcc/expr.h:539
#14 0x0072cb6c in expand_phi_nodes (sa=) at
../../trunk/gcc/tree-outof-ssa.c:777
#15 0x006b4800 in gimple_expand_cfg () at ../../trunk/gcc/cfgexpand.c:2506
#16 0x002fcdf0 in execute_one_pass (pass=0x95dcfc) at
../../trunk/gcc/passes.c:1291
#17 0x002fd07c in execute_pass_list (pass=0x95dcfc) at
../../trunk/gcc/passes.c:1340
#18 0x003fa1e0 in tree_rest_of_compilation (fndecl=0x403cc580) at
../../trunk/gcc/tree-optimize.c:394
#19 0x0054e584 in cgraph_expand_function (node=0x4047cf00) at
../../trunk/gcc/cgraphunit.c:1051
#20 0x0055059c in cgraph

[Bug fortran/40039] New: Procedures as actual arguments: Check intent of arguments

[janus at gcc dot gnu dot org]

Consider the following module:


module m

contains

subroutine a(x,f)
  real :: x
  interface
real function f(y)
  real,intent(in) :: y
end function
  end interface
  print *,f(x)
end subroutine

real function func(z)
  real,intent(inout) :: z
  func = z**2
end function

subroutine caller
  call a(4.3,func)
end subroutine

end module 


ifort complains:
error #7061: The characteristics of dummy argument 1 of the associated actual
procedure differ from the characteristics of dummy argument 1 of the dummy
procedure. (12.2)   [FUNC]
  call a(4.3,func)

Although gfortran, g95 and sunf95 accept it, I think ifort is right to reject
it (but I haven't checked the standard yet). The same check should also be
applied to procedure pointer assignments.

Btw "gfortran -Wall -Wextra" produces this warning:
test.f90:5: warning: unused parameter ‘f’
This is bogus, because 'f' *is* used in the subroutine a.


-- 
   Summary: Procedures as actual arguments: Check intent of
arguments
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janus at gcc dot gnu dot org


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

[Bug middle-end/40021] [4.5 Regression] Revision 146817 miscompiled DAXPY in BLAS

[matz at gcc dot gnu dot org]

--- Comment #10 from matz at gcc dot gnu dot org  2009-05-06 09:01 ---
Yes, I'll clean this up before submission.  Did it help?


-- 


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

[Bug libstdc++/40038] [4.4/4.5 regression] symbols ce...@glibcxx_3.4.3 and ta...@glibcxx_3.4 not exported

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2009-05-06 09:17 
---
Is this related to PR39491?


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||bkoz at redhat dot com


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

[Bug fortran/40037] gfortran -O3 optimization generates code that seg faults on unaligned array data

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2009-05-06 09:18 ---
The code generated for SMALL is correct, any caller that passes argument not
aligned on 8 byte boundary (you are mistaken that it requires 16 byte
alignment,
try calling it with c(3) which is 8 byte aligned, but not 16 byte aligned and
it will work too) is invalid.  All DOUBLE PRECISION variables/arrays must be
properly aligned on 8 byte boundaries.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug libstdc++/39491] [4.3 regression] symbol __signb...@glibcxx_3.4 in libstdc++ exported

[paolo dot carlini at oracle dot com]

--- Comment #34 from paolo dot carlini at oracle dot com  2009-05-06 09:19 
---
Removing 4.2 regression, branch no longer maintained.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

Summary|[4.2/4.3 regression] symbol |[4.3 regression] symbol
   |__signb...@glibcxx_3.4 in   |__signb...@glibcxx_3.4 in
   |libstdc++  exported |libstdc++  exported


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

[Bug tree-optimization/33928] [4.3/4.4/4.5 Regression] 30% performance slowdown in floating-point code caused by r118475

[bonzini at gnu dot org]

--- Comment #55 from bonzini at gnu dot org  2009-05-06 09:20 ---
Created an attachment (id=17807)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17807&action=view)
svn diff of cse.c to "fix" the performance regression (updated)


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

  Attachment #17805|0   |1
is obsolete||


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

[Bug debug/40040] New: gfortran invalid DW_AT_location for overridable variables

[jan dot kratochvil at redhat dot com]

Variables in Fortran modules compiled in -fPIC shared libraries will get unique
address by a copy relocation to the main executable.  Still .debug_info of the
library contains absolute DW_AT_location of the variable - without any
indirection through the GOT vector.

Debugger will then print the variable location not in active use.  Current FSF
GDB cannot resolve these variables but it was found by a new patch for modules:
http://sourceware.org/gdb/wiki/ArcherBranchManagement
archer-jankratochvil-fortran-module

Assuming no DW_AT_location should exist for such variables.  DW_AT_declaration
should be present there as such variables are NOT optimized-out.  Or
DW_AT_location using DW_FORM_block* indirecting GOT could be present?

For C the problem does not happen with GCC as it will put there _two_ DIEs and
the first one is just a declaration.  Current FSF GDB ignores any non-first
DIEs for a named object.  Still the second invalid DIE is redundant + invalid
even in the C case.

GNU Fortran (GCC) 4.4.0 20090427 (Red Hat 4.4.0-3)
GNU Fortran (GCC) 4.5.0 20090501 (experimental)

--

cat >lib.f90 : Abbrev Number: 2 (DW_TAG_module)
<2e>   DW_AT_name: lib
 <2><38>: Abbrev Number: 3 (DW_TAG_variable)
<39>   DW_AT_name: var
<3f>   DW_AT_type: <0x4f>
<43>   DW_AT_external: 1
<44>   DW_AT_location: 9 byte block: 3 98 7 20 0 0 0 0 0   
(DW_OP_addr: 200798)
 invalid DW_AT_location

$ readelf -wi main | approx-grep var
 <1><2d>: Abbrev Number: 2 (DW_TAG_subprogram)
<2f>   DW_AT_name: (indirect string, offset: 0x9): MAIN__
 <2><50>: Abbrev Number: 4 (DW_TAG_imported_module)
<53>   DW_AT_import  : <0x58>   [Abbrev Number: 5 (DW_TAG_module)]
 <1><58>: Abbrev Number: 5 (DW_TAG_module)
<59>   DW_AT_name: lib
<5d>   DW_AT_declaration : 1


cat >clib.c : Abbrev Number: 4 (DW_TAG_variable)
<56>   DW_AT_name: var
<5c>   DW_AT_type: <0x4e>
<60>   DW_AT_external: 1
<61>   DW_AT_declaration : 1
 <1><62>: Abbrev Number: 5 (DW_TAG_variable)
 redundant+invalid DIE
<63>   DW_AT_name: var
<69>   DW_AT_type: <0x4e>
<6d>   DW_AT_external: 1
<6e>   DW_AT_location: 9 byte block: 3 0 8 20 0 0 0 0 0
(DW_OP_addr: 200800)
 invalid DW_AT_location


-- 
   Summary: gfortran invalid DW_AT_location for overridable
variables
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug fortran/40041] New: spurious warning with INTRINSIC statement

[dfranke at gcc dot gnu dot org]

(see also: http://gcc.gnu.org/ml/fortran/2009-05/msg00068.html)

$> cat foo.f
  INTRINSIC   ABS, MAX
  a(n) = MAX(ABS(2),ABS(3),n)
  END

$> gfortran-svn -Wall -Wextra foo.f
foo.f:1.21:

  INTRINSIC   ABS, MAX
 1
Warning: Type specified for intrinsic function 'abs' at (1) is ignored
foo.f:1.26:

  INTRINSIC   ABS, MAX
  1
Warning: Type specified for intrinsic function 'max' at (1) is ignored


The same warnings are given if the arguments of ABS/MAX are of default-real
kind, so this not related to implicit typing.


-- 
   Summary: spurious warning with INTRINSIC statement
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dfranke at gcc dot gnu dot org


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

[Bug tree-optimization/33928] [4.3/4.4/4.5 Regression] 30% performance slowdown in floating-point code caused by r118475

[bonzini at gnu dot org]

--- Comment #56 from bonzini at gnu dot org  2009-05-06 09:31 ---
Created an attachment (id=17808)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17808&action=view)
usable testcase

Ok, I managed to make a reasonably readable source code (uninclude stdlib
files, remove unused gambit stuff and ___ prefixes, simplify some expressions),
find the heavy loops, annotate them with asm statements (see comment #18,
2007-11-30) and find the length of the loops.

   4.2  4.5 4.5 + patch
LOOP 1~190 ~230~190
INNER LOOP 1.1~120 ~130~120
LOOP 2 33   36  31

I am thus obsoleting (almost) everything that was posted and is not relevant
anymore.  Let's start from scratch with the new testcase.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

  Attachment #14418|0   |1
is obsolete||
  Attachment #14423|0   |1
is obsolete||
  Attachment #14424|0   |1
is obsolete||
  Attachment #14425|0   |1
is obsolete||
  Attachment #14426|0   |1
is obsolete||
  Attachment #14534|0   |1
is obsolete||
  Attachment #14535|0   |1
is obsolete||
  Attachment #14536|0   |1
is obsolete||
  Attachment #14997|0   |1
is obsolete||


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

[Bug middle-end/39954] [4.5 Regression] Revision 146817 caused unaligned access in gcc.dg/torture/pr26565.c

[matz at gcc dot gnu dot org]

--- Comment #14 from matz at gcc dot gnu dot org  2009-05-06 09:48 ---
Mark, I'm certainly willing to help fixing this, but it's not a new
regression.  Before my change TER _sometimes_ worked around the pre-existing
problem, but it's trivial to construct a case exposing it also before
expand from SSA:

void * send_probe(struct outdata *outdata, struct timeval *tp)
{
memcpy(&outdata->tv, tp, sizeof outdata->tv);
return &outdata->tv;
}

(or having more than one reference to &outdata->tv in some other way).

gcc 4.3, 4.4 and trunk before expand from SSA will emit unaligned accesses
here.  I haven't checked older ones, but the problem exists since introduction
of SSA (and TER in its current form).


-- 


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

[Bug tree-optimization/33928] [4.3/4.4/4.5 Regression] 30% performance slowdown in floating-point code caused by r118475

[jakub at gcc dot gnu dot org]

--- Comment #57 from jakub at gcc dot gnu dot org  2009-05-06 09:49 ---
Why do you need any #include lines at all in the reduced testcase?  Compiles
just fine even without them...


-- 


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

[Bug tree-optimization/33928] [4.3/4.4/4.5 Regression] 30% performance slowdown in floating-point code caused by r118475

[bonzini at gnu dot org]

--- Comment #58 from bonzini at gnu dot org  2009-05-06 09:56 ---
Uhm, it's better to run unpatched 4.5 with -O1 -fforward-propagate to get a
fair comparison.  Also, I was counting the loop headers, which are not part of
the hot code.

   4.2 -O1 4.5 -O1 -ffw-prop 4.5 + patch -O1
LOOP 1181 201   180
INNER LOOP 1.1117 118   113
LOOP 227   2726

This shows that you should compare running the code (you can use direct.i) with
4.2/-O1 and 4.5/-O1 -fforward-propagate.  This is very important, otherwise
you're comparing apples to oranges.

fwprop is creating too high register pressure by creating offsets like these in
the loop header:

leaq-8(%r12), %rsi
leaq8(%r12), %r10
leaq-16(%r12), %r9
leaq-24(%r12), %rbx
leaq-32(%r12), %rbp
leaq-40(%r12), %rdi
leaq-48(%r12), %r11
leaq40(%r12), %rdx

Then, the additional register pressure is causing the bad scheduling we have in
the fast assembly outputs:

movq(%rdx), %rax
movsd   (%rax,%r15,2), %xmm7
movq(%rdi), %r15
movsd   (%rax,%r15,2), %xmm10
movq(%rbp), %r15
movsd   (%rax,%r15,2), %xmm5
movq(%rbx), %r15
movsd   (%rax,%r15,2), %xmm6
movq(%r9), %r15
movsd   (%rax,%r15,2), %xmm15
movq(%rsi), %r15
movsd   (%rax,%r15,2), %xmm11


-- 


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

[Bug tree-optimization/33928] [4.3/4.4/4.5 Regression] 30% performance slowdown in floating-point code caused by r118475

[bonzini at gnu dot org]

--- Comment #59 from bonzini at gnu dot org  2009-05-06 09:59 ---
Created an attachment (id=17809)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17809&action=view)
usable testcase

Without includes as Jakub suggested.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

  Attachment #17808|0   |1
is obsolete||


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

[Bug libstdc++/40038] [4.4/4.5 regression] symbols ce...@glibcxx_3.4.3 and ta...@glibcxx_3.4 not exported

[debian-gcc at lists dot debian dot org]

--- Comment #2 from debian-gcc at lists dot debian dot org  2009-05-06 
10:14 ---
same for arm-linux-gnu arm-linux-gnueabi

  Matthias


-- 

debian-gcc at lists dot debian dot org changed:

   What|Removed |Added

 GCC target triplet|mips-linux-gnu mipsel-linux-|mips-linux-gnu mipsel-linux-
   |gnu |gnu arm-linux-gnu arm-linux-
   ||gnueabi


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

[Bug libstdc++/40042] New: delete doesn't always delete

[simonracz at gmail dot com]

I have found that small sized allocations can't be deleted in c++ , probably
because a bug in glibc. I didn't know where to report this, so i decided that i
will report it here too. 
This behaviour affects the very basic map container too. For example by using
map with many elements. 
The allocated memory could be used by other parts of the program later if they
fit in (for example by using another map), but it will never be freed
to be able to use it by other processes till the end of the program.

In the following program i represented a map node with a struct. It will
allocate a lot of these struct and later it tries to delete them, without
success. If you uncomment the "big int array" in the struct, then it will
delete them as you would except normally. I compiled this code with every g++
in ubuntu with the same result.

#include 
#include 
#include 

using namespace std;

struct node
{
   //int big[20];
   int a,b,c,d,e;
};

int main(int argc, char *argv[]) {
   const int num=1000;
   {
vector pointers;
pointers.reserve(num);
for(int i=0;i!=num;++i){
node* p=new node;
pointers.push_back(p);
}
cout << "end of allocating" << endl;
char c;
cin >> c;

for(int i=0;i!=num;++i){
node *p=pointers[i];
delete p;
}
   }

   cout << "nodes are deleted" << endl;
   char d;
   cin >> d;
   cout << "bye" << endl;
}

I checked malloc.c in glibc source. I found that under 64 bytes it won't
automatically release memory back to the kernel for obvious reasons, but if the
so wasted memory become large it will release them, by calling malloc_trim. I
tried to call it manually after deleting these nodes, and it worked. But this
kind of code is not portable ant most importantly not c++.

Sorry if i send this bug report at the wrong place. (this is my first)
Simon Rácz


-- 
   Summary: delete doesn't always delete
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: simonracz at gmail dot com


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

[Bug debug/40040] gfortran invalid DW_AT_location for overridable variables

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2009-05-06 10:24 ---
I'd say this is actually a ld bug, not GCC.
GCC emits:
.uleb128 0x3# (DIE (0x38) DW_TAG_variable)
.ascii "var\0"  # DW_AT_name
.byte   0x1 # DW_AT_decl_file (pr40040lib.f90)
.byte   0x2 # DW_AT_decl_line
.long   0x4f# DW_AT_type
.byte   0x1 # DW_AT_external
.byte   0x9 # DW_AT_location
.byte   0x3 # DW_OP_addr
.quad   __pr40040lib_MOD_var
and the relocation is preserved even by gas, .rela.debug_info has:
 6: 00200738 4 OBJECT  GLOBAL DEFAULT   19 __pr40040lib_MOD_var
But then ld resolves all relocations in .rela.debug_info locally and throws
away that section, while perhaps best would be to drop most of the relocations
from that section and keep only some, against overridable objects.  Still the
question is if .rela.debug_info won't be too large for practical uses.

If DW_AT_location isn't provided, how would gdb find that address out?  Using
DW_AT_MIPS_linkage_name (currently not emitted) and symbol lookup?


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tromey at gcc dot gnu dot
   ||org, roland at redhat dot
   ||com


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

[Bug fortran/40041] spurious warning with INTRINSIC statement

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2009-05-06 10:26 ---
(In reply to comment #0)
> The same warnings are given if the arguments of ABS/MAX are of default-real
> kind, so this not related to implicit typing.

I have to admit that I don't fully understand that sentence, but I don't get
the warning with IMPLICIT NONE. I also don't see the relation to the arguments
of ABS/MAX -- I think it is about implicit typing of the result value of
ABS/MAX itself.

Untested patch:

--- resolve.c   (revision 147168)
+++ resolve.c   (working copy)
@@ -9320,13 +9526,14 @@ resolve_symbol (gfc_symbol *sym)

   if ((isym = gfc_find_function (sym->name)))
{
- if (sym->ts.type != BT_UNKNOWN && gfc_option.warn_surprising)
+ if (sym->ts.type != BT_UNKNOWN && gfc_option.warn_surprising
+ && !sym->attr.implicit_type)
gfc_warning ("Type specified for intrinsic function '%s' at %L is"
 " ignored", sym->name, &sym->declared_at);
}
   else if ((isym = gfc_find_subroutine (sym->name)))
{
- if (sym->ts.type != BT_UNKNOWN)
+ if (sym->ts.type != BT_UNKNOWN && !sym->attr.implicit_type)
{
  gfc_error ("Intrinsic subroutine '%s' at %L shall not have a
type"
 " specifier", sym->name, &sym->declared_at);


-- 


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

[Bug fortran/40039] Procedures as actual arguments: Check intent of arguments

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2009-05-06 10:29 ---
NAG f95 5.1 gives the following error:

Error: line 21: Dummy proc F arg 1 has different INTENT from actual proc FUNC
arg
Error: line 21: Incompatible procedure argument for F (no. 2) of A

After fixing this (intent INOUT -> IN), it is accepted by NAG f95. I think that
is the same as the error message of ifort.


-- 


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

[Bug tree-optimization/33928] [4.3/4.4/4.5 Regression] 30% performance slowdown in floating-point code caused by r118475

[bonzini at gnu dot org]

--- Comment #60 from bonzini at gnu dot org  2009-05-06 10:47 ---
Actually those are created by -fmove-loop-invariants.  With -O1
-fforward-propagate -fno-move-loop-invariants I get:

   4.5 -O1 -ffw-prop -fno-move-loop-inv
LOOP 1183
INNER LOOP 1.1116
LOOP 225

You should be able to get performance close to 4.2 or better with options "-O1
-fforward-propagate -fno-move-loop-invariants -fschedule-insns2".  If you do,
this means two things:

1) That the bug is in the register pressure estimations of
-fno-move-loop-invariants, and merely exposed by the fwprop patch.

2) That maybe you should start from -O2 and go backwards, eliminating
optimizations that do not help you or cause high compilation time, instead of
using -O1.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 Status|NEW |WAITING


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

[Bug target/39975] Support big endian ARM by default.

[ramana at gcc dot gnu dot org]

--- Comment #2 from ramana at gcc dot gnu dot org  2009-05-06 10:52 ---


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


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/16350] gcc only understands little endian ARM systems

[ramana at gcc dot gnu dot org]

--- Comment #23 from ramana at gcc dot gnu dot org  2009-05-06 10:52 ---
*** Bug 39975 has been marked as a duplicate of this bug. ***


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu dot
   ||org


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

[Bug debug/40040] gfortran invalid DW_AT_location for overridable variables

[jan dot kratochvil at redhat dot com]

--- Comment #2 from jan dot kratochvil at redhat dot com  2009-05-06 10:54 
---
(In reply to comment #1)
> If DW_AT_location isn't provided, how would gdb find that address out?  Using
> DW_AT_MIPS_linkage_name (currently not emitted) and symbol lookup?

The GDB patch now assembles the symbol name from its parent DW_TAG_module as
`__modulename_MOD_varname'.  As GDB also has to know the C++ mangling rules I
believe this Fortran mangling is can be also used from GDB.

If GDB should never guess the fully qualified names I will have to file at
least one more GCC fortran debug/ PR for DW_TAG_imported_declaration which
already uses only DW_TAG_variable with DW_AT_declaration and no DW_AT_location.


-- 


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

[Bug libstdc++/40042] delete doesn't always delete

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-05-06 10:55 ---
This is a glibc "bug".


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug target/40031] [4.5 Regression] ARM broken with addresses in PHIs with -fPIC

[ramana at gcc dot gnu dot org]

--- Comment #3 from ramana at gcc dot gnu dot org  2009-05-06 10:59 ---
(In reply to comment #1)
> What's the ICE?
> 

With a cross arm-linux-gnueabi version r147153, I get a segfault with the
following backtrace for this particular testcase. 

#0  0x082112b1 in emit_insn_after_1 (first=0xb7c352d0, after=0xb7c324b0,
bb=0xb7c324d4) at /home/ramrad01/sourcearea/trunk/gcc/emit-rtl.c:4129
#1  0x0821214c in emit_insn_after (pattern=0x0, after=0xb7c324b0) at
/home/ramrad01/sourcearea/trunk/gcc/emit-rtl.c:4335
#2  0x085eb5b7 in legitimize_pic_address (orig=0xb7c41c08, mode=SImode,
reg=0x0) at /home/ramrad01/sourcearea/trunk/gcc/config/arm/arm.c:3599
#3  0x086b2ead in gen_movsi (operand0=0x0, operand1=0xb7c41c08) at
/home/ramrad01/sourcearea/trunk/gcc/config/arm/arm.md:4966
#4  0x0824ad24 in emit_move_insn_1 (x=0xb7c39ce0, y=0xb7c41c08) at
/home/ramrad01/sourcearea/trunk/gcc/expr.c:3337
#5  0x0824b012 in emit_move_insn (x=0xb7c39ce0, y=0xb7c41c08) at
/home/ramrad01/sourcearea/trunk/gcc/expr.c:3425
#6  0x087d1923 in expand_phi_nodes (sa=0x8acb174) at
/home/ramrad01/sourcearea/trunk/gcc/tree-outof-ssa.c:211
#7  0x08754d77 in gimple_expand_cfg () at
/home/ramrad01/sourcearea/trunk/gcc/cfgexpand.c:2506
#8  0x08381d8d in execute_one_pass (pass=0x8a2f720) at
/home/ramrad01/sourcearea/trunk/gcc/passes.c:1291
#9  0x0838200c in execute_pass_list (pass=0x8a2f720) at
/home/ramrad01/sourcearea/trunk/gcc/passes.c:1340
#10 0x0848a6c0 in tree_rest_of_compilation (fndecl=0xb7c34680) at
/home/ramrad01/sourcearea/trunk/gcc/tree-optimize.c:394
#11 0x085fd902 in cgraph_expand_function (node=0xb7bb8a00) at
/home/ramrad01/sourcearea/trunk/gcc/cgraphunit.c:1051
#12 0x085ff7cf in cgraph_optimize () at
/home/ramrad01/sourcearea/trunk/gcc/cgraphunit.c:1110
#13 0x080cec7b in c_write_global_declarations () at
/home/ramrad01/sourcearea/trunk/gcc/c-decl.c:8364
#14 0x084334a6 in toplev_main (argc=20, argv=0xbf806e84) at
/home/ramrad01/sourcearea/trunk/gcc/toplev.c:990
#15 0x08152f82 in main (argc=Cannot access memory at address 0x0
) at /home/ramrad01/sourcearea/trunk/gcc/main.c:35


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-05-06 10:59:43
   date||


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

[Bug libstdc++/40038] [4.4/4.5 regression] symbols ce...@glibcxx_3.4.3 and ta...@glibcxx_3.4 not exported

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2009-05-06 11:02 
---
By the way, if you want to hear my advice, remember to regression test on those
much less widespread targets *before* major releases.


-- 


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

[Bug middle-end/39954] [4.5 Regression] Revision 146817 caused unaligned access in gcc.dg/torture/pr26565.c

[rguenth at gcc dot gnu dot org]

--- Comment #15 from rguenth at gcc dot gnu dot org  2009-05-06 11:08 
---
For optimization purposes differently aligned type variants should be treated
as a variant type, thus liked in the TYPE_NEXT_VARIANT chain (probably also
required to get correct behavior when assigning alias sets).  The gimple
type system then should treat conversions of pointer types with differing
alignment of their target types as not useless.  Eventually conversion
folding machinery needs to be adjusted, at least the STRIP_NOPS code needs to.

The question is also whether for the FIELD_DECLs we properly put in place
types with TYPE_ALIGN == 8 into packed structures.  I have no idea if we
want to set TYPE_USER_ALIGN on these types though - and what it makes for
a difference.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org


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

[Bug c/40026] [4.5 Regression] ICE during gimplify_init_constructor

[joseph at codesourcery dot com]

--- Comment #2 from joseph at codesourcery dot com  2009-05-06 11:09 ---
Subject: Re:  [4.5 Regression] ICE during gimplify_init_constructor

On Tue, 5 May 2009, rguenth at gcc dot gnu dot org wrote:

> Reduced testcase, maybe due to the C const expression changes(?)

I see nothing in the reported information about this bug to suggest this 
(rather than, say, the move of COMPOUND_LITERAL_EXPR handling to 
language-independent code).  What do you think is wrong about the trees 
being passed by the C front end to the gimplifier?


-- 


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

[Bug middle-end/40043] New: [4.5 Regression] ICE with nested try/catch

[reichelt at gcc dot gnu dot org]

The following valid testcase triggers an ICE on trunk when compiled with "-O":

===
struct A
{
  ~A();
  void foo();
};

void bar()
{
  A a;

  try
  {
A b;

try
{
  b.foo();
}
catch (int) {}
  }
  catch (int) {}
}
===

bug.cc: In function 'void bar()':
bug.cc:7: error: EH edge 2->21 is missing
bug.cc:7: error: unnecessary EH edge 2->10
bug.cc:7: internal compiler error: verify_flow_info failed
Please submit a full bug report, [etc.]

The bug might be related to PR39862.


-- 
   Summary: [4.5 Regression] ICE with nested try/catch
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug middle-end/40043] [4.5 Regression] ICE with nested try/catch

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0
Version|unknown |4.5.0


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

[Bug middle-end/39954] [4.5 Regression] Revision 146817 caused unaligned access in gcc.dg/torture/pr26565.c

[matz at gcc dot gnu dot org]

--- Comment #16 from matz at gcc dot gnu dot org  2009-05-06 11:20 ---
Joseph: I'd need some advise where best starting to fix this.  I see some
options, when we want to deal with such construct:

struct S { T member __attribute__((packed)); };
... struct S s; ... &s->member ...

(1) make the type of the FIELD_DECL not be T but an aligned(1) variant
of it.  Currently simply DECL_PACKED is set on the FIELD_DECL, but
that's ignored in some contextes, which results in the other options:
(2) make the type of the COMPONENT_REF "s->member" not be T but an aligned(1)
variant of it, and
(3) make the type of the ADDR_EXPR "&s->member" not be T* but (T-aligned1)*.

It seems that option (1) would be the most thorough one as then surely no
other code can accidentally construct an aligned access to it.  I think
amending handle_packed_attribute to retroactively patch TREE_TYPE if called
on a FIELD_DECL might do it.

Option (3) I think is the least appealing one, as I'd always fear that there
might be other usages of the COMPONENT_REF than the ADDR_EXPR where the
alignment might matter.  It would also mean constructing the pointer type
not from the RHS but using some variant, which seems to introduce a conceptual
inconsistency.

Option (2) lies somewhere in between, although it should be nearly equivalent
to option 1, as there aren't many other contexts than COMPONENT_REF where
a pure FIELD_DECL could be used.  But option (2) has the advantage that the
structure type is completely laid out already, not so for option (1).  That
might be important for performance sometimes, e.g. when the user declares
a field as packed (or aligned(1)), but it so happens (due to other members)
that it got it's natural alignment in the end.  In that case we don't _have_
to construct unaligned types.


-- 

matz at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||joseph at codesourcery dot
   ||com


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

[Bug libstdc++/39546] parallel mode doesn't support implicit string conversion

[singler at gcc dot gnu dot org]

--- Comment #19 from singler at gcc dot gnu dot org  2009-05-06 11:21 
---
Subject: Bug 39546

Author: singler
Date: Wed May  6 11:20:35 2009
New Revision: 147169

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147169
Log:
2009-05-06  Johannes Singler  

PR libstdc++/39546
* include/parallel/algo.h (find_switch):
Parametrize binder2nd with const T& instead of T.
* testsuite/25_algorithms/find/39546.cc: new test case


Added:
trunk/libstdc++-v3/testsuite/25_algorithms/find/39546.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/parallel/algo.h


-- 


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

[Bug libstdc++/40038] [4.4/4.5 regression] symbols ce...@glibcxx_3.4.3 and ta...@glibcxx_3.4 not exported

[paolo dot carlini at oracle dot com]

-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

   Target Milestone|--- |4.4.1


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

[Bug libstdc++/40038] [4.4/4.5 regression] symbols ce...@glibcxx_3.4.3 and ta...@glibcxx_3.4 not exported

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2009-05-06 11:25 
---
Benjamin, can you have a look?


-- 


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

[Bug libstdc++/40042] delete doesn't always delete

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2009-05-06 11:39 
---
By the way, valgrind, correctly, doesn't report anything, at least together
with glibc 2.9:

==5250== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 3 from 1)
==5250== malloc/free: in use at exit: 0 bytes in 0 blocks.
==5250== malloc/free: 10,000,001 allocs, 10,000,001 frees, 280,000,000 bytes
allocated.


-- 


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

[Bug c/40026] [4.5 Regression] ICE during gimplify_init_constructor

[rguenther at suse dot de]

--- Comment #3 from rguenther at suse dot de  2009-05-06 11:41 ---
Subject: Re:  [4.5 Regression] ICE during
 gimplify_init_constructor

On Wed, 6 May 2009, joseph at codesourcery dot com wrote:

> Subject: Re:  [4.5 Regression] ICE during gimplify_init_constructor
> 
> On Tue, 5 May 2009, rguenth at gcc dot gnu dot org wrote:
> 
> > Reduced testcase, maybe due to the C const expression changes(?)
> 
> I see nothing in the reported information about this bug to suggest this 
> (rather than, say, the move of COMPOUND_LITERAL_EXPR handling to 
> language-independent code).  What do you think is wrong about the trees 
> being passed by the C front end to the gimplifier?

It was just wild guessing - the COMPOUND_LITERAL_EXPR changes may be
indeed a better guess.

Richard.


-- 


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

[Bug middle-end/39954] [4.5 Regression] Revision 146817 caused unaligned access in gcc.dg/torture/pr26565.c

[rguenther at suse dot de]

--- Comment #17 from rguenther at suse dot de  2009-05-06 11:45 ---
Subject: Re:  [4.5 Regression] Revision 146817 caused
 unaligned access in gcc.dg/torture/pr26565.c

On Wed, 6 May 2009, matz at gcc dot gnu dot org wrote:

> --- Comment #16 from matz at gcc dot gnu dot org  2009-05-06 11:20 ---
> Option (2) lies somewhere in between, although it should be nearly equivalent
> to option 1, as there aren't many other contexts than COMPONENT_REF where
> a pure FIELD_DECL could be used.  But option (2) has the advantage that the
> structure type is completely laid out already, not so for option (1).  That
> might be important for performance sometimes, e.g. when the user declares
> a field as packed (or aligned(1)), but it so happens (due to other members)
> that it got it's natural alignment in the end.  In that case we don't _have_
> to construct unaligned types.

I'm all for option (1), but concering (2) - a packed structure does
have alignment 1, so how can we derive anything but alignment 1 from
(the sizes of, supposedly) other members?  That is, we would have
to build an explicitly aligned _decl_ of the packed type to be able
to derive more than 1 alignment.  No?

Richard.


-- 


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

[Bug fortran/40041] spurious warning with INTRINSIC statement

[dfranke at gcc dot gnu dot org]

--- Comment #2 from dfranke at gcc dot gnu dot org  2009-05-06 11:57 ---
(In reply to comment #1)
> > The same warnings are given if the arguments of ABS/MAX are of default-real
> > kind, so this not related to implicit typing.
> 
> I have to admit that I don't fully understand that sentence, but I don't get
> the warning with IMPLICIT NONE. I also don't see the relation to the arguments
> of ABS/MAX -- I think it is about implicit typing of the result value of
> ABS/MAX itself.

IIRC, typing of 'a' and 'n' is enough to avoid the warnings as well. 

In above statement I assumed some interaction between INTEGER actual arguments
to an implicitly typed REAL ABS-function - and REAL-typed arguments to the
implicitly INTEGER-typed MAX-function. Thus, converting all the arguments to
REAL as in

  a(n) = MAX(ABS(2.0),ABS(3.0),REAL(n))

one could think that the warnings should vanish - they don't. So, I concluded,
that it's not related to the argument types.

Btw, adding "REAL ABS,MAX" doesn't help either, so it's not related to the
function's types.

I'll give your patch a try later today.


-- 


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

[Bug middle-end/39954] [4.5 Regression] Revision 146817 caused unaligned access in gcc.dg/torture/pr26565.c

[matz at gcc dot gnu dot org]

--- Comment #18 from matz at gcc dot gnu dot org  2009-05-06 11:57 ---
The structure in this testcase is not packed.  One member is.  Or are you
talking about some different case?

Let's suppose you are and you mean something like this:
  struct S {T1 m1; T2 m2; ...} __attribute__((packed));
then IMO all members should also have DECL_PACKED set.  I don't think this
is currently the case (only TYPE_PACKED is set on the whole struct type), but
conceptually that is the ultimate meaning.

If we don't do that we still can create such unaligned types when building
COMPONENT_REFs, when the base datum has TYPE_PACKED set, i.e. option (2).
But let's deal with one case after the other, I'm currently concerned with
only packed members.


-- 


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

[Bug libstdc++/40042] delete doesn't always delete

[simonracz at gmail dot com]

--- Comment #3 from simonracz at gmail dot com  2009-05-06 12:03 ---
(In reply to comment #2)
> By the way, valgrind, correctly, doesn't report anything, at least together
> with glibc 2.9:

You can see the difference in memory usage (after deleting) with top.


-- 


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

[Bug libstdc++/40042] delete doesn't always delete

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2009-05-06 12:07 
---
Oh well, if valgrind is happy, definitely not a libstdc++ maintainers job.


-- 


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

[Bug libstdc++/40042] delete doesn't always delete

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2009-05-06 12:14 ---
That just means you have no idea how a memory allocator works.
Returning all just freed pages immediately to the system is of course possible,
but terribly expensive performance wise, since often on the following malloc
call you'll need the memory again and mmapping it is very expensive.
glibc malloc has many options which allow you to fine tune things to the
behavior of your application, see mallopt or corresponding env variables, plus
recent glibcs (last year or two, don't remember) use madvise syscall in certain
cases to allow the kernel to reuse the pages for other process if needed, but
if not immediately needed for other process can be fairly cheaply used by the
current process for malloc again.


-- 


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

[Bug c++/40044] New: ICE when resolves overloaded functions

[vbvan at 163 dot com]

The following code will ICE:

template
void f(T*);

template
struct A {};

template
void g(A > *);

int main()
{
g((A >*)0);
}


-- 
   Summary: ICE when resolves overloaded functions
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vbvan at 163 dot com


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

[Bug bootstrap/40027] [4.4/4.5 regression] i686-pc-solaris2.10 bootstrap fails using Sun ld

[ro at gcc dot gnu dot org]

--- Comment #1 from ro at gcc dot gnu dot org  2009-05-06 13:01 ---
I've just confirmed the bug on i686-pc-solaris2.10.  It doesn't occur on
i686-pc-solaris2.11, though, so this is indeed a Sun ld bug.

I've got a few questions to resolve, though:

* Why does generating code for i686 instead of i386 change gcc's assembler
output
  so significantly?

* Is it possible to get the relevant CRs backported to Solaris 10 (or are fixes
  already included in recent linker/kernel patches)?

* How to handle this in gcc/configure.ac?  I'd like to avoid completely
  disabling hidden support on Solaris 10 (and even early versions of Solaris 11
  before the linker bug got fixed).


-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ro at gcc dot gnu dot org
 AssignedTo|unassigned at gcc dot gnu   |ro at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-05-06 13:01:30
   date||


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

[Bug libstdc++/40038] [4.4/4.5 regression] symbols ce...@glibcxx_3.4.3 not exported

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2009-05-06 13:02 ---
Only ceill is actually missing in SVN.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.4/4.5 regression] symbols|[4.4/4.5 regression] symbols
   |ce...@glibcxx_3.4.3 and |ce...@glibcxx_3.4.3 not
   |ta...@glibcxx_3.4 not   |exported
   |exported|


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

[Bug c/40032] [4.5 regression] ICE with incomplete type in struct

[jsm28 at gcc dot gnu dot org]

--- Comment #1 from jsm28 at gcc dot gnu dot org  2009-05-06 13:03 ---
Subject: Bug 40032

Author: jsm28
Date: Wed May  6 13:02:48 2009
New Revision: 147174

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147174
Log:
PR c/40032
* c-decl.c (grokdeclarator): Handle incomplete type of unnamed
field.

testsuite:
* gcc.dg/noncompile/incomplete-5.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/noncompile/incomplete-5.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-decl.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c/40032] [4.5 regression] ICE with incomplete type in struct

[jsm28 at gcc dot gnu dot org]

--- Comment #2 from jsm28 at gcc dot gnu dot org  2009-05-06 13:04 ---
Fixed for 4.5.


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||4.5.0
 Resolution||FIXED


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

[Bug rtl-optimization/33928] [4.3/4.4/4.5 Regression] 30% performance slowdown in floating-point code caused by r118475

[jakub at gcc dot gnu dot org]

--- Comment #61 from jakub at gcc dot gnu dot org  2009-05-06 13:05 ---
Also see PR39871, maybe that's related (though on ARM).


-- 


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

[Bug libstdc++/40038] [4.4/4.5 regression] symbols ce...@glibcxx_3.4.3 not exported

[paolo dot carlini at oracle dot com]

--- Comment #6 from paolo dot carlini at oracle dot com  2009-05-06 13:20 
---
Excellent. Then Matthias' suggested fix makes sense to me. Better if Benjamin
could also review it, however (lately, he touched this code, IIRC).


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-05-06 13:20:29
   date||


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

[Bug tree-optimization/39999] [4.4/4.5 Regression] gcc 4.4.0 compiles in infinite loop

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-05-06 13:24 ---
Reduced testcase:

void foo(void *);
void
MMAPGCD (int *A1, int *A2)
{
  int *t; 

  do
{
  t = A1;
  A1 = A2;
  A2 = t;
}
  while (A2[-1]);

  foo (A1-1);
  foo (A2-1);
}   

if you make foo take int * the issue goes away.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail||4.4.0
  Known to work||4.3.3
Summary|gcc 4.4.0 compiles in   |[4.4/4.5 Regression] gcc
   |infinite loop   |4.4.0 compiles in infinite
   ||loop
   Target Milestone|--- |4.4.1


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

[Bug fortran/40045] New: ICE with type extension and -fdump-parse-tree

[janus at gcc dot gnu dot org]

Segfault with -fdump-parse-tree:

type t
end type
type, extends(t) :: t2
end type t2
end


-- 
   Summary: ICE with type extension and -fdump-parse-tree
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janus at gcc dot gnu dot org


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

[Bug tree-optimization/39999] [4.4/4.5 Regression] gcc 4.4.0 compiles in infinite loop

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2009-05-06 13:52 ---
Ok, I know what happens.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-05-02 10:19:57 |2009-05-06 13:52:20
   date||


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

[Bug other/40046] New: GCC build fails due to host_address variable is empty

[roman dot marchenko at mail dot ru]

There is the following line in configure script:

eval `${CC-cc} -E conftest.c | grep host_address=`

Since I have GREP_OPTIONS variable in my environment which looks like
"GREP_OPTIONS=--color=always", some color codes are generated in grep's output.
The issue is the "eval ..." does not work properly in this case and the
host_address variable is empty.

I have repaired the build by replacing the line with the following:

eval `${CC-cc} -E conftest.c | grep --color=auto host_address=`


-- 
   Summary: GCC build fails due to host_address variable is empty
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: roman dot marchenko at mail dot ru
 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=40046

[Bug middle-end/40021] [4.5 Regression] Revision 146817 miscompiled DAXPY in BLAS

[hjl dot tools at gmail dot com]

--- Comment #11 from hjl dot tools at gmail dot com  2009-05-06 14:27 
---
(In reply to comment #10)
> Yes, I'll clean this up before submission.  Did it help?
> 

I tried it on revision 147173 and it works on test input for
416.gamess and 465.tonto. I am running reference input now. Thanks.


-- 


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

[Bug fortran/40041] spurious warning with INTRINSIC statement

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2009-05-06 14:28 ---
> Btw, adding "REAL ABS,MAX" doesn't help either, so it's not related to the
> function's types.

Well, exactly that should trigger the warning! Thus it shall not help silencing
the warning!

Some light testing - now that bootstrapping finished - shows that the patch
seems to work correctly. -> Assign to myself


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |burnus at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-05-06 14:28:48
   date||


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

[Bug fortran/40045] ICE with type extension and -fdump-parse-tree

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2009-05-06 14:31 ---
Confirmed and this is regression with repect to 4.4.0:

[karma] f90/bug% gfc -fdump-parse-tree pr40045.f90

Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4)
procedure name = MAIN__
symtree: MAIN__  Ambig 0
symbol MAIN__ (UNKNOWN 0)(PROGRAM UNKNOWN-INTENT PUBLIC UNKNOWN-PROC
UNKNOWN SUBROUTINE)

symtree: t  Ambig 0
symbol t (UNKNOWN 0)(DERIVED UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC
UNKNOWN)
Procedure bindings:

f951: internal compiler error: Bus error
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
  PROCEDURE, [karma] f90/bug% 
[karma] f90/bug% gfc44 -fdump-parse-tree pr40045.f90

Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4)
procedure name = MAIN__
symtree: MAIN__  Ambig 0
symbol MAIN__ (UNKNOWN 0)(PROGRAM UNKNOWN-INTENT PUBLIC UNKNOWN-PROC
UNKNOWN SUBROUTINE)

symtree: t  Ambig 0
symbol t (UNKNOWN 0)(DERIVED UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC
UNKNOWN)
Procedure bindings:


symtree: t2  Ambig 0
symbol t2 (UNKNOWN 0)(DERIVED UNKNOWN-INTENT UNKNOWN-ACCESS
UNKNOWN-PROC UNKNOWN)
components: (t (DERIVED t) ())
Procedure bindings:


-- 


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

[Bug fortran/40045] ICE with type extension and -fdump-parse-tree

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2009-05-06 14:39 ---
Regarding the segfault, valgrind shows:

==14376== Invalid read of size 1
==14376==by 0x616A4F7: fprintf (in /lib64/libc-2.9.so)
==14376==by 0x4B4BF1: show_typebound (dump-parse-tree.c:693)

The line is:
fprintf (dumpfile, "PASS(%s)", st->n.tb->pass_arg);
and the interesting question is: Why is it called? There are no type-bound
procedures (and also no components [except of t2%t]. Thus why is
  if (!st->n.tb)
return;
not working?

 * * *

Related problem: The following gives: show_code_node(): Bad statement code

type t
  procedure(), nopass, pointer :: p
end type t
type(t) m
!external bar
!m%p => bar
call m%p()
end


-- 


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

[Bug bootstrap/40027] [4.4/4.5 regression] i686-pc-solaris2.10 bootstrap fails using Sun ld

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2009-05-06 14:51 ---
(In reply to comment #1)
> I've just confirmed the bug on i686-pc-solaris2.10.  It doesn't occur on
> i686-pc-solaris2.11, though, so this is indeed a Sun ld bug.
> 
> I've got a few questions to resolve, though:
> 
> * Why does generating code for i686 instead of i386 change gcc's assembler
> output
>   so significantly?
> 

The difference is in how to get PC for -fPIC:

bash-3.2$ cat p.c
void
foo ()
{
  bar ();
}
bash-3.2$ gcc -m32 -fPIC p.c -S -O3 -mtune=i386
bash-3.2$ cat p.s
.file   "p.c"
.text
.p2align 2,,3
.globl foo
.type   foo, @function
foo:
pushl   %ebp
movl%esp, %ebp
pushl   %ebx
subl$4, %esp
call.L3
.L3:
popl%ebx
addl$_GLOBAL_OFFSET_TABLE_+[.-.L3], %ebx
callb...@plt
popl%eax
popl%ebx
leave
ret
.size   foo, .-foo
.ident  "GCC: (GNU) 4.3.2 20081105 (Red Hat 4.3.2-7)"
.section.note.GNU-stack,"",@progbits
bash-3.2$ gcc -m32 -fPIC p.c -S -O3 -mtune=i686
bash-3.2$ cat p.s
.file   "p.c"
.text
.p2align 4,,15
.globl foo
.type   foo, @function
foo:
pushl   %ebp
movl%esp, %ebp
pushl   %ebx
call__i686.get_pc_thunk.bx
addl$_GLOBAL_OFFSET_TABLE_, %ebx
subl$4, %esp
callb...@plt
addl$4, %esp
popl%ebx
popl%ebp
ret
.size   foo, .-foo
.ident  "GCC: (GNU) 4.3.2 20081105 (Red Hat 4.3.2-7)"
.section   
.text.__i686.get_pc_thunk.bx,"axG",@progbits,__i686.get_pc_thunk.bx,comdat
.globl __i686.get_pc_thunk.bx
.hidden __i686.get_pc_thunk.bx
.type   __i686.get_pc_thunk.bx, @function
__i686.get_pc_thunk.bx:
movl(%esp), %ebx
ret
.section.note.GNU-stack,"",@progbits
bash-3.2$ 


-- 


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

[Bug fortran/40045] ICE with type extension and -fdump-parse-tree

[janus at gcc dot gnu dot org]

--- Comment #3 from janus at gcc dot gnu dot org  2009-05-06 14:58 ---
(In reply to comment #2)
> and the interesting question is: Why is it called? There are no type-bound
> procedures (and also no components [except of t2%t]. 

If it's a regression it may be caused by Daniel's r146733 ("reworking
type-bound procedures")?!?



> Related problem: The following gives: show_code_node(): Bad statement code

I will handle this in my PPC patch before committing.


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||domob at gcc dot gnu dot org


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

[Bug fortran/40045] ICE with type extension and -fdump-parse-tree

[domob at gcc dot gnu dot org]

--- Comment #4 from domob at gcc dot gnu dot org  2009-05-06 15:01 ---
Yes, that sounds like a problem caused by my patch; it did change the structure
of storing the type-bounds, so maybe simply changing the if to the one shown by
Tobias was wrong.

I will look into this!


-- 

domob at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |domob at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-05-06 15:01:04
   date||


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

[Bug rtl-optimization/39871] [4.3/4.4/4.5 regression] Code size increase on ARM due to inferior CSE

[bonzini at gnu dot org]

--- Comment #1 from bonzini at gnu dot org  2009-05-06 15:06 ---
With 4.5 I see
With 4.5.0 I see:

push{lr}
sub sp, sp, #12
ldr r2, [r0]
ldr r1, [r0, #4]
mov r0, sp
str r2, [sp, #4]
bl  func
add sp, sp, #12
pop {pc}

Can you bisect which revision fixed this?


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 CC||bonzini at gnu dot org
  Known to work||4.5.0


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

[Bug rtl-optimization/33928] [4.3/4.4/4.5 Regression] 30% performance slowdown in floating-point code caused by r118475

[bonzini at gnu dot org]

--- Comment #62 from bonzini at gnu dot org  2009-05-06 15:07 ---
No, totally unrelated to PR39871


-- 


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

[Bug libgomp/40047] New: [4.5 Regression] ICE for libgomp.c++/task-4.C: type mismatch in indirect reference

[burnus at gcc dot gnu dot org]

Compiling "libgomp.c++/task-4.C" with "g++" is successful, but compiling it
with "g++ -fopenmp" gives:

libgomp.c++/task-4.C: In function 'void foo(int, int)':
libgomp.c++/task-4.C:37: error: type mismatch in indirect reference
int[0:D.2193]

int[0:<<< error >>>]

D.2218 = &(*q.1)[0];

libgomp.c++/task-4.C:37: error: type mismatch in indirect reference
int[0:D.2173]

int[0:<<< error >>>]

D.2219 = &(*p.0)[0];

libgomp.c++/task-4.C:37: internal compiler error: verify_stmts failed


(It might be not a true regression but a side effect of stricter type checking
in 4.5.)


-- 
   Summary: [4.5 Regression] ICE for libgomp.c++/task-4.C: type
mismatch in indirect reference
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug libgomp/40047] [4.5 Regression] ICE for libgomp.c++/task-4.C: type mismatch in indirect reference

[burnus at gcc dot gnu dot org]

-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0
Version|unknown |4.5.0


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

[Bug tree-optimization/39999] [4.4/4.5 Regression] gcc 4.4.0 compiles in infinite loop

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug bootstrap/39929] [4.5 Regression] Bootstrapping fails at stage 1 on powerpc-ibm-aix

[bonzini at gnu dot org]

--- Comment #19 from bonzini at gnu dot org  2009-05-06 15:33 ---
ARM moved to PR40031 (and PR39978?).

What about AIX?


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 Status|NEW |WAITING


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

[Bug middle-end/39978] [4.5 Regression] SEGV compiling libiberty/regex.c in stage2

[bonzini at gnu dot org]

--- Comment #7 from bonzini at gnu dot org  2009-05-06 15:35 ---
Is this reproducible with a crosscompiler and with --enable-checking=all,gcac? 
You can try valgrind too.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 CC||bonzini at gnu dot org


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

[Bug fortran/40041] spurious warning with INTRINSIC statement

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2009-05-06 15:45 ---
Subject: Bug 40041

Author: burnus
Date: Wed May  6 15:44:18 2009
New Revision: 147183

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147183
Log:
2009-05-06  Tobias Burnus  

PR fortran/40041
* resolve.c (resolve_symbol): Print no warning for implicitly
typed intrinsic functions.

2009-05-06  Tobias Burnus  

PR fortran/40041
* gfortran.dg/intrinsic_2.f90: New test.
* gfortran.dg/intrinsic.f90: Add old and this PR as comment.


Added:
trunk/gcc/testsuite/gfortran.dg/intrinsic_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/intrinsic.f90


-- 


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

[Bug fortran/40041] spurious warning with INTRINSIC statement

[burnus at gcc dot gnu dot org]

--- Comment #5 from burnus at gcc dot gnu dot org  2009-05-06 15:46 ---
FIXED on the trunk (4.5). Thanks for reporting it.

Crossref: The warning was added by Daniel Franke with Rev. 126153 for PR 20373.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/40048] New: Compiler crash possibly related to --std=c++0x

[bgalehouse at spamcop dot net]

The following was produced on a gentoo x86 linux system with a pentium-m
processor, the system compiler is Gentoo 4.3.3-r2 and kernel is
linux-2.6.28-gentoo-r5. 

Last night, I built gcc 4.4.0 and installed it into /home/bgalehouse/installs. 
I then reconfigured a library (CGAL) to make use of c++0x features, and tried
to compile a program. This program worked fine under the system compiler when
the library is configured to avoid c++0x features. I might have time to compile
and try a recent snapshot over the next few days, if so I'll try to amend this
bug report accordingly.

g++ -v --save-temps -c --std=c++0x -g -O0 -Wall -D_GLIBCXX_DEBUG
-I/home/bgalehouse/installs/include -Isubdivision_trees -I.  meshTangleCube.cpp
-o meshTangleCube.o
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ./configure --prefix=/home/bgalehouse/installs/
--enable-languages=c,c++ --with-ppl=/home/bgalehouse/install
--with-cloog=/home/bgalehouse/install --with-gmp=/home/bgalehouse/install
Thread model: posix
gcc version 4.4.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-std=c++0x' '-g' '-O0' '-Wall'
'-D_GLIBCXX_DEBUG' '-I/home/bgalehouse/installs/include' '-Isubdivision_trees'
'-I.' '-o' 'meshTangleCube.o' '-shared-libgcc' '-mtune=generic'
 /home/bgalehouse/installs/bin/../libexec/gcc/i686-pc-linux-gnu/4.4.0/cc1plus
-E -quiet -v -I/home/bgalehouse/installs/include -Isubdivision_trees -I.
-iprefix /home/bgalehouse/installs/bin/../lib/gcc/i686-pc-linux-gnu/4.4.0/
-D_GNU_SOURCE -D_GLIBCXX_DEBUG m
eshTangleCube.cpp -mtune=generic -std=c++0x -Wall -g -fworking-directory -O0
-fpch-preprocess -o meshTangleCube.ii
ignoring nonexistent directory
"/home/bgalehouse/installs/bin/../lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../i686-pc-linux-gnu/include"
ignoring duplicate directory
"/home/bgalehouse/installs/bin/../lib/gcc/../../lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0"
ignoring duplicate directory
"/home/bgalehouse/installs/bin/../lib/gcc/../../lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0/i686-pc-linux-gnu"
ignoring duplicate directory
"/home/bgalehouse/installs/bin/../lib/gcc/../../lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0/backward"
ignoring nonexistent directory "/usr/local/include"
ignoring duplicate directory
"/home/bgalehouse/installs/bin/../lib/gcc/../../include"
ignoring duplicate directory
"/home/bgalehouse/installs/bin/../lib/gcc/../../lib/gcc/i686-pc-linux-gnu/4.4.0/include"
ignoring duplicate directory
"/home/bgalehouse/installs/bin/../lib/gcc/../../lib/gcc/i686-pc-linux-gnu/4.4.0/include-fixed"
ignoring nonexistent directory
"/home/bgalehouse/installs/bin/../lib/gcc/../../lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../i686-pc-linux-gnu/include"
ignoring duplicate directory "/home/bgalehouse/installs/include"
  as it is a non-system directory that duplicates a system directory
ignoring duplicate directory "/home/bgalehouse/installs/include/"
  as it is a non-system directory that duplicates a system directory
#include "..." search starts here:
#include <...> search starts here:
 subdivision_trees
 .
 /home/bgalehouse/installs/include/

/home/bgalehouse/installs/bin/../lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0

/home/bgalehouse/installs/bin/../lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0/i686-pc-linux-gnu

/home/bgalehouse/installs/bin/../lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0/backward
 /home/bgalehouse/installs/bin/../lib/gcc/i686-pc-linux-gnu/4.4.0/include
 /home/bgalehouse/installs/bin/../lib/gcc/i686-pc-linux-gnu/4.4.0/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-std=c++0x' '-g' '-O0' '-Wall'
'-D_GLIBCXX_DEBUG' '-I/home/bgalehouse/installs/include' '-Isubdivision_trees'
'-I.' '-o' 'meshTangleCube.o' '-shared-libgcc' '-mtune=generic'
 /home/bgalehouse/installs/bin/../libexec/gcc/i686-pc-linux-gnu/4.4.0/cc1plus
-fpreprocessed meshTangleCube.ii -quiet -dumpbase meshTangleCube.cpp
-mtune=generic -auxbase-strip meshTangleCube.o -g -O0 -Wall -std=c++0x -version
-o meshTangleCube.s
GNU C++ (GCC) version 4.4.0 (i686-pc-linux-gnu)
compiled by GNU C version 4.4.0, GMP version 4.3, MPFR version
2.4.1-p1.
warning: GMP header version 4.3 differs from library version 4.3.0.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: a06cae60c4bc667b19bd2a267478aeb7
In file included from FunctionInfo.h++:5,
 from SimpleHull.h++:11,
 from CGALHullFinder.h++:4,
 from meshTangleCube.cpp:10:
subdivision_trees/CGAL/Spatial_subdivision_tree.h: In member function
'CGAL::Spatial_subdivision_tree::rect_reference
CGAL::Spatial_subdivision_tree::root_reference() [with unsigned int
a_dim = 3u, D_ = CGALHullFinder,
CGAL::Linear_algebraCd<__gmp_expr<__mpq_struct [1], __mpq_struct [1]>,
std::allocator<__gmp_expr<__mpq_struct [1], __mpq_struct [1]> > > >,
tangleCubeFunction<3

[Bug middle-end/40021] [4.5 Regression] Revision 146817 miscompiled DAXPY in BLAS

[hjl dot tools at gmail dot com]

--- Comment #12 from hjl dot tools at gmail dot com  2009-05-06 15:48 
---
(In reply to comment #11)
> (In reply to comment #10)
> > Yes, I'll clean this up before submission.  Did it help?
> > 
> 
> I tried it on revision 147173 and it works on test input for
> 416.gamess and 465.tonto. I am running reference input now. Thanks.
> 

It fixed 416.gamess and 465.tonto with reference input.


-- 


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

[Bug bootstrap/39929] [4.5 Regression] Bootstrapping fails at stage 1 on powerpc-ibm-aix

[matz at gcc dot gnu dot org]

--- Comment #20 from matz at gcc dot gnu dot org  2009-05-06 15:48 ---
Bootstrap on AIX was already working on April 29:
http://gcc.gnu.org/ml/gcc-patches/2009-04/msg02342.html

I just left this open for the other (ARM/Mips) problem.  As that now moved
somewhere else, this here is fixed.


-- 

matz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED


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

[Bug c++/40048] Compiler crash possibly related to --std=c++0x

[bgalehouse at spamcop dot net]

--- Comment #1 from bgalehouse at spamcop dot net  2009-05-06 15:53 ---
Created an attachment (id=17810)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17810&action=view)
Compressed preprocessed source to recreate.

Attached proprocessed source file, compressed to fit under bugtraq size limit.


-- 


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

[Bug libgomp/40047] [4.5 Regression] ICE for libgomp.c++/task-4.C: type mismatch in indirect reference

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-05-06 15:56 ---


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


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug middle-end/39958] [4.5 Regression] OMP tasking creates invalid gimple

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-05-06 15:56 ---
*** Bug 40047 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu dot
   ||org


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

[Bug c++/40048] Compiler crash

[bgalehouse at spamcop dot net]

--- Comment #2 from bgalehouse at spamcop dot net  2009-05-06 16:04 ---
Just found that it seems unrelated to c++0x features. I configured the library
to not require them, and found the 4.4.0 crashes but the system compiler works.
(both running same options, without the -std=c++0x, but otherwise as
previously)

I'm happy to provide additional .ii files and so on if necessary.


-- 

bgalehouse at spamcop dot net changed:

   What|Removed |Added

Summary|Compiler crash possibly |Compiler crash
   |related to --std=c++0x  |


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

[Bug c++/40048] Compiler crash possibly related to --std=c++0x

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-05-06 16:18 ---
Works for me on the branch head.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||4.4.1 4.5.0
 Resolution||WORKSFORME
Summary|Compiler crash  |Compiler crash possibly
   ||related to --std=c++0x


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

[Bug middle-end/32667] builtin operator= generates memcpy with overlapping memory regions

[ppluzhnikov at google dot com]

--- Comment #5 from ppluzhnikov at google dot com  2009-05-06 16:36 ---
(In reply to comment #3)

> Note that this is likely not a problem in practice as 
>  memcpy (p, p, sizeof (*p)) is difficult to implement
> in a way that would make it not work.

>From Julian Seward:

JS> AIUI, POSIX says the src==dst case is not allowed (along with all other
JS> overlapping cases) because (eg) on PowerPC, it is possible to make a high
JS> performance memcpy that preallocates the destination area in D1 using
JS> dcbz instructions, which create the line in D1 and fill it full of
JS> zeroes.  This avoids dragging the destination line up the memory
JS> hierarchy only to completely overwrite it with stuff from the source.
JS>
JS> Result is however that if the src and dst overlap, in any way, including
JS> completely, then this causes zeroes to be written into the src area (!)
JS> which is certainly not what you want.

This bug is likely fixed by:
http://gcc.gnu.org/ml/gcc-patches/2009-04/msg00932.html


-- 


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

[Bug debug/40040] gfortran invalid DW_AT_location for overridable variables

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2009-05-06 16:40 ---
(In reply to comment #2)
> The GDB patch now assembles the symbol name from its parent DW_TAG_module as
> `__modulename_MOD_varname'.  As GDB also has to know the C++ mangling rules I
> believe this Fortran mangling is can be also used from GDB.

Note: The Fortran mangling is highly compiler dependent. Intel's ifort uses
"modulename_mp_varname_", sunf95 uses "modulename.varname_", and g95 and NAG
f95 use "modulename_MP_varname" (however,  the latter two don't create
DW_TAG_module - g95 is based on gcc 4.0.x and NAG f95 uses the system's C
compiler).


-- 


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

[Bug middle-end/40021] [4.5 Regression] Revision 146817 miscompiled DAXPY in BLAS

[matz at gcc dot gnu dot org]

--- Comment #13 from matz at gcc dot gnu dot org  2009-05-06 16:50 ---
Subject: Bug 40021

Author: matz
Date: Wed May  6 16:49:13 2009
New Revision: 147186

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147186
Log:
PR middle-end/40021
* cfgexpand.c (maybe_cleanup_end_of_block): New static function.
(expand_gimple_cond): Use it to cleanup CFG and superfluous jumps.

* gfortran.dg/pr40021.f: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr40021.f
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/40021] [4.5 Regression] Revision 146817 miscompiled DAXPY in BLAS

[matz at gcc dot gnu dot org]

--- Comment #14 from matz at gcc dot gnu dot org  2009-05-06 16:54 ---
Hence, fixed.


-- 

matz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/39986] decimal float constant is incorrect when cc1 is a 64-bit binary

[janis at gcc dot gnu dot org]

--- Comment #4 from janis at gcc dot gnu dot org  2009-05-06 17:01 ---
Subject: Bug 39986

Author: janis
Date: Wed May  6 16:59:53 2009
New Revision: 147188

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147188
Log:
PR middle-end/39986
* dfp.c (encode_decimal32, decode_decimal32, encode_decimal64,
decode_decimal64, encode_decimal128, decode_decimal128): Avoid
32-bit memcpy into long.

* gcc.dg/dfp/pr39986.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/dfp/pr39986.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dfp.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/39986] decimal float constant is incorrect when cc1 is a 64-bit binary

[janis at gcc dot gnu dot org]

--- Comment #5 from janis at gcc dot gnu dot org  2009-05-06 17:18 ---
This was a regression after all, release branches do not have the bug.  I added
the new test case to the 4.4 and 4.3 branches.


-- 

janis at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/40037] gfortran -O3 optimization generates code that seg faults on unaligned array data

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2009-05-06 17:39 ---
(In reply to comment #3)
> The code generated for SMALL is correct, any caller that passes argument not
> aligned on 8 byte boundary (you are mistaken that it requires 16 byte
> alignment,
> try calling it with c(3) which is 8 byte aligned, but not 16 byte aligned and
> it will work too) is invalid.  All DOUBLE PRECISION variables/arrays must be
> properly aligned on 8 byte boundaries.
> 

I believe x86-64 psABI requires that all arrays >= 16byte must be aligned
at 16byte.


-- 


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

[Bug middle-end/40023] type mismatch in address expression

[hjl at gcc dot gnu dot org]

--- Comment #8 from hjl at gcc dot gnu dot org  2009-05-06 17:47 ---
Subject: Bug 40023

Author: hjl
Date: Wed May  6 17:45:40 2009
New Revision: 147195

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147195
Log:
2009-05-06  H.J. Lu  

Backport from mainline:
2009-05-06  H.J. Lu  

PR middle-end/40021
* gfortran.fortran-torture/execute/pr40021.f: New.

2009-05-05  Richard Guenther  

PR middle-end/40023
* gcc.c-torture/compile/pr40023.c: New testcase.

2009-05-03  Richard Guenther  

PR c/39983
* gcc.c-torture/compile/pr39983.c: New testcase.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr39983.c
  - copied unchanged from r147193,
trunk/gcc/testsuite/gcc.c-torture/compile/pr39983.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40023.c
  - copied unchanged from r147194,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40023.c
   
branches/gcc-4_4-branch/gcc/testsuite/gfortran.fortran-torture/execute/pr40021.f
  - copied unchanged from r147193,
trunk/gcc/testsuite/gfortran.fortran-torture/execute/pr40021.f
Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c/39983] ICE: type mismatch in address expression

[hjl at gcc dot gnu dot org]

--- Comment #6 from hjl at gcc dot gnu dot org  2009-05-06 17:47 ---
Subject: Bug 39983

Author: hjl
Date: Wed May  6 17:45:40 2009
New Revision: 147195

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147195
Log:
2009-05-06  H.J. Lu  

Backport from mainline:
2009-05-06  H.J. Lu  

PR middle-end/40021
* gfortran.fortran-torture/execute/pr40021.f: New.

2009-05-05  Richard Guenther  

PR middle-end/40023
* gcc.c-torture/compile/pr40023.c: New testcase.

2009-05-03  Richard Guenther  

PR c/39983
* gcc.c-torture/compile/pr39983.c: New testcase.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr39983.c
  - copied unchanged from r147193,
trunk/gcc/testsuite/gcc.c-torture/compile/pr39983.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40023.c
  - copied unchanged from r147194,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40023.c
   
branches/gcc-4_4-branch/gcc/testsuite/gfortran.fortran-torture/execute/pr40021.f
  - copied unchanged from r147193,
trunk/gcc/testsuite/gfortran.fortran-torture/execute/pr40021.f
Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/40021] [4.5 Regression] Revision 146817 miscompiled DAXPY in BLAS

[hjl at gcc dot gnu dot org]

--- Comment #15 from hjl at gcc dot gnu dot org  2009-05-06 17:47 ---
Subject: Bug 40021

Author: hjl
Date: Wed May  6 17:45:40 2009
New Revision: 147195

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147195
Log:
2009-05-06  H.J. Lu  

Backport from mainline:
2009-05-06  H.J. Lu  

PR middle-end/40021
* gfortran.fortran-torture/execute/pr40021.f: New.

2009-05-05  Richard Guenther  

PR middle-end/40023
* gcc.c-torture/compile/pr40023.c: New testcase.

2009-05-03  Richard Guenther  

PR c/39983
* gcc.c-torture/compile/pr39983.c: New testcase.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr39983.c
  - copied unchanged from r147193,
trunk/gcc/testsuite/gcc.c-torture/compile/pr39983.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40023.c
  - copied unchanged from r147194,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40023.c
   
branches/gcc-4_4-branch/gcc/testsuite/gfortran.fortran-torture/execute/pr40021.f
  - copied unchanged from r147193,
trunk/gcc/testsuite/gfortran.fortran-torture/execute/pr40021.f
Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/17395] [4.5 Regression] Incorrect lookup for parameters

[dodji at gcc dot gnu dot org]

--- Comment #9 from dodji at gcc dot gnu dot org  2009-05-06 18:56 ---
I have submitted a patch for this at
http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00270.html.


-- 


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

[Bug tree-optimization/40049] New: Incorrect tree made for vector shifted by constant on powerpc, spu

[meissner at linux dot vnet dot ibm dot com]

On machines with only a vector/vector shift like the powerpc and spu, the wrong
type is generated for the tree vector that is created with the constant
splat'ed to fill the vector.  The problem is the code uses
get_vectype_for_scalar_type, and integer constants don't have a type.  So
get_vectype_for_scalar_type returns V4SI, even if the vector in question is
V8HI or V16QI.  Before the added type validation was added on April 27th, this
appeared to work because nothing looked at the type field.  With the current
code, this can lead to incorrect code being generated, and for larger programs
the compiler will die due to garbage collection failure.


-- 
   Summary: Incorrect tree made for vector shifted by constant on
powerpc, spu
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: meissner at linux dot vnet dot ibm dot com
 GCC build triplet: powerpc64-unknown-linux-gnu
  GCC host triplet: powerpc64-unknown-linux-gnu
GCC target triplet: powerpc64-unknown-linux-gnu


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

[Bug tree-optimization/40049] Incorrect tree made for vector shifted by constant on powerpc, spu

[meissner at linux dot vnet dot ibm dot com]

--- Comment #1 from meissner at linux dot vnet dot ibm dot com  2009-05-06 
19:08 ---
Created an attachment (id=17811)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17811&action=view)
Patch to fix vector shift by constant on machines with vector/vector shift

This patch fixes the problem in the small case.  While there, I fixed the FIXME
in the next section to use build_constructor instead of
build_constructor_from_list.


-- 


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