[Bug tree-optimization/37525] [4.4 Regression] IVOPTS difference causing 20% degradation in 173.applu benchmark

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2008-10-16 07:14 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug debug/37801] DWARF output for inlined functions doesn't always use DW_TAG_inlined_subroutine

[xuepeng dot guo at intel dot com]

--- Comment #1 from xuepeng dot guo at intel dot com  2008-10-16 07:36 
---
Hello Jason, I posted the whole debug_info section of of the binary file of
your example as below.  I guess you mean that DW_TAG_lexical_block tags like
those at <8c> and <8d> are unnecessary. We should avoid generating them if they
contain nothing. Am I right? 

The section .debug_info contains:

  Compilation Unit @ offset 0x0:
   Length:0x2a2 (32-bit)
   Version:   2
   Abbrev Offset: 0
   Pointer Size:  8
 <0>: Abbrev Number: 1 (DW_TAG_compile_unit)
< c>   DW_AT_producer: (indirect string, offset: 0x58): GNU C 4.4.0
20081005 (experimental) [trunk revision 4110]   
<10>   DW_AT_language: 1(ANSI C)
<11>   DW_AT_name: (indirect string, offset: 0x0): 37801.c  
<15>   DW_AT_comp_dir: (indirect string, offset: 0xd): /home/xguo2/work 
<19>   DW_AT_low_pc  : 0x40045c 
<21>   DW_AT_high_pc : 0x40048b 
<29>   DW_AT_stmt_list   : 0x0  
 <1><2d>: Abbrev Number: 2 (DW_TAG_subprogram)
<2e>   DW_AT_external: 1
<2f>   DW_AT_name: (indirect string, offset: 0x3c): third   
<33>   DW_AT_decl_file   : 1
<34>   DW_AT_decl_line   : 2
<35>   DW_AT_prototyped  : 1
<36>   DW_AT_inline  : 3(declared as inline and inlined)
<37>   DW_AT_sibling : <0x5b>   
 <2><3b>: Abbrev Number: 3 (DW_TAG_formal_parameter)
<3c>   DW_AT_name: (indirect string, offset: 0x53): arg3
<40>   DW_AT_decl_file   : 1
<41>   DW_AT_decl_line   : 2
<42>   DW_AT_type: <0x5b>   
 <2><46>: Abbrev Number: 4 (DW_TAG_variable)
<47>   DW_AT_name: (indirect string, offset: 0x37): var3
<4b>   DW_AT_decl_file   : 1
<4c>   DW_AT_decl_line   : 4
<4d>   DW_AT_type: <0x5b>   
 <2><51>: Abbrev Number: 5 (DW_TAG_variable)
<52>   DW_AT_name: a
<54>   DW_AT_decl_file   : 1
<55>   DW_AT_decl_line   : 5
<56>   DW_AT_type: <0x62>   
 <1><5b>: Abbrev Number: 6 (DW_TAG_base_type)
<5c>   DW_AT_byte_size   : 4
<5d>   DW_AT_encoding: 5(signed)
<5e>   DW_AT_name: int  
 <1><62>: Abbrev Number: 7 (DW_TAG_pointer_type)
<63>   DW_AT_byte_size   : 8
<64>   DW_AT_type: <0x5b>   
 <1><68>: Abbrev Number: 2 (DW_TAG_subprogram)
<69>   DW_AT_external: 1
<6a>   DW_AT_name: (indirect string, offset: 0x42): second  
<6e>   DW_AT_decl_file   : 1
<6f>   DW_AT_decl_line   : 9
<70>   DW_AT_prototyped  : 1
<71>   DW_AT_inline  : 3(declared as inline and inlined)
<72>   DW_AT_sibling : <0x9b>   
 <2><76>: Abbrev Number: 3 (DW_TAG_formal_parameter)
<77>   DW_AT_name: (indirect string, offset: 0x4e): arg2
<7b>   DW_AT_decl_file   : 1
<7c>   DW_AT_decl_line   : 9
<7d>   DW_AT_type: <0x5b>   
 <2><81>: Abbrev Number: 4 (DW_TAG_variable)
<82>   DW_AT_name: (indirect string, offset: 0x32): var2
<86>   DW_AT_decl_file   : 1
<87>   DW_AT_decl_line   : 10   
<88>   DW_AT_type: <0x5b>   
 <2><8c>: Abbrev Number: 8 (DW_TAG_lexical_block)
 <3><8d>: Abbrev Number: 8 (DW_TAG_lexical_block)
 <4><8e>: Abbrev Number: 9 (DW_TAG_variable)
<8f>   DW_AT_abstract_origin: <0x46>
 <4><93>: Abbrev Number: 9 (DW_TAG_variable)
<94>   DW_AT_abstract_origin: <0x51>
 <1><9b>: Abbrev Number: 2 (DW_TAG_subprogram)
<9c>   DW_AT_external: 1
<9d>   DW_AT_name: (indirect string, offset: 0x27): first   
   DW_AT_decl_file   : 1
   DW_AT_decl_line   : 14   
   DW_AT_prototyped  : 1
   DW_AT_inline  : 3(declared as inline and inlined)
   DW_AT_sibling : <0xd7>   
 <2>: Abbrev Number: 3 (DW_TAG_formal_parameter)
   DW_AT_name: (indirect string, offset: 0x49): arg1
   DW_AT_decl_file   : 1
   DW_AT_decl_line   : 14   
   DW_AT_type: <0x5b>   
 <2>: Abbrev Number: 4 (DW_TAG_variable)
   DW_AT_name: (indirect string, offset: 0x2d): var1
   DW_AT_decl_file   : 1
   DW_AT_decl_line   : 15   
   DW_AT_type: <0x5b>   
 <2>: Abbrev Number: 8 (DW_TAG_lexical_block)
 <3>: Abbrev Number: 8 (DW_TAG_lexical_block)
 <4>: Abbrev Number: 9 (DW_TAG_variable)
   DW_AT_abstract_origin: <0x81>
 <4>: Abbrev Number: 8 (DW_TAG_lexical_block)
 <5>: Abbrev Number: 8 (DW_TAG_lexical_block)
 <6>: Abbrev Number: 9 (DW_TAG_variable)
   DW_AT_abstract_origin: <0x46>
 <6>: Abbrev Number: 9 (DW_TAG_variable)
   DW_AT_abstract_origin: <0x51>
 <1>: Abbrev Number: 10 (DW_TAG_subprogram)
   DW_AT_abstract_origin: <0x2d>
   DW_AT_low_pc  : 0x40045c 
   DW_A

[Bug middle-end/37845] New: gcc ignores FP_CONTRACT pragma set to OFF

[vincent at vinc17 dot org]

To be conform to the ISO C standard (when FLT_EVAL_METHOD is 0, 1 or 2, which
is the case of gcc), gcc should either take FP_CONTRACT pragmas into account or
(in the mean time) assume they are set to OFF, i.e. disallow the contraction of
floating expressions. This means in particular that -mno-fused-madd should be
the default (with processors for which this option is supported, e.g. PowerPC).

I've tested with gcc-4.4-20081010 on ia64 that this bug is still present.


-- 
   Summary: gcc ignores FP_CONTRACT pragma set to OFF
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org


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

[Bug middle-end/37846] New: Option -mno-fused-madd should be supported on IA-64

[vincent at vinc17 dot org]

Option -mno-fused-madd is currently not supported on IA-64. This means that the
expression x*y+z is always fused (IA-64's fma instruction) and this cannot be
disabled, unlike on PowerPC.

BTW, I wonder why this option exists for PowerPC (and other CPU types) but not
for IA-64. Isn't it similar, or is there some difficulty?


-- 
   Summary: Option -mno-fused-madd should be supported on IA-64
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org


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

[Bug tree-optimization/37573] [4.4 Regression] gcc-4.4 regression: incorrect code generation with -O1 -ftree-vectorize

[rguenther at suse dot de]

--- Comment #11 from rguenther at suse dot de  2008-10-16 08:14 ---
Subject: Re:  [4.4 Regression] gcc-4.4 regression:
 incorrect code generation with -O1 -ftree-vectorize

On Thu, 16 Oct 2008, spop at gcc dot gnu dot org wrote:

> --- Comment #10 from spop at gcc dot gnu dot org  2008-10-16 00:02 ---
> Subject: Re:  [4.4 Regression] gcc-4.4 regression: incorrect code generation
> with -O1 -ftree-vectorize
> 
> On Wed, Oct 15, 2008 at 4:47 PM, rguenth at gcc dot gnu dot org
> > IMHO the fix for the tuplification bug(!) is to strip the ADDR_EXPR that is
> > always present on op0 in split_constant_offset_1 so:
> >
> >case ADDR_EXPR:
> >  {
> >tree base, poffset;
> >HOST_WIDE_INT pbitsize, pbitpos;
> >enum machine_mode pmode;
> >int punsignedp, pvolatilep;
> >
> >op0 = TREE_OPERAND (op0, 0);
> >if (!handled_component_p (op0))
> >  return false;
> 
> This is exactly what I tried within gdb and it did worked, although
> not as I expected: the base address ends to be &s and not &s.c[0] as
> I expected before.  This then fixes the bug as we end on the same
> base address of the structure.  Then the alias analysis answers that
> the two accesses can overlap.

Yes, but that is another thing.  It also isn't that simple - for any
two accesses you want to disambiguate you have to find a suitable
common base.  Consider &s.c[1] and &s + i, obviously the accesses can
overlap - would you still say so if the base address of the first one
would be &s.c[0]?  (really the base address of a non-variable access
is the access itself, right?  &s.c[1] in this case)

Richard.


-- 


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

[Bug middle-end/37418] [4.4 Regression] error: type mismatch in address expression, verify_gimple failed

[rguenth at gcc dot gnu dot org]

--- Comment #9 from rguenth at gcc dot gnu dot org  2008-10-16 08:20 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/37418] [4.4 Regression] error: type mismatch in address expression, verify_gimple failed

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2008-10-16 08:21 
---
Subject: Bug 37418

Author: rguenth
Date: Thu Oct 16 08:19:49 2008
New Revision: 141165

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141165
Log:
2008-10-16  Joseph Myers  <[EMAIL PROTECTED]>
Richard Guenther  <[EMAIL PROTECTED]>

PR middle-end/37418
* tree-ssa.c (useless_type_conversion_p_1): Do not treat
volatile qualified functions or methods as relevant.

* gcc.c-torture/compile/pr37418-1.c,
gcc.c-torture/compile/pr37418-2.c,
gcc.c-torture/compile/pr37418-3.c,
gcc.c-torture/compile/pr37418-4.c: New tests.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr37418-1.c
trunk/gcc/testsuite/gcc.c-torture/compile/pr37418-2.c
trunk/gcc/testsuite/gcc.c-torture/compile/pr37418-3.c
trunk/gcc/testsuite/gcc.c-torture/compile/pr37418-4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa.c


-- 


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

Abwesenheitsnotiz: [SPAM] ?????????????: ????????????? ? ?????????? ?????? ??????????????? ??????

[joerg.peine]

Vielen Dank für Ihre Mail.

In der Zeit vom 13.10.2008 bis zum 31.10.2008 bin ich nicht im Haus. Meine 
E-Mails werden regelmäßig durch Frau Engel gelesen. 

In meiner Abwesenheit steht Ihnen Herr Andreas Jung (Tel. 02421/47-2857) für 
alle Fragen, die das Segment Handel/Dienstleistungen angehen, gerne zu 
Verfügung. 

Freundliche Grüße  

Jörg Peine

RWE Rhein-Ruhr
Aktiengesellschaft

Standort Düren
Leiter Handel/Dienstleistungen
Neue Jülicher Straße 60, 52353 Düren

T  intern 710 - 28 30
T  extern +49(0)24 21/47 - 28 30
M +49(0)173 / 29 02 866
F  +49-(0)24 21/47 - 21 93
mailto:[EMAIL PROTECTED]

Vorsitzender des Aufsichtsrats: Heinz-Werner Ufer
Vorstand: Dr. Georg Müller (Vorsitzender), Dr. Heinz-Willi Mölders, Dr. Bernd 
Böddeling, Achim Südmeier

Sitz der Gesellschaft: Essen
Eingetragen beim Amtsgericht Essen
Handelsregister -Nr. HRB 14457
Ust-IdNr. DE 1920 00 514

[Bug c++/35483] GCC on AIX doesn't support dollar in symbols name.

[dje at gcc dot gnu dot org]

--- Comment #10 from dje at gcc dot gnu dot org  2008-10-16 11:58 ---
Subject: Bug 35483

Author: dje
Date: Thu Oct 16 11:57:26 2008
New Revision: 141170

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141170
Log:
gcc/
PR target/35483
* Makefile.in (coverage.o): Depend on $(TM_P_H).
* coverage.c: Include tm_p.h.
* config/rs6000/x-aix (jc1): Override LDFLAGS.
* config/rs6000/xcoff.h (ASM_GENERATE_INTERNAL_LABEL): Strip
dollar signs from PREFIX.
* config/rs6000/rs6000.c (output_toc): Use RS6000_OUTPUT_BASENAME
instead of manual strip_name_encoding.

java/
PR target/35483
* Make-lang.in (class.o): Depend on $(TM_P_H).
(expr.o): Same.
* class.c: Include tm_p.h.
* expr.c: Include tm_p.h.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/x-aix
trunk/gcc/config/rs6000/xcoff.h
trunk/gcc/coverage.c
trunk/gcc/java/ChangeLog
trunk/gcc/java/Make-lang.in
trunk/gcc/java/class.c
trunk/gcc/java/expr.c


-- 


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

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[rguenth at gcc dot gnu dot org]

--- Comment #12 from rguenth at gcc dot gnu dot org  2008-10-16 09:44 
---
Turning -frounding-math on by default would be a disservice to (most of) our
users which is why the decision was made (long ago) to not enable this by
default.


-- 


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

[Bug tree-optimization/37664] [4.4 Regression] ice in remove_range_assertions, at tree-vrp.c:5116

[jakub at gcc dot gnu dot org]

--- Comment #10 from jakub at gcc dot gnu dot org  2008-10-16 12:33 ---
Subject: Bug 37664

Author: jakub
Date: Thu Oct 16 12:32:01 2008
New Revision: 141171

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141171
Log:
PR tree-optimization/37664
* fold-const.c (fold_binary): When optimizing comparison with
highest or lowest type's value, don't consider TREE_OVERFLOW.

* gcc.c-torture/compile/pr37664.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr37664.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/37848] New: internal compiler error: Segmentation fault. gfortran openmp

[m dot c dot schaafsma at student dot tudelft dot nl]

The following code generates an internal compiler error on gcc 4.2.3 on
x86_64-linux-gnu

Bug:
  The following bug occurs when:
  -The designated variables are stored in the module
  -Multithreading is applied
  -The final subroutine is called from another subroutine

Command-line:
  gfortran -v -save-temps -g -fopenmp mH_Junctions.f90 Lanczos.f90 -o _Lanczos

Compiler output:

Driving: gfortran -v -save-temps -g -fopenmp mH_Junctions.f90 Lanczos.f90
/usr/lib/liblapack-3.so -o _Lanczos -lgfortranbegin -lgfortran -lm
-shared-libgcc
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)
 /usr/lib/gcc/x86_64-linux-gnu/4.2.3/f951 mH_Junctions.f90 -quiet -dumpbase
mH_Junctions.f90 -mtune=generic -auxbase mH_Junctions -g -version -fopenmp
-fstack-protector -I /usr/lib/gcc/x86_64-linux-gnu/4.2.3/finclude -o
mH_Junctions.s
GNU F95 version 4.2.3 (Ubuntu 4.2.3-2ubuntu7) (x86_64-linux-gnu)
compiled by GNU C version 4.2.3 (Ubuntu 4.2.3-2ubuntu7).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
 as --traditional-format -V -Qy -o mH_Junctions.o mH_Junctions.s
GNU assembler version 2.18.0 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.18.0.20080103
 /usr/lib/gcc/x86_64-linux-gnu/4.2.3/f951 Lanczos.f90 -quiet -dumpbase
Lanczos.f90 -mtune=generic -auxbase Lanczos -g -version -fopenmp
-fstack-protector -I /usr/lib/gcc/x86_64-linux-gnu/4.2.3/finclude -o Lanczos.s
GNU F95 version 4.2.3 (Ubuntu 4.2.3-2ubuntu7) (x86_64-linux-gnu)
compiled by GNU C version 4.2.3 (Ubuntu 4.2.3-2ubuntu7).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Lanczos.f90:26: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see .

mh_Junctions.f90:
MODULE Parameters
IMPLICIT NONE
  INTEGER, parameter   :: dbl = 8
  INTEGER(kind=dbl), parameter :: g_junct = 6
  INTEGER(kind=dbl), parameter :: g_dims  = 6
  INTEGER(kind=dbl) :: g_alpha(g_dims,g_junct)
END MODULE Parameters

Lanczos.f90:
PROGRAM Lanczos
use parameters
IMPLICIT NONE
  call Algorithm()
STOP

CONTAINS

SUBROUTINE Algorithm()
use parameters
IMPLICIT NONE
   CALL ConstructH()
END SUBROUTINE Algorithm

SUBROUTINE ConstructH()
use omp_lib
use parameters
IMPLICIT NONE
  INTEGER(kind=dbl) :: g_Ndim  = 7
  INTEGER(kind=dbl) :: ni, N(g_dims), M(g_dims), l

!$OMP PARALLEL DEFAULT(NONE) &
!$OMP SHARED(g_alpha,g_ndim, g_junct) &
!$OMP PRIVATE(l,ni,M,N)

  DO ni = 1, g_Ndim
DO l = 1, g_junct
  M = N - g_alpha(:,l)
END DO
  END DO
!$OMP END PARALLEL
END SUBROUTINE ConstructH
END PROGRAM Lanczos


-- 
   Summary: internal compiler error: Segmentation fault. gfortran
openmp
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: m dot c dot schaafsma at student dot tudelft dot nl


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

[Bug fortran/37848] internal compiler error: Segmentation fault. gfortran openmp

[m dot c dot schaafsma at student dot tudelft dot nl]

--- Comment #1 from m dot c dot schaafsma at student dot tudelft dot nl  
2008-10-16 12:47 ---
Created an attachment (id=16507)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16507&action=view)
Main fortran routine


-- 


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

[Bug fortran/37848] internal compiler error: Segmentation fault. gfortran openmp

[m dot c dot schaafsma at student dot tudelft dot nl]

--- Comment #2 from m dot c dot schaafsma at student dot tudelft dot nl  
2008-10-16 12:48 ---
Created an attachment (id=16508)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16508&action=view)
fortran module


-- 


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

[Bug c/37849] New: double to array conversion

[hazeman at aster dot pl]

Double conversion to memory and from memory array is broken with O3
optimization enabled. Both functions conv1 ( conversion from double to
uint16_t[4] array ) and conv2 ( conversion from uint16_t array to double ) are
broken. 
To my knowlege the problem also exists in previous versions of gcc/g++ ( I've
used gcc 4.2.4 and 4.1.x on my previous machine (32 bit environment)- and I've
had problems with HPA ( high precision arithmetic ) library with O3 enabled ). 

Correct test program output ( with -O0 ) is
r=(0,0,0,16420)   <- double converted to array
d=10.00   <- double reconverted from array

Enabling optimization -O3 gives 
r=(1600,64,0,0)
d=0.00

Using g++ with -O3 gives
r=(1840,64,0,0)
d=0.00

The following code shows the base of the problem I found in the HPA library.

- test5.c -
#include 
#include 

// move double to array
void conv1( double y, uint16_t* pr )
{
uint16_t*   py;
int i;

py = (uint16_t*)&y;
for(i=0;i<4;i++) pr[i] = py[i];
}

// get double from array
double conv2( uint16_t* pr )
{
uint16_tpa[4];
int i;

for(i=0;i<4;i++) pa[i] = pr[i];

return *((double*)pa);
}

int main( int argc, char* argv[] )
{
uint16_tr[4];
double  d;
int i;

conv1(10.,r);

printf("r=(%i,%i,%i,%i)\n", (int)r[0], (int)r[1], (int)r[2], (int)r[3]);

d = conv2(r);

printf("d=%lf\n", d);
}
- test5.c -

Result of gcc -v -save-temps -O3 test5.c

Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.2-1ubuntu10'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib
--without-included-gettext--enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu10)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-mtune=generic'
 /usr/lib/gcc/x86_64-linux-gnu/4.3.2/cc1 -E -quiet -v test5.c
-D_FORTIFY_SOURCE=2 -mtune=generic -O3 -fpch-preprocess -o test5.i
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../x86_64-linux-gnu/include"
ignoring nonexistent directory "/usr/include/x86_64-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/4.3.2/include
 /usr/lib/gcc/x86_64-linux-gnu/4.3.2/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-mtune=generic'
 /usr/lib/gcc/x86_64-linux-gnu/4.3.2/cc1 -fpreprocessed test5.i -quiet
-dumpbase test5.c -mtune=generic -auxbase test5 -O3 -version -fstack-protector
-o test5.s
GNU C (Ubuntu 4.3.2-1ubuntu10) version 4.3.2 (x86_64-linux-gnu)
compiled by GNU C version 4.3.2, GMP version 4.2.2, MPFR version 2.3.1.
warning: MPFR header version 2.3.1 differs from library version 2.3.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 9fb216f9df26c4d658fb4fb0c8a8291a
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-mtune=generic'
 as -V -Qy -o test5.o test5.s
GNU assembler version 2.18.93 (x86_64-linux-gnu) using BFD version (GNU
Binutils for Ubuntu) 2.18.93.20081009
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-linux-gnu/4.3.2/:/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-mtune=generic'
 /usr/lib/gcc/x86_64-linux-gnu/4.3.2/collect2 --eh-frame-hdr -m elf_x86_64
--hash-style=both -dynamic-linker /lib64/ld-linux-x86-64.so.2 -zrelro
/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib/crt1.o
/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib/crti.o
/usr/lib/gcc/x86_64-linux-gnu/4.3.2/crtbegin.o
-L/usr/lib/gcc/x86_64-linux-gnu/4.3.2 -L/usr/lib/gcc/x86_64-linux-gnu/4.3.2
-L/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib -L/lib/../lib
-L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../.. test5.o -lgcc
--as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/x86_64-linux-gnu/4.3.2/crtend.o
/usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../../lib/crtn.o


-- 
   Summary: double to array conversion
   Product: gcc
   Version: 4.3.2
Stat

[Bug c++/37847] Invalid tree sharing with CHANGE_DYNAMIC_TYPE_EXPR

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-10-16 13:13 ---
Jakub thinks sharing TARGET_EXPRs is valid (unshare_body explicitly doesn't
unshare TARGET_EXPRs just like SAVE_EXPRs).


-- 


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

[Bug fortran/37848] internal compiler error: Segmentation fault. gfortran openmp

[dominiq at lps dot ens dot fr]

--- Comment #3 from dominiq at lps dot ens dot fr  2008-10-16 13:17 ---
gfortran 4.3.2 and 4.4.0 give the following error:

pr37848.f90:32.23:

!$OMP PRIVATE(l,ni,M,N)
  1
Error: Object 'g_junct' is not a variable at (1)

The program compiles (and executes) after removing 'g_junct' from "!$OMP
SHARED(g_alpha,g_ndim, g_junct) &".


-- 


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

[Bug c/37849] double to array conversion

[schwab at suse dot de]

--- Comment #1 from schwab at suse dot de  2008-10-16 13:30 ---


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


-- 

schwab at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE
Summary|double to array conversion  |double to array conversion


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

[Bug c/21920] aliasing violations

[schwab at suse dot de]

--- Comment #130 from schwab at suse dot de  2008-10-16 13:30 ---
*** Bug 37849 has been marked as a duplicate of this bug. ***


-- 

schwab at suse dot de changed:

   What|Removed |Added

 CC||hazeman at aster dot pl


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

[Bug target/37845] gcc ignores FP_CONTRACT pragma set to OFF

[vincent at vinc17 dot org]

--- Comment #3 from vincent at vinc17 dot org  2008-10-16 13:54 ---
(In reply to comment #1)
> Confirmed.  The FP_CONTRACT macro is not implemented, but the default behavior
> of GCC is to behave like it was set to OFF.

The problem is that on PowerPC, x*y+z is fused (contracted) by default (which
is forbidden when FP_CONTRACT is OFF). I could test only with Apple's gcc
4.0.1, but the man page of the gcc snapshot implies that the problem remains
with the current versions:

   IBM RS/6000 and PowerPC Options

   -mfused-madd
   -mno-fused-madd
   Generate code that uses (does not use) the floating point multiply
   and accumulate instructions.  These instructions are generated by
   default if hardware floating is used.

But the correct behavior would be that these instructions should not be
generated by default.

On http://www.vinc17.org/software/tst-ieee754.c compiled with

  gcc -Wall -O2 -std=c99 tst-ieee754.c -o tst-ieee754 -lm

I get:

$ ./tst-ieee754 | grep fused
x * y + z with FP_CONTRACT OFF is fused.

I need to add -mno-fused-madd to get the correct behavior:

$ ./tst-ieee754 | grep fused
x * y + z with FP_CONTRACT OFF is not fused.


-- 


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

[Bug tree-optimization/37705] [graphite] Remove limit_scops() workaround

[spop at gcc dot gnu dot org]

--- Comment #2 from spop at gcc dot gnu dot org  2008-10-16 13:59 ---
I prefer the second solution: if (multiplication_in_parameters (n)) then
insert a new parameter on the BB preceding the scop, and use 
force_gimple_operand to gimplify the sequence of stmts for n.  
This returns a sequence of stmts that you can insert on the src of the 
entry edge of the scop.


-- 


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

[Bug fortran/37850] New: FAIL: gfortran.dg/c_by_val_1.f & gfortran.dg/value_4.f90 execution test

[mikael dot morin at tele2 dot fr]

I have seen nothing about it on the list yet, so I guess I'm the only one
impacted. 
Can someone confirm ?
I'll investigate and provide more information later. 


FAIL: gfortran.dg/c_by_val_1.f  -O0  execution test
FAIL: gfortran.dg/c_by_val_1.f  -O1  execution test
FAIL: gfortran.dg/c_by_val_1.f  -O2  execution test
FAIL: gfortran.dg/c_by_val_1.f  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/c_by_val_1.f  -O3 -fomit-frame-pointer -funroll-loops 
execution test
FAIL: gfortran.dg/c_by_val_1.f  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
FAIL: gfortran.dg/c_by_val_1.f  -O3 -g  execution test
FAIL: gfortran.dg/c_by_val_1.f  -Os  execution test
FAIL: gfortran.dg/value_4.f90  -O0  execution test
FAIL: gfortran.dg/value_4.f90  -O1  execution test
FAIL: gfortran.dg/value_4.f90  -O2  execution test
FAIL: gfortran.dg/value_4.f90  -O3 -fomit-frame-pointer  execution test
FAIL: gfortran.dg/value_4.f90  -O3 -fomit-frame-pointer -funroll-loops 
execution test
FAIL: gfortran.dg/value_4.f90  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
FAIL: gfortran.dg/value_4.f90  -O3 -g  execution test
FAIL: gfortran.dg/value_4.f90  -Os  execution test


-- 
   Summary: FAIL: gfortran.dg/c_by_val_1.f & gfortran.dg/value_4.f90
execution test
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikael dot morin at tele2 dot fr
  GCC host triplet: x86_64-unknown-linux-gnu


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

[Bug fortran/37827] Fortran IO structure - compiler vs. library (libgfortran) [requires ABI breaking?]

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2008-10-16 10:01 ---
Duplicate of 37839?


-- 


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

[Bug fortran/37848] internal compiler error: Segmentation fault. gfortran openmp

[m dot c dot schaafsma at student dot tudelft dot nl]

--- Comment #4 from m dot c dot schaafsma at student dot tudelft dot nl  
2008-10-16 14:14 ---
Thanks for your adequate respons!
I'll implement your suggestion.


-- 


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

[Bug fortran/37835] -fno-automatic does not work for derived types with default initalizer

[burnus at gcc dot gnu dot org]

--- Comment #3 from burnus at gcc dot gnu dot org  2008-10-16 09:41 ---
Hmm, maybe the wording could (should?) be changed to make clear that for
  subroutine sub(n)
 integer n
 real automatic_data_object(n)
  end subroutine sub
the automatic_data_object gets no SAVE with -fno-automatic. (It doesn't and I
have no idea how it could, but seemingly one can read the option such that it
would.)


-- 


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

[Bug target/37845] gcc ignores FP_CONTRACT pragma set to OFF

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2008-10-16 09:42 ---
The fma patterns on ia64 are not guarded properly.  They should be off
as long as flag_unsafe_math_optimizations is not specified.


-- 


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

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[vincent at vinc17 dot org]

--- Comment #14 from vincent at vinc17 dot org  2008-10-16 14:20 ---
(In reply to comment #12)
> Turning -frounding-math on by default would be a disservice to (most of) our
> users which is why the decision was made (long ago) to not enable this by
> default.

The compiler should generate correct code by default, and options like
-funsafe-math-optimizations are there to allow the users to run the compiler in
a non-conforming mode. So, it would be wise to have -frounding-math by default
and add -fno-rounding-math to the options enabled by
-funsafe-math-optimizations.


-- 


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

[Bug fortran/37850] FAIL: gfortran.dg/c_by_val_1.f & gfortran.dg/value_4.f90 execution test

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2008-10-16 14:39 ---
> ... so I guess I'm the only one impacted. ...

Which revision? I don't have gfortran regression at r141150 on
i686-apple-darwin9 and r141139 powerpc-apple-darwin9.


-- 


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

[Bug c++/37847] New: Invalid tree sharing with CHANGE_DYNAMIC_TYPE_EXPR

[rguenth at gcc dot gnu dot org]

The C++ FE builds from the following testcase:

typedef long unsigned int size_t;
void* operator new(size_t, void* __p);
class locale {
public:
class facet;
const facet** _M_facets;
locale(size_t);
};
typedef char fake_facet_vec[128];
fake_facet_vec facet_vec;
locale::locale(size_t __refs)
{
  _M_facets = new (&facet_vec) const facet*;
}

the following trees with -fstrict-aliasing:

{
  <_M_facets = (<<)>>>, (const struct facet *
*) operator new (8, (void *) TARGET_EXPR );)) >>>
>>;
}

where the TARGET_EXPR  tree is shared, and this is the
only reason the code works after gimplifying and it does not ICE during
gimplification.  If you unshare the trees the gimplifier ICEs in
gimple_add_tmp_var, at gimplify.c:827 because D.2102 is used twice as the
target of a TARGET_EXPR.

Obviously the IL construct emitted by the frontend is completely bogus in
this case.


-- 
   Summary: Invalid tree sharing with CHANGE_DYNAMIC_TYPE_EXPR
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org


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

[Bug target/37846] Option -mno-fused-madd should be supported on IA-64

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-10-16 09:43 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|middle-end  |target
 Ever Confirmed|0   |1
 GCC target triplet||ia64-*-*
   Last reconfirmed|-00-00 00:00:00 |2008-10-16 09:43:19
   date||


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

[Bug c++/37847] Invalid tree sharing with CHANGE_DYNAMIC_TYPE_EXPR

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-10-16 09:24 ---
A solution would be to wrap the placement in a SAVE_EXPR in all callers of
avoid_placement_new_aliasing, thus the following seems to fix it:

Index: init.c
===
*** init.c  (revision 141164)
--- init.c  (working copy)
*** build_new_1 (tree placement, tree type,
*** 2041,2046 
--- 2041,2047 
  || VOID_TYPE_P (TREE_TYPE (TREE_TYPE (placement_arg
{
  placement_expr = get_target_expr (TREE_VALUE (placement));
+ placement_expr = save_expr (placement_expr);
  CALL_EXPR_ARG (alloc_call, 1)
= convert (TREE_TYPE (placement_arg), placement_expr);
}


-- 

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|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-10-16 09:24:15
   date||


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

[Bug middle-end/37851] New: [graphite] ICE in expand_scalar_variables_expr, at graphite.c:3617

[dwarak dot rajagopal at amd dot com]

gfortran -O2 -floop-block 939.f90 
939.f90: In function 'solvep':
939.f90:6: internal compiler error: in expand_scalar_variables_expr, at
graphite.c:3617
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

This was tested on the graphite branch. The reduced testcase from polyhedron
benchmark is attached.

- Dwarak


-- 
   Summary: [graphite] ICE in expand_scalar_variables_expr, at
graphite.c:3617
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dwarak dot rajagopal at amd dot com
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug middle-end/37851] [graphite] ICE in expand_scalar_variables_expr, at graphite.c:3617

[dwarak dot rajagopal at amd dot com]

--- Comment #1 from dwarak dot rajagopal at amd dot com  2008-10-16 15:00 
---
Created an attachment (id=16509)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16509&action=view)
Testcase


-- 


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

[Bug libfortran/34670] bounds checking for array intrinsics

[tkoenig at gcc dot gnu dot org]

--- Comment #10 from tkoenig at gcc dot gnu dot org  2008-10-16 10:18 
---
Subject: Bug 34670

Author: tkoenig
Date: Thu Oct 16 10:16:38 2008
New Revision: 141167

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141167
Log:
2008-10-16  Thomas Koenig  <[EMAIL PROTECTED]>

PR libfortran/34670
* generated/spread_r4.c: Regenerated.


Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/generated/spread_r4.c


-- 


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

[Bug libfortran/37839] st_parameter_dt has unwanted padding, is out of sync with compiler

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2008-10-16 10:01 ---
The same as PR 37827.

Richard writes there:
"You cannot touch the library part, but you certainly can align what the
compiler does to the library part of the structure definition.  Thus, if the
behavior is wrong (as in wrong-code) at the moment, changing the "ABI" only in
parts that affect the wrong-code bug certainly is ok."


-- 


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

[Bug fortran/37835] -fno-automatic does not work for derived types with default initalizer

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2008-10-16 09:37 ---
Regarding -fno-automatic, James Van Buskirk suggested to compare the details
with ifort's -save (see URL above):

"The description in my admittedly old version of ifort documentation
allows for different semantics for ifort /Qsave and gfortran
-fno-automatic.  The former says only that it saves all variables in
static allocation except local variables within a recursive routine
and variables declare as AUTOMATIC.  This is not the same as treating
every program unit except those marked as RECURSIVE as if the SAVE
statement were specified for every local variable and array
referenced in it.  For example ifort leaves open the possibility
of reinitializing instances of user-defined types with default
initialization and gfortran does not.  This on the one hand permits
standard-conforming code to behave the same way with /Qsave specified
whereas the change should be detectable for -fno-automatic but on
the other hand creates an ambiguity as to whether ifort actually does
leave the semantics of standard-conforming code intact as it doesn't
say whether it does or not in the documentation.

It might be useful for the gfortran team to compare with ifort and
determine whether they want to maintain semantics of standard-conforming
code before considering failure to change semantics to be a bug.  Of
course the documentation would have to be rewritten if the decision
were made to change the behavior.  Sometimes it's just so difficult to
rewrite the documentation that a documented bad behavior gets left
intact.  For example in the original f90 standard, non-advancing I/O
was specified to advance on format reversion due to a carry-over from
f77 that had no non-advancing I/O.  I imagine everyone tries to write
non-advancing I/O taking for granted that format reversion also does
not advance to the next record and indeed early f90 compilers behaved
in just this way.  However the simply-worded standard says otherwise
and rather than fix this bug in the standard the compilers got 'fixed'
so that now format reversion is just useless in conjunction with non-
advancing I/O."

Wording of gfortran:
http://gcc.gnu.org/onlinedocs/gfortran/Code-Gen-Options.html

Wording of ifort:
"This option saves all variables in static allocation except local variables
within a recursive routine and variables declared as AUTOMATIC."
http://www.intel.com/software/products/compilers/docs/flin/main_for/mergedProjects/copts_for/fortran_options/option_save.htm

I think gfortran's wording implies that derived-types are SAVEd, ifort's is a
bit more ambiguous, but ifort does the do so. Thus I think it might be enough
to fix the 'bug' as stated in comment 0.


-- 


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

[Bug fortran/37848] internal compiler error: Segmentation fault. gfortran openmp

[m dot c dot schaafsma at student dot tudelft dot nl]

--- Comment #5 from m dot c dot schaafsma at student dot tudelft dot nl  
2008-10-16 15:06 ---
I implemented your suggestion, but with little success.
Removing the variable results in the same error.
I need to use variables declared in an external module in a multi threaded
loop.
Somehow my compiler can't manage it.


-- 


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

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[merkert at comcast dot net]

--- Comment #13 from merkert at comcast dot net  2008-10-16 11:56 ---
Would it make sense to have a function attribute to indicate that rounding mode
was changed as a side effect? This way, one could keep the default rounding
behavior and not incur a performance penalty, but at the same time
setroundingmode would work as expected.


-- 


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

[Bug fortran/37848] internal compiler error: Segmentation fault. gfortran openmp

[dominiq at lps dot ens dot fr]

--- Comment #6 from dominiq at lps dot ens dot fr  2008-10-16 15:16 ---
> Somehow my compiler can't manage it.

Could you try a more recent version: 4.3.2 or 4.4.0: as I said in comment #3,
the ICE has ben replaced by an error (I am not fluent enough with openmp to say
if it is right or not).

Note that very few fixes (if none) are backported to 4.2.


-- 


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

[Bug target/37845] gcc ignores FP_CONTRACT pragma set to OFF

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2008-10-16 09:40 ---
Confirmed.  The FP_CONTRACT macro is not implemented, but the default behavior
of GCC is to behave like it was set to OFF.

This is a target issue (sofar ia64 is identified as buggy).


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||37846
 Status|UNCONFIRMED |NEW
  Component|middle-end  |target
 Ever Confirmed|0   |1
 GCC target triplet||ia64-*-*
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2008-10-16 09:40:12
   date||


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

[Bug libfortran/37839] st_parameter_dt has unwanted padding, is out of sync with compiler

[sje at cup dot hp dot com]

--- Comment #3 from sje at cup dot hp dot com  2008-10-16 15:23 ---
While changing the compiler would not break the ABI it seems like it would be
pretty difficult.  It looks to me like the compiler is building the
offsets/fields based on the types in ioparm.def and assumes no padding.  I want
to add padding but only in 32 bit mode and only on some platforms.


-- 


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

[Bug libfortran/37839] st_parameter_dt has unwanted padding, is out of sync with compiler

[dominiq at lps dot ens dot fr]

--- Comment #4 from dominiq at lps dot ens dot fr  2008-10-16 15:32 ---
> I want to add padding but only in 32 bit mode and only on some platforms.

Are not these information provided by the config steps, hence available when
building gfortran?


-- 


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

[Bug middle-end/37852] New: [graphite] ICE in gbb_loop_index, at graphite.h:252

[mitul dot thakkar at amd dot com]

gfortran -floop-block -O2 final_test_fpu.f90
final_test_fpu.f90: In function 'gauss':
final_test_fpu.f90:7: internal compiler error: in gbb_loop_index, at
graphite.h:252
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

This was tested on the graphite branch. The reduced testcase from polyhedron
benchmark is attached.

-Mitul


-- 
   Summary: [graphite] ICE in gbb_loop_index, at graphite.h:252
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mitul dot thakkar at amd dot com
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug middle-end/37852] [graphite] ICE in gbb_loop_index, at graphite.h:252

[mitul dot thakkar at amd dot com]

--- Comment #1 from mitul dot thakkar at amd dot com  2008-10-16 15:37 
---
Created an attachment (id=16510)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16510&action=view)
Testcase


-- 


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

[Bug middle-end/37853] New: gcc.dg/vect/vect-67.c failing since PRE rewrite

[sje at cup dot hp dot com]

This test is failing on several platforms, IA64, x86_64, and PowerPC.  On IA64
the failures started with r137631 which was the PRE rewrite.  There was some
discussion of test failures when this change went in but I didn't see any
mention of this particular test.

See http://gcc.gnu.org/ml/gcc-patches/2008-07/msg01638.html


-- 
   Summary: gcc.dg/vect/vect-67.c failing since PRE rewrite
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sje at cup dot hp dot com


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

Re: [Bug target/37845] gcc ignores FP_CONTRACT pragma set to OFF

[Andrew Thomas Pinski]

Sent from my iPhone

On Oct 16, 2008, at 2:42 AM, "rguenth at gcc dot gnu dot org" <[EMAIL PROTECTED] 
> wrote:





--- Comment #2 from rguenth at gcc dot gnu dot org  2008-10-16  
09:42 ---

The fma patterns on ia64 are not guarded properly.  They should be off
as long as flag_unsafe_math_optimizations is not specified.


No that is not true. They should be on by default.





--


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

[Bug target/37845] gcc ignores FP_CONTRACT pragma set to OFF

[pinskia at gmail dot com]

--- Comment #4 from pinskia at gmail dot com  2008-10-16 15:40 ---
Subject: Re:  gcc ignores FP_CONTRACT pragma set to OFF



Sent from my iPhone

On Oct 16, 2008, at 2:42 AM, "rguenth at gcc dot gnu dot org"
<[EMAIL PROTECTED] 
 > wrote:

>
>
> --- Comment #2 from rguenth at gcc dot gnu dot org  2008-10-16  
> 09:42 ---
> The fma patterns on ia64 are not guarded properly.  They should be off
> as long as flag_unsafe_math_optimizations is not specified.

No that is not true. They should be on by default.

>
>
>
> -- 
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37845
>


-- 


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

[Bug tree-optimization/37705] [graphite] Remove limit_scops() workaround

[spop at gcc dot gnu dot org]

--- Comment #3 from spop at gcc dot gnu dot org  2008-10-16 15:46 ---
Created an attachment (id=16511)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16511&action=view)
patch for solution 2

Patch as discussed at today's graphite call: detect multiplications of
parameters, then gimplify and add new parameters for these multiplication
expressions. 


-- 


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

[Bug middle-end/37853] gcc.dg/vect/vect-67.c failing since PRE rewrite

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2008-10-16 15:49 ---
Fails also on PPC/Intel Darwin9, 32 and 64 bit modes. The first time I see the
failure is for r137631 (Intel).


-- 


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

[Bug fortran/37848] internal compiler error: Segmentation fault. gfortran openmp

[burnus at gcc dot gnu dot org]

--- Comment #7 from burnus at gcc dot gnu dot org  2008-10-16 15:53 ---
(In reply to comment #3)
> gfortran 4.3.2 and 4.4.0 give the following error:
> pr37848.f90:32.23:
> !$OMP PRIVATE(l,ni,M,N)
>   1
> Error: Object 'g_junct' is not a variable at (1)

That error message was added for PR 35786 (fixed in April 2008 for 4.4.0 and
4.3.x).

(In reply to comment #6)
> > Somehow my compiler can't manage it.
> Could you try a more recent version: 4.3.2 or 4.4.0

That would also be my suggestion as there have been a couple of other OpenMP
fixes. (By the way: GCC 4.4 also already supports OpenMP version 3.0.)


-- 


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

[Bug c++/37854] New: No error when creating a variable from itself

[julien dot sagnard at gmail dot com]

If I try to compile this code:

class X {};

int main {
  int i = i;
  X x = x;
  X y(y);
  return 0;
}

With:
gcc -Wall main.cpp

There is no error and no warning.


INFOS:

OS:
Ubuntu Hardy

gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--enable-targets=all --enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)

uname -a
Linux VmWare-Ubuntu 2.6.24-19-generic #1 SMP Fri Jul 11 23:41:49 UTC 2008 i686
GNU/Linux


-- 
   Summary: No error when creating a variable from itself
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: julien dot sagnard at gmail dot com


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

[Bug c++/37854] No error when creating a variable from itself

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2008-10-16 16:16 
---


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


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/37854] No error when creating a variable from itself

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2008-10-16 16:18 
---
Oops, sorry.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|DUPLICATE   |


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

[Bug c++/34772] [4.2/4.3/4.4 Regression] self-initialisation does not silence uninitialised warnings (-Winit-self ignored)

[paolo dot carlini at oracle dot com]

--- Comment #11 from paolo dot carlini at oracle dot com  2008-10-16 16:16 
---
*** Bug 37854 has been marked as a duplicate of this bug. ***


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||julien dot sagnard at gmail
   ||dot com


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

[Bug c++/37854] No error when creating a variable from itself

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2008-10-16 16:22 
---
In mainline (would be 4.4.0), with -Winit-self a warning is emitted for line 4
only. EDG-based compilers apparently do the same...


-- 


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

[Bug target/37845] gcc ignores FP_CONTRACT pragma set to OFF

[joseph at codesourcery dot com]

--- Comment #5 from joseph at codesourcery dot com  2008-10-16 16:31 ---
Subject: Re:  gcc ignores FP_CONTRACT pragma set to OFF

On Thu, 16 Oct 2008, rguenth at gcc dot gnu dot org wrote:

> Confirmed.  The FP_CONTRACT macro is not implemented, but the default behavior
> of GCC is to behave like it was set to OFF.

No, the default is to behave like it is ON, on targets with fused 
operations, with target-specific options to turn it off.  A default of ON 
is fine according to C99.

It so happens that GCC's version of "ON" is buggy, in that it contracts 
even outside the bounds of source language expressions - those boundaries 
are lost at gimplification, long before the insn patterns are applied.  
Fixing this would probably require fused operations to be identified in 
the front end in conforming mode, and the only insn patterns in conforming 
mode for the fused instructions to have RTL describing them precisely as 
fused operations so non-fused ones don't get combined.

This situation is much like the other floating-point pragmas:

* GCC doesn't support any of the pragmas, and doesn't claim to support 
those parts of C99; the features can only be enabled or disabled for a 
whole translation unit on the command line.

* The features for a whole translation unit are in practice rather buggy 
and incomplete.  -fno-cx-limited-range (on by default) doesn't work for 
constant arithmetic (bug 30789).  -ftrapping-math (on by default) doesn't 
cause all required exceptions to be generated, and spurious exceptions are 
generated in some cases; no real effort has been made to get it to work 
properly in all cases.  -frounding-math (off by default) comes with a 
specific warning in the manual that it's experimental and incomplete, 
which is quite correct.

Yes, there should be a target-independent option to disable contracting 
rather than needing separate options for each target, and in conformance 
mode (flag_iso) contracting, if enabled, should be restricted to source 
language expressions.  I'm not aware of anyone working on this, or on the 
other issues with the options approximating to the standard pragmas, or on 
the pragmas themselves.


-- 


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

[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS

[domob at gcc dot gnu dot org]

--- Comment #6 from domob at gcc dot gnu dot org  2008-10-16 16:32 ---
Fixed the accepts-invalid mentioned in comment #1 (patch posted at
http://gcc.gnu.org/ml/fortran/2008-10/msg00145.html) on trunk, but the main
problem here is still there, I'll start to work on it directly now.


-- 


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

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[joseph at codesourcery dot com]

--- Comment #15 from joseph at codesourcery dot com  2008-10-16 16:39 
---
Subject: Re:  Optimization generates incorrect code
 with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

On Thu, 16 Oct 2008, vincent at vinc17 dot org wrote:

> The compiler should generate correct code by default, and options like

Sure, it generates correct code for the supported features, and 
, which is linked from the manual, 
documents the state of support for the features: standard pragmas are 
documented as Missing and IEC 60559 support as Broken, with the 
explanation:

 * IEC 60559 is IEEE 754 floating point. This works if and only if
   the hardware is perfectly compliant, but GCC does not define
   __STDC_IEC_559__ or implement the associated standard pragmas; nor
   do some options such as -frounding-math to enable the pragmas
   globally work in all cases (for example, required exceptions may
   not be generated) and contracting expressions (e.g., using fused
   multiply-add) is not restricted to source-language expressions as
   required by C99.

So you are using features documented not to be fully implemented and 
whether they will work is unpredictable.


-- 


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

[Bug c/33192] __imag operator drops side effects in subexpr

[jsm28 at gcc dot gnu dot org]

--- Comment #3 from jsm28 at gcc dot gnu dot org  2008-10-16 17:07 ---
Subject: Bug 33192

Author: jsm28
Date: Thu Oct 16 17:05:57 2008
New Revision: 141176

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141176
Log:
PR c/33192
* c-typeck.c (build_unary_op): Use omit_one_operand for
IMAGPART_EXPR of real argument.

testsuite:
* gcc.dg/imag-1.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/imag-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-typeck.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c/33192] __imag operator drops side effects in subexpr

[jsm28 at gcc dot gnu dot org]

--- Comment #4 from jsm28 at gcc dot gnu dot org  2008-10-16 17:12 ---
Fixed for 4.4.


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug target/37381] [4.4 Regression] ICE in ia64_speculate_insn, at config/ia64/ia64.c:6902

[amonakov at gcc dot gnu dot org]

--- Comment #12 from amonakov at gcc dot gnu dot org  2008-10-16 17:31 
---
Subject: Bug 37381

Author: amonakov
Date: Thu Oct 16 17:30:06 2008
New Revision: 141177

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141177
Log:
2008-10-16  Alexander Monakov  <[EMAIL PROTECTED]>

PR target/37381
* gcc.c-torture/compile/pr37381.c: New test.


Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr37381.c
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)

[vincent at vinc17 dot org]

--- Comment #16 from vincent at vinc17 dot org  2008-10-16 17:39 ---
I was suggesting to improve the behavior by having -frounding-math by default
(at least when the user compiles with -std=c99 -- if he does this, then this
means that he shows some interest in a conforming implementation). This is not
perfect, but would be better than the current behavior.


-- 


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

[Bug target/37381] [4.4 Regression] ICE in ia64_speculate_insn, at config/ia64/ia64.c:6902

[amonakov at gcc dot gnu dot org]

--- Comment #13 from amonakov at gcc dot gnu dot org  2008-10-16 17:42 
---
H.J., thanks for reminding.  Closing again.


-- 

amonakov at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


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

[Bug libgcj/37856] New: Abort with: Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS

[doko at ubuntu dot com]

see PR37855 for the use case (building icedtea --with-alt-jar=gjar

$ /usr/bin/gjar c0mf
/scratch/packages/openjdk/d/icedtest/openjdk/control/build/linux-i586/tmp/manifest.tmp
/scratch/packages/openjdk/d/icedtest/openjdk/control/build/linux-i586/tmp/rt-orig.jar
@/scratch/packages/openjdk/d/icedtest/openjdk/control/build/linux-i586/tmp/jarfilelists/rt_jar_list_args
-J-client -J-Xmx896m -J-Xms128m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m
Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS
Aborted

In the past there was some dicussion about setting LARGE_CONFIG, see
http://gcc.gnu.org/ml/java-patches/2005-q4/msg00149.html
and in the followup:

"For the branch, I wanted to solve the problem while making the least intrusive
change possible. On HEAD, it sounds like LARGE_CONFIG is the way to go. I will
test a patch shortly and reverse the MAX_ROOT_SETS change there."


-- 
   Summary: Abort with: Too many heap sections: Increase MAXHINCR or
MAX_HEAP_SECTS
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: doko at ubuntu dot com


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

[Bug debug/37801] DWARF output for inlined functions doesn't always use DW_TAG_inlined_subroutine

[jason at redhat dot com]

--- Comment #2 from jason at redhat dot com  2008-10-16 18:22 ---
Subject: Re:  DWARF output for inlined functions doesn't
 always use DW_TAG_inlined_subroutine

xuepeng dot guo at intel dot com wrote:
> Hello Jason, I posted the whole debug_info section of of the binary file of
> your example as below.  I guess you mean that DW_TAG_lexical_block tags like
> those at <8c> and <8d> are unnecessary. We should avoid generating them if 
> they
> contain nothing. Am I right? 

No; they aren't empty, they contain a couple of variables.  But they 
come from an inlined function ("third"), and we shouldn't represent 
inlined functions in the debug info for the abstract instance of an 
inline function.

Jason


-- 


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

[Bug debug/33429] debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always

[jason at redhat dot com]

--- Comment #10 from jason at redhat dot com  2008-10-16 18:40 ---
Subject: Re:  debug info for class2 in g++.dg/other/unused1.C
  requires -femit-class-debug-always

mark at codesourcery dot com wrote:
> The library is provided to us in binary form and stripped, and if it
> does have debug info it might not have come from GCC.  But, if it's
> declared in a header, we can still provide debug info.

In which case we need to specify -femit-class-debug-always, yes.

> OK, my statement was overly strong.  I was thinking particularly of C++
> templates, where the vague linkage strategy makes for lots of copies,
> both in the object files, and, because we don't use COMDAT, in the final
> binaries.  In that kind of C++ code, this optimization doesn't save a
> significant percentage of space.

I wouldn't expect it to make a big difference with heavily templated 
code, no.

It seems to me that you're arguing that -femit-class-debug-always should 
go back to being on by default; its only effect is to control this exact 
optimization.  But the documentation says

--
This option
should be used only with debuggers that are unable to handle the way GCC
normally emits debugging information for classes because using this
option will increase the size of debugging information by as much as a
factor of two.
--

Does anyone have some recent numbers?

Jason


-- 


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

[Bug middle-end/37857] New: [graphite] Segmentation fault

[mitul dot thakkar at amd dot com]

gfortran -O2 -floop-block  final_protein.f90

final_protein.f90: In function 'superficie_proteina':
final_protein.f90:1: error: type mismatch between an SSA_NAME and its symbol
final_protein.f90:1: internal compiler error: Segmentation fault


-- 
   Summary: [graphite] Segmentation fault
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mitul dot thakkar at amd dot com
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug middle-end/37857] [graphite] Segmentation fault

[mitul dot thakkar at amd dot com]

--- Comment #1 from mitul dot thakkar at amd dot com  2008-10-16 18:38 
---
Created an attachment (id=16512)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16512&action=view)
Reduced Test Case


-- 


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

[Bug c++/37854] No error when creating a variable from itself

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2008-10-16 19:08 ---
In this case since x and y are empty structs there are no real uses of them.
If I change the code to:
struct X {int i;};

int main()
{
  int i = i;
  X x = x;
  X y(y);
  return i+x.i+y.i;
}
--- CUT ---
And turn on optimization, I get the following warnings:
t.c: In function 'int main()':
t.c:5: warning: 'i' is used uninitialized in this function
t.c:8: warning: 'x.X::i' is used uninitialized in this function
t.c:8: warning: 'y.X::i' is used uninitialized in this function


Note all of the above warnings should only happen with -Winit-self (which works
correctly with the C front-end and is PR 34772 ).


-- 


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

[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected

[dje at gcc dot gnu dot org]

--- Comment #3 from dje at gcc dot gnu dot org  2008-10-16 20:12 ---
I see the same failure on AIX that just restored Java support.

On AIX, _Jv_CheckABI is invoked with version argument of 0 instead of 404000
GCC version constant.


-- 

dje at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dje at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-10-16 20:12:35
   date||


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

[Bug fortran/37850] FAIL: gfortran.dg/c_by_val_1.f & gfortran.dg/value_4.f90 execution test

[tkoenig at gcc dot gnu dot org]

--- Comment #2 from tkoenig at gcc dot gnu dot org  2008-10-16 20:20 ---
I can't reproduce this with today's trunk, rev. 141180

Any more details?


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug debug/33429] debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always

[mark at codesourcery dot com]

--- Comment #11 from mark at codesourcery dot com  2008-10-16 20:37 ---
Subject: Re:  debug info for class2 in g++.dg/other/unused1.C
  requires -femit-class-debug-always

jason at redhat dot com wrote:

> It seems to me that you're arguing that -femit-class-debug-always should 
> go back to being on by default; its only effect is to control this exact 
> optimization.

If that's the only effect, then, yes, I guess that's what I'm arguing.

> Does anyone have some recent numbers?

That would certainly be helpful.


-- 


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

[Bug rtl-optimization/35729] const volatile variable access incorrectly hoisted out of loop

[sje at cup dot hp dot com]

--- Comment #7 from sje at cup dot hp dot com  2008-10-16 21:32 ---
The new test that was added fails for me on ia64-*-* platforms too.  It looks
like the fix for the original bug is right in that it is preventing the
volatile assignment in being moved but the test is bad because other
instructions (not involving the volatile variable) are being moved out of the
loop so the test does see the "Decided to move invariant" string in the loop
dump file.  The information in this file doesn't seem to be specific enough to
allow for an easy way to check whether the assignment of g_361 specifically was
or was not moved.  If I compile with -O2 instead of -Os then I don't see any
invariant code motion but I don't know if that is a way to fix the test or not
since the original bug involved -Os.


-- 

sje at cup dot hp dot com changed:

   What|Removed |Added

 CC||sje at cup dot hp dot com


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

[Bug target/37843] [4.4 Regression] unaligned stack in main due to tail call optimization

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2008-10-16 22:14 ---
An updated patch is at

http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00724.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

URL|http://gcc.gnu.org/ml/gcc-  |http://gcc.gnu.org/ml/gcc-
   |patches/2008-   |patches/2008-
   |10/msg00670.html|10/msg00724.html


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

Problem building gcc 3.4.6 on 64 bit linux machine

[Leonard J. Reder]

Hello,

I have a code that requires gcc 3.4.6 to compile it so I am attempting 
to build for my fedora 9 64 bit linux machine.  It is having trouble 
doing this:


gcc -c   -g -O2 -DIN_GCC -DCROSS_COMPILE  -W -Wall -Wwrite-strings 
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long 
-DHAVE_CONFIG_H-I. -I. -I../../gcc -I../../gcc/. 
-I../../gcc/../include  ../../gcc/cppspec.c -o cppspec.o
gcc   -g -O2 -DIN_GCC -DCROSS_COMPILE  -W -Wall -Wwrite-strings 
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long 
-DHAVE_CONFIG_H  -o cpp gcc.o cppspec.o intl.o \

  prefix.o version.o  ../libiberty/libiberty.a
/home/dlab/pkgs/src/gcc/gcc-3.4.6/gobj/gcc/xgcc 
-B/home/dlab/pkgs/src/gcc/gcc-3.4.6/gobj/gcc/ 
-B/home/dlab/pkgs/src/gcc/3.4.6/x86_64-redhat-linux/bin/ 
-B/home/dlab/pkgs/src/gcc/3.4.6/x86_64-redhat-linux/lib/ -isystem 
/home/dlab/pkgs/src/gcc/3.4.6/x86_64-redhat-linux/include -isystem 
/home/dlab/pkgs/src/gcc/3.4.6/x86_64-redhat-linux/sys-include -dumpspecs 
> tmp-specs

mv tmp-specs specs
if [ -f specs.ready ] ; then \
true; \
else \
echo timestamp > specs.ready; \
fi
(MAKE="make"; srcdir=`cd ../../gcc/fixinc && ${PWDCMD-pwd}` ; \
	CC="gcc"; CFLAGS="  -g -O2 -DIN_GCC -DCROSS_COMPILE  -W -Wall 
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic 
-Wno-long-long  -Wno-error  -DHAVE_CONFIG_H -DGENERATOR_FILE"; LDFLAGS=""; \
	WARN_CFLAGS="-W -Wall -Wwrite-strings -Wstrict-prototypes 
-Wmissing-prototypes -pedantic -Wno-long-long  -Wno-error"; 
LIBERTY=`${PWDCMD-pwd}`/"../libiberty/libiberty.a"; \

export MAKE srcdir CC CFLAGS LDFLAGS WARN_CFLAGS LIBERTY; \
cd ./fixinc && \
	/bin/sh ${srcdir}/mkfixinc.sh x86_64-unknown-linux-gnu 
x86_64-redhat-linux-gnu)
constructing ../fixinc.sh for x86_64-redhat-linux-gnu to run on 
x86_64-unknown-linux-gnu
make TARGETS=oneprocess SHELL="/bin/tcsh" CC="gcc" CFLAGS=" -g -O2 
-DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes 
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-error -DHAVE_CONFIG_H 
-DGENERATOR_FILE" LDFLAGS="" 
LIBERTY="/home/dlab/pkgs/src/gcc/gcc-3.4.6/gobj/gcc/../libiberty/libiberty.a" 
install-bin
make[2]: Entering directory 
`/home/dlab/pkgs/src/gcc/gcc-3.4.6/gobj/gcc/fixinc'

/bin/tcsh ../../../gcc/fixinc/genfixes machname.h
SHELL=/bin/sh: Command not found.
export: Command not found.
if: Expression Syntax.
make[2]: *** [machname.h] Error 1
make[2]: Leaving directory 
`/home/dlab/pkgs/src/gcc/gcc-3.4.6/gobj/gcc/fixinc'

make[1]: *** [fixinc.sh] Error 2
make[1]: Leaving directory `/home/dlab/pkgs/src/gcc/gcc-3.4.6/gobj/gcc'
make: *** [all-gcc] Error 2

This is my configure line:

../configure --prefix=/home/dlab/pkgs/src/gcc/3.4.6 
--target=x86_64-redhat-linux


When I execute "gcc -dumpmachine" I get this

x86_64-redhat-linux

Does anyone have any idea of how I can configure to fix this error or is 
there something else I need to fix here?   Any replies would be appreciated.


Regards,

Len Reder
Jet Propulsion Laboratory

Re: Problem building gcc 3.4.6 on 64 bit linux machine

[Bruce Korb]

You must be trying to rebuild the generated files in the fixincludes directory.
You shouldn't be.  Run:
   bash contrib/gcc_update --touch
Good luck - Bruce

On Thu, Oct 16, 2008 at 3:24 PM, Leonard J. Reder <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I have a code that requires gcc 3.4.6 to compile it so I am attempting to
> build for my fedora 9 64 bit linux machine.  It is having trouble doing
> this:
>
> gcc -c   -g -O2 -DIN_GCC -DCROSS_COMPILE  -W -Wall -Wwrite-strings
> -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
> -DHAVE_CONFIG_H-I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include
>  ../../gcc/cppspec.c -o cppspec.o
> gcc   -g -O2 -DIN_GCC -DCROSS_COMPILE  -W -Wall -Wwrite-strings
> -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
> -DHAVE_CONFIG_H  -o cpp gcc.o cppspec.o intl.o \
>  prefix.o version.o  ../libiberty/libiberty.a
> /home/dlab/pkgs/src/gcc/gcc-3.4.6/gobj/gcc/xgcc
> -B/home/dlab/pkgs/src/gcc/gcc-3.4.6/gobj/gcc/
> -B/home/dlab/pkgs/src/gcc/3.4.6/x86_64-redhat-linux/bin/
> -B/home/dlab/pkgs/src/gcc/3.4.6/x86_64-redhat-linux/lib/ -isystem
> /home/dlab/pkgs/src/gcc/3.4.6/x86_64-redhat-linux/include -isystem
> /home/dlab/pkgs/src/gcc/3.4.6/x86_64-redhat-linux/sys-include -dumpspecs >
> tmp-specs
> mv tmp-specs specs
> if [ -f specs.ready ] ; then \
>true; \
>else \
>echo timestamp > specs.ready; \
>fi
> (MAKE="make"; srcdir=`cd ../../gcc/fixinc && ${PWDCMD-pwd}` ; \
>CC="gcc"; CFLAGS="  -g -O2 -DIN_GCC -DCROSS_COMPILE  -W -Wall
> -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic
> -Wno-long-long  -Wno-error  -DHAVE_CONFIG_H -DGENERATOR_FILE"; LDFLAGS=""; \
>WARN_CFLAGS="-W -Wall -Wwrite-strings -Wstrict-prototypes
> -Wmissing-prototypes -pedantic -Wno-long-long  -Wno-error";
> LIBERTY=`${PWDCMD-pwd}`/"../libiberty/libiberty.a"; \
>export MAKE srcdir CC CFLAGS LDFLAGS WARN_CFLAGS LIBERTY; \
>cd ./fixinc && \
>/bin/sh ${srcdir}/mkfixinc.sh x86_64-unknown-linux-gnu
> x86_64-redhat-linux-gnu)
> constructing ../fixinc.sh for x86_64-redhat-linux-gnu to run on
> x86_64-unknown-linux-gnu
> make TARGETS=oneprocess SHELL="/bin/tcsh" CC="gcc" CFLAGS=" -g -O2 -DIN_GCC
> -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes
> -Wmissing-prototypes -pedantic -Wno-long-long -Wno-error -DHAVE_CONFIG_H
> -DGENERATOR_FILE" LDFLAGS=""
> LIBERTY="/home/dlab/pkgs/src/gcc/gcc-3.4.6/gobj/gcc/../libiberty/libiberty.a"
> install-bin
> make[2]: Entering directory
> `/home/dlab/pkgs/src/gcc/gcc-3.4.6/gobj/gcc/fixinc'
> /bin/tcsh ../../../gcc/fixinc/genfixes machname.h
> SHELL=/bin/sh: Command not found.
> export: Command not found.
> if: Expression Syntax.
> make[2]: *** [machname.h] Error 1
> make[2]: Leaving directory
> `/home/dlab/pkgs/src/gcc/gcc-3.4.6/gobj/gcc/fixinc'
> make[1]: *** [fixinc.sh] Error 2
> make[1]: Leaving directory `/home/dlab/pkgs/src/gcc/gcc-3.4.6/gobj/gcc'
> make: *** [all-gcc] Error 2
>
> This is my configure line:
>
> ../configure --prefix=/home/dlab/pkgs/src/gcc/3.4.6
> --target=x86_64-redhat-linux
>
> When I execute "gcc -dumpmachine" I get this
>
> x86_64-redhat-linux
>
> Does anyone have any idea of how I can configure to fix this error or is
> there something else I need to fix here?   Any replies would be appreciated.
>
> Regards,
>
> Len Reder
> Jet Propulsion Laboratory
>
>
>
>
>
>
>

[Bug middle-end/37339] [4.4 Regression] gcc.dg/pr33645-3.c scan-assembler-not var1_t

[sje at cup dot hp dot com]

--- Comment #2 from sje at cup dot hp dot com  2008-10-16 23:17 ---
This test uses -fno-unit-at-a-time which basically no longer exists.  I believe
it is currently accepted as an alias for -fno-toplevel-reorder.  Does it make
sense to just remove this test?


-- 

sje at cup dot hp dot com changed:

   What|Removed |Added

 CC||sje at cup dot hp dot com


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

[Bug tree-optimization/37449] [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math

[dberlin at dberlin dot org]

--- Comment #25 from dberlin at gcc dot gnu dot org  2008-10-16 23:30 
---
Subject: Re:  [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math

I fixed the PRE issue with builtin_pow here.
:)


On Wed, Oct 15, 2008 at 2:50 PM, dberlin at dberlin dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #24 from dberlin at gcc dot gnu dot org  2008-10-15 18:50 
> ---
> Subject: Re:  [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math
>
> On Wed, Oct 15, 2008 at 2:43 PM, rguenther at suse dot de
> <[EMAIL PROTECTED]> wrote:
>>
>>
>> --- Comment #23 from rguenther at suse dot de  2008-10-15 18:43 ---
>> Subject: Re:  [4.4 Regression] calculix gets
>>  wrong answer for -O1 -ffast-math
>>
>> On Wed, 15 Oct 2008, rguenther at suse dot de wrote:
>>
>>> --- Comment #22 from rguenther at suse dot de  2008-10-15 18:33 ---
>>> Subject: Re:  [4.4 Regression] calculix gets
>>>  wrong answer for -O1 -ffast-math
>>>
>>> On Wed, 15 Oct 2008, dberlin at dberlin dot org wrote:
>>>
>>> > --- Comment #21 from dberlin at gcc dot gnu dot org  2008-10-15 17:55 
>>> > ---
>>> > Subject: Re:  [4.4 Regression] calculix gets wrong answer for -O1 
>>> > -ffast-math
>>> >
>>> > >
>>> > > It already does (I fixed that recently), but we only phi-translate 
>>> > > during
>>> > > insertion and we
>>> > > don't insert for that case, as obviously there is no partial redundancy.
>>> >
>>> > True, but if it discovered all the new phi arguments would be constant
>>> > it used to create a new phi node with the new constant values and let
>>> > eliminate replace the old calculation with the new phi node.
>>> >
>>> > Maybe it only did this if all the constants ended up the same value,
>>> > but it would be trivial to do it if all the arguments are constant,
>>> > regardless of whether they are the same value.
>>> > :)
>>>
>>> Well, we already do for
>>>
>>> int foo (int b)
>>> {
>>>   double i;
>>>   if (b)
>>> i = 4;
>>>   else
>>> i = 9;
>>>   return __builtin_sqrt(i);
>>> }
>>>
>>> :
>>>   # i_1 = PHI <4.0e+0(5), 9.0e+0(3)>
>>>   # prephitmp.11_7 = PHI <2.0e+0(5), 3.0e+0(3)>
>>>   # prephitmp.12_8 = PHI <2(5), 3(3)>
>>>   D.1238_5 = prephitmp.11_7;
>>>   D.1237_6 = prephitmp.12_8;
>>>   return D.1237_6;
>>
>> Ok, for return __builtin_pow (i, i) it doesn't work because we
>> do not register phi-translations that result in constants (translating
>> i does) and then we run into the if (seen) guard and fail to
>> phi-translate.
>
>
>
>>
>> Either we should register phi-translations for them
>
> We should be.
>
> REmember we used to always create names for constants, and then we
> removed that because the constants were valid arguments for GIMPLE
> expressions anyway.
>
> Now that we don't always produce NAME, we should be allowing
> registration of translations that result in CONSTANT.
> Otherwise we will also miss partial redundancies where one phi
> arguments evaluates to constant, as well, because when it comes time
> to look it up, it will come up with no translation, and we will assume
> it's nnot partially redundant.
>
> --Dan
>
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37449
>
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.
>


-- 


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

[Bug c/37858] New: [4.3/4.4] ICE when "-fdump-ipa-all -dv" is used

[zsojka at seznam dot cz]

gcc crashes when any file is compiled with following switches:

gcc test.cpp -o test.o -fdump-ipa-all -dv

---

Seems to crash for any valid input file, but in this test I used:
test.cpp:
int main(void) { return 0; }

-

test.cpp:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

---

# gcc -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.3.2/work/gcc-4.3.2/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--enable-nls --without-included-gettext --with-system-zlib --disable-checking
--disable-werror --enable-secureplt --enable-multilib --disable-libmudflap
--disable-libssp --enable-cld --disable-libgcj
--enable-languages=c,c++,treelang,fortran --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.2 p1.0'
Thread model: posix
gcc version 4.3.2 (Gentoo 4.3.2 p1.0)


-- 
   Summary: [4.3/4.4] ICE when "-fdump-ipa-all -dv" is used
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
  GCC host triplet: x86_64-pc-linux-gnu


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

[Bug bootstrap/37859] New: Bootstrap failure on mips64octeon-unknown-linux-gnu

[nemet at gcc dot gnu dot org]

Bootstrap failure in stage3.

/mnt/src/gcc-clean/mips64octeon-unknown-linux-gnu/./prev-gcc/xgcc
-B/mnt/src/gcc
-clean/mips64octeon-unknown-linux-gnu/./prev-gcc/
-B/mnt/src/gcc-clean/mips64oct
eon-unknown-linux-gnu/../install-mips64octeon-unknown-linux-gnu/mips64octeon-unk
nown-linux-gnu/bin/ -c  -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings
-Wstrict-prot
otypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat
-Wmi
ssing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overle
ngth-strings -Werror -fno-common  -DHAVE_CONFIG_H -I. -I. -I../../src/gcc
-I../.
./src/gcc/. -I../../src/gcc/../include -I../../src/gcc/../libcpp/include 
-I../.
./src/gcc/../libdecnumber -I../../src/gcc/../libdecnumber/dpd -I../libdecnumber 
   ../../src/gcc/tracer.c -o tracer.o
In file included from ../../src/gcc/sel-sched.c:50:
../../src/gcc/sel-sched-ir.h: In function 'T.2588':
../../src/gcc/sel-sched-ir.h:1312: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [sel-sched.o] Error 1
make[3]: *** Waiting for unfinished jobs
rm gcj-dbtool.pod fsf-funding.pod jcf-dump.pod jv-convert.pod grmic.pod
gcov.pod
 gcj.pod gc-analyze.pod gfdl.pod cpp.pod gij.pod gcc.pod gfortran.pod
make[3]: Leaving directory
`/mnt/src/gcc-clean/mips64octeon-unknown-linux-gnu/gc
c'
make[2]: *** [all-stage3-gcc] Error 2
make[2]: Leaving directory `/mnt/src/gcc-clean/mips64octeon-unknown-linux-gnu'
make[1]: *** [stage3-bubble] Error 2
make[1]: Leaving directory `/mnt/src/gcc-clean/mips64octeon-unknown-linux-gnu'
make: *** [all] Error 2


-- 
   Summary: Bootstrap failure on mips64octeon-unknown-linux-gnu
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: nemet at gcc dot gnu dot org
ReportedBy: nemet at gcc dot gnu dot org
 GCC build triplet: mips64octeon-unknown-linux-gnu
  GCC host triplet: mips64octeon-unknown-linux-gnu
GCC target triplet: mips64octeon-unknown-linux-gnu


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

[Bug libfortran/37839] st_parameter_dt has unwanted padding, is out of sync with compiler

[jvdelisle at gcc dot gnu dot org]

--- Comment #5 from jvdelisle at gcc dot gnu dot org  2008-10-17 03:40 
---
What if we do something like this:

typedef struct st_parameter_common
{
  GFC_INTEGER_4 flags;
  GFC_INTEGER_4 unit;
  const char *filename;
  GFC_INTEGER_4 line;
  CHARACTER2 (iomsg);
  GFC_INTEGER_4 *iostat;
#ifdef NEED_TO_PAD
  GFC_INTEGER_4 padit;
#endif
}
st_parameter_common;

Defining NEED_TO_PAD based on platform and whether or not -m32 ?


-- 


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

[Bug debug/37801] DWARF output for inlined functions doesn't always use DW_TAG_inlined_subroutine

[xuepeng dot guo at intel dot com]

--- Comment #3 from xuepeng dot guo at intel dot com  2008-10-17 04:58 
---
Yes, I agree with you. Would you please explain your idea in more detailed way?
Please take what I posted in comment #1 as an example to show what should be
generated and what should not be generated. I am willing to fix this bug under
your instruction.


-- 


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

Re: Problem building gcc 3.4.6 on 64 bit linux machine

[Manfred Hollstein]

On Fri, 17 Oct 2008, 00:33:08 +0200, Bruce Korb wrote:
> You must be trying to rebuild the generated files in the fixincludes 
> directory.
> You shouldn't be.  Run:
>bash contrib/gcc_update --touch
> Good luck - Bruce

Another thing that strikes is that he's using /bin/tcsh as the shell; I'd
suggest to "setenv CONFIG_SHELL /bin/sh" before invoking configure.

> On Thu, Oct 16, 2008 at 3:24 PM, Leonard J. Reder <[EMAIL PROTECTED]> wrote:
> > [...]
> > make TARGETS=oneprocess SHELL="/bin/tcsh" CC="gcc" CFLAGS=" -g -O2 -DIN_GCC
^
> > [...]
> > make[2]: Entering directory
> > `/home/dlab/pkgs/src/gcc/gcc-3.4.6/gobj/gcc/fixinc'
> > /bin/tcsh ../../../gcc/fixinc/genfixes machname.h
> > SHELL=/bin/sh: Command not found.
> > export: Command not found.
> > if: Expression Syntax.
> > make[2]: *** [machname.h] Error 1
> > make[2]: Leaving directory
> > `/home/dlab/pkgs/src/gcc/gcc-3.4.6/gobj/gcc/fixinc'
> > make[1]: *** [fixinc.sh] Error 2
> > make[1]: Leaving directory `/home/dlab/pkgs/src/gcc/gcc-3.4.6/gobj/gcc'
> > make: *** [all-gcc] Error 2
> >
> > This is my configure line:
> >
> > ../configure --prefix=/home/dlab/pkgs/src/gcc/3.4.6
> > --target=x86_64-redhat-linux
> >
> > When I execute "gcc -dumpmachine" I get this
> >
> > x86_64-redhat-linux
> >
> > Does anyone have any idea of how I can configure to fix this error or is
> > there something else I need to fix here?   Any replies would be appreciated.

HTH, cheers.

l8er
manfred

[Bug middle-end/37858] [4.3/4.4 Regression] ICE when "-fdump-ipa-all -dv" is used

[ubizjak at gmail dot com]

--- Comment #1 from ubizjak at gmail dot com  2008-10-17 06:32 ---
Confirmed, gcc crashes in passes.c, around line 1288:

  if (initializing_dump
  && dump_file
  && graph_dump_format != no_graph
==>   && (cfun->curr_properties & (PROP_cfg | PROP_rtl))
  == (PROP_cfg | PROP_rtl))
{
  get_dump_file_info (pass->static_pass_number)->flags |= TDF_GRAPH;
  dump_flags |= TDF_GRAPH;
  clean_graph_dump_file (dump_file_name);
}

(gdb) print cfun
$1 = (struct function *) 0x0


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   GCC host triplet|x86_64-pc-linux-gnu |
   Last reconfirmed|-00-00 00:00:00 |2008-10-17 06:32:56
   date||
Summary|[4.3/4.4] ICE when "-fdump- |[4.3/4.4 Regression] ICE
   |ipa-all -dv" is used|when "-fdump-ipa-all -dv" is
   ||used


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

[Bug target/37809] [4.2/4.3/4.4 Regression] Incorrect code with MMX right shift __builtin_ia32_psradi

[ubizjak at gmail dot com]

--- Comment #5 from ubizjak at gmail dot com  2008-10-17 06:35 ---
(In reply to comment #4)
> Digging a bit, in combine.c, the ASHIFTRT case of force_to_mode() contains two
> calls to simplify_shift_const().  Disabling those for vector modes fixes the
> test case here (patch below).

Can you please post the patch with correct ChangeLog to gcc-patches mailing
list?
Also, the discussion about patch should start in gcc-patches ML.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 AssignedTo|ubizjak at gmail dot com|unassigned at gcc dot gnu
   ||dot org
 Status|ASSIGNED|NEW


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