[Bug rtl-optimization/40209] ICE in iv_analyze_def caused by stale REG_UNUSED note

[steven at gcc dot gnu dot org]

--- Comment #4 from steven at gcc dot gnu dot org  2009-07-24 06:27 ---
A hint, please, about why the patch of comment #2 would be the correct fix.  As
far as I can tell, loop-iv doesn't need the notes and shouldn't have to clean
up other passes' mess. This patch also introduces a pass ordering restriction
that shouldn't be there. And at the very least, if this bug gets papered over
like this, then there should be a comment in loop-iv that the problem is only
added to fix bugs elsewhere...


-- 


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

[Bug rtl-optimization/40209] ICE in iv_analyze_def caused by stale REG_UNUSED note

[ubizjak at gmail dot com]

--- Comment #3 from ubizjak at gmail dot com  2009-07-24 06:25 ---
Please also add the testcase from Comment #1 to gcc testsuite.


-- 


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

[Bug tree-optimization/40844] O2 optimizes out assignment to bitfield

[pinskia at gmail dot com]

--- Comment #1 from pinskia at gmail dot com  2009-07-24 05:54 ---
Subject: Re:   New: O2 optimizes out assignment to bitfield



Sent from my iPhone

On Jul 23, 2009, at 10:22 PM, "jim at bodwin dot us"  wrote:

> Incorrect code is produced for the following source with the O2  
> option.  In
> particular, the assignment to the bitfield field2 is optimized out  
> of the code
> entirely and regImage is left all zero.  Correct code is produced  
> with the O1
> option and (at least) with gcc version 4.3.2.
>
>   Source Code
>
> typedef struct hwreg {
>short field1 : 4;
>short field2 : 2;
>short field3 : 10;
> } hwreg_t;
>
> void foo(volatile short *hwPtr, short f2) {
>hwreg_t regImage;   // Place to build reg image bit-by-bit
>*(short *) ®Image = 0;
>
>regImage.field2 = f2;
>
>*hwPtr = *((short *) ®Image);
> }

I think you are violating c/c++ aliasing rules here.


>
>  Object dump
>
>
> /tmp/foo.o: file format elf32-littlearm
>
>
> Disassembly of section .text:
>
>  :
>   0:   e3a03000mov r3, #0  ; 0x0
>   4:   e24dd004sub sp, sp, #4  ; 0x4
>   8:   e1c030b0strhr3, [r0]
>   c:   e28dd004add sp, sp, #4  ; 0x4
>  10:   e12fff1ebx  lr
>
>   gcc -v output
>
> Configured with: ../gcc-4.4.1/configure --target=arm-elf --disable- 
> __cxa_atexit
> --with-newlib --enable-languages=c,c++ --with-gnu-as --with-gnu-ld
> --with-gxx-include-dir=/home/jmb/arm-elf/include --prefix=/home/jmb/ 
> arm-elf :
> (reconfigured) ../gcc-4.4.1/configure --target=arm-elf --disable- 
> __cxa_atexit
> --with-newlib --enable-languages=c,c++ --with-gnu-as --with-gnu-ld
> --with-gxx-include-dir=/home/jmb/arm-elf/include --prefix=/home/jmb/ 
> arm-elf
> Thread model: single
> gcc version 4.4.1 (GCC)
>
>
> -- 
>   Summary: O2 optimizes out assignment to bitfield
>   Product: gcc
>   Version: 4.4.1
>Status: UNCONFIRMED
>  Severity: critical
>  Priority: P3
> Component: tree-optimization
>AssignedTo: unassigned at gcc dot gnu dot org
>ReportedBy: jim at bodwin dot us
> GCC build triplet: i486-pc-linux-gnu
>  GCC host triplet: i486-pc-linux-gnu
> GCC target triplet: arm-elf
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40844
>


-- 


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

Re: [Bug tree-optimization/40844] New: O2 optimizes out assignment to bitfield

[Andrew Pinski]

Sent from my iPhone

On Jul 23, 2009, at 10:22 PM, "jim at bodwin dot us" > wrote:


Incorrect code is produced for the following source with the O2  
option.  In
particular, the assignment to the bitfield field2 is optimized out  
of the code
entirely and regImage is left all zero.  Correct code is produced  
with the O1

option and (at least) with gcc version 4.3.2.

  Source Code

typedef struct hwreg {
   short field1 : 4;
   short field2 : 2;
   short field3 : 10;
} hwreg_t;

void foo(volatile short *hwPtr, short f2) {
   hwreg_t regImage;   // Place to build reg image bit-by-bit
   *(short *) ®Image = 0;

   regImage.field2 = f2;

   *hwPtr = *((short *) ®Image);
}


I think you are violating c/c++ aliasing rules here.




 Object dump


/tmp/foo.o: file format elf32-littlearm


Disassembly of section .text:

 :
  0:   e3a03000mov r3, #0  ; 0x0
  4:   e24dd004sub sp, sp, #4  ; 0x4
  8:   e1c030b0strhr3, [r0]
  c:   e28dd004add sp, sp, #4  ; 0x4
 10:   e12fff1ebx  lr

  gcc -v output

Configured with: ../gcc-4.4.1/configure --target=arm-elf --disable- 
__cxa_atexit

--with-newlib --enable-languages=c,c++ --with-gnu-as --with-gnu-ld
--with-gxx-include-dir=/home/jmb/arm-elf/include --prefix=/home/jmb/ 
arm-elf :
(reconfigured) ../gcc-4.4.1/configure --target=arm-elf --disable- 
__cxa_atexit

--with-newlib --enable-languages=c,c++ --with-gnu-as --with-gnu-ld
--with-gxx-include-dir=/home/jmb/arm-elf/include --prefix=/home/jmb/ 
arm-elf

Thread model: single
gcc version 4.4.1 (GCC)


--
  Summary: O2 optimizes out assignment to bitfield
  Product: gcc
  Version: 4.4.1
   Status: UNCONFIRMED
 Severity: critical
 Priority: P3
Component: tree-optimization
   AssignedTo: unassigned at gcc dot gnu dot org
   ReportedBy: jim at bodwin dot us
GCC build triplet: i486-pc-linux-gnu
 GCC host triplet: i486-pc-linux-gnu
GCC target triplet: arm-elf


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

[Bug fortran/40011] Problems with -fwhole-file

[jv244 at cam dot ac dot uk]

--- Comment #35 from jv244 at cam dot ac dot uk  2009-07-24 05:48 ---
(In reply to comment #34)
> I won't be able to reduce this failure for the next 10 days or so.

as a PS, the multiple-file compilation of trunk cp2k goes fine. 


-- 


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

[Bug fortran/40011] Problems with -fwhole-file

[jv244 at cam dot ac dot uk]

--- Comment #34 from jv244 at cam dot ac dot uk  2009-07-24 05:39 ---
Testing paul's latest patch at 

http://gcc.gnu.org/ml/fortran/2009-07/msg00202.html 

on the latest all file CP2K (see also PR40005)

http://www.pci.uzh.ch/vandevondele/tmp/CP2K_2009-05-01.f90.gz

I get the following ICE for 

ulimit -s 512000
gfortran -c -O2 -march=native -fwhole-file CP2K_2009-05-01.f90

CP2K_2009-05-01.f90: In function ‘broadcast_input_information’:
CP2K_2009-05-01.f90:53523:0: internal compiler error: tree check: expected
record_type or union_type or qual_union_type, have H��H$@
in gfc_get_derived_type, at fortran/trans-types.c:2010
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

I won't be able to reduce this failure for the next 10 days or so.


-- 


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

[Bug tree-optimization/40844] New: O2 optimizes out assignment to bitfield

[jim at bodwin dot us]

Incorrect code is produced for the following source with the O2 option.  In
particular, the assignment to the bitfield field2 is optimized out of the code
entirely and regImage is left all zero.  Correct code is produced with the O1
option and (at least) with gcc version 4.3.2.

  Source Code

typedef struct hwreg {
short field1 : 4;
short field2 : 2;
short field3 : 10;
} hwreg_t;

void foo(volatile short *hwPtr, short f2) {
hwreg_t regImage;   // Place to build reg image bit-by-bit
*(short *) ®Image = 0;

regImage.field2 = f2;

*hwPtr = *((short *) ®Image);
}

 Object dump


/tmp/foo.o: file format elf32-littlearm


Disassembly of section .text:

 :
   0:   e3a03000mov r3, #0  ; 0x0
   4:   e24dd004sub sp, sp, #4  ; 0x4
   8:   e1c030b0strhr3, [r0]
   c:   e28dd004add sp, sp, #4  ; 0x4
  10:   e12fff1ebx  lr

  gcc -v output

Configured with: ../gcc-4.4.1/configure --target=arm-elf --disable-__cxa_atexit
--with-newlib --enable-languages=c,c++ --with-gnu-as --with-gnu-ld
--with-gxx-include-dir=/home/jmb/arm-elf/include --prefix=/home/jmb/arm-elf :
(reconfigured) ../gcc-4.4.1/configure --target=arm-elf --disable-__cxa_atexit
--with-newlib --enable-languages=c,c++ --with-gnu-as --with-gnu-ld
--with-gxx-include-dir=/home/jmb/arm-elf/include --prefix=/home/jmb/arm-elf
Thread model: single
gcc version 4.4.1 (GCC)


-- 
   Summary: O2 optimizes out assignment to bitfield
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jim at bodwin dot us
 GCC build triplet: i486-pc-linux-gnu
  GCC host triplet: i486-pc-linux-gnu
GCC target triplet: arm-elf


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

[Bug rtl-optimization/40209] ICE in iv_analyze_def caused by stale REG_UNUSED note

[ian at gcc dot gnu dot org]

--- Comment #2 from ian at gcc dot gnu dot org  2009-07-24 04:01 ---
Subject: Bug 40209

Author: ian
Date: Fri Jul 24 04:01:13 2009
New Revision: 150038

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150038
Log:
PR rtl-optimization/40209
* loop-iv.c (iv_analysis_loop_init): Call df_note_add_problem.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/loop-iv.c


-- 


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

[Bug target/40835] redundant comparison instruction

[carrot at google dot com]

--- Comment #2 from carrot at google dot com  2009-07-24 02:11 ---
It seems HAVE_cc0 disabled for arm. What's the reason behind it?

A simple method is to add a peephole rule to handle it.


-- 


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

[Bug libstdc++/40841] Application segfaults when throwing an exception that destroys an fstream

[hjl dot tools at gmail dot com]

--- Comment #6 from hjl dot tools at gmail dot com  2009-07-24 01:52 ---
It works for me on RHEL 4 with gcc 4.4.1:

[...@gnu-14 tmp]$ cat foo.cc
#include 

using namespace std;

void f(const char * filename)
{
 ifstream is;
 throw 2;
}

int main()
{
 try {
  f("v3");
 } catch(int e) {
 }
}
[...@gnu-14 tmp]$ /usr/gcc-4.4/bin/g++ foo.cc -Wl,-rpath,/usr/gcc-4.4/lib
[...@gnu-14 tmp]$ ldd a.out
linux-gate.so.1 =>  (0xa000)
libstdc++.so.6 => /usr/gcc-4.4/lib/libstdc++.so.6 (0x20044000)
libm.so.6.1 => /lib/tls/libm.so.6.1 (0x2024)
libgcc_s.so.1 => /usr/gcc-4.4/lib/libgcc_s.so.1 (0x202fc000)
libunwind.so.7 => /usr/gcc-4.4/lib/libunwind.so.7 (0x2033)
libc.so.6.1 => /lib/tls/libc.so.6.1 (0x2035c000)
/lib/ld-linux-ia64.so.2 (0x2000)
[...@gnu-14 tmp]$ ./a.out
[...@gnu-14 tmp]$ /usr/gcc-4.4/bin/g++ -v
Using built-in specs.
Target: ia64-unknown-linux-gnu
Configured with: /net/gnu-13/export/gnu/src/gcc-4.4/gcc/configure
--enable-clocale=gnu --with-system-zlib --enable-checking=assert
--with-demangler-in-ld --enable-shared --enable-threads=posix --enable-haifa
--prefix=/usr/gcc-4.4 --with-local-prefix=/usr/local
Thread model: posix
gcc version 4.4.1 (GCC)
[...@gnu-14 tmp]$ ld -V
GNU ld (Linux/GNU Binutils) 2.19.51.0.14.20090722
  Supported emulations:
   elf64_ia64
[...@gnu-14 tmp]$


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||hjl dot tools at gmail dot
   ||com


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

[Bug lto/40429] [LTO] Handling of -o without space

[bje at gcc dot gnu dot org]

--- Comment #3 from bje at gcc dot gnu dot org  2009-07-24 00:42 ---
I checked in Ryan's patch for him.


-- 

bje at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug lto/40429] [LTO] Handling of -o without space

[bje at gcc dot gnu dot org]

--- Comment #2 from bje at gcc dot gnu dot org  2009-07-24 00:42 ---
Subject: Bug 40429

Author: bje
Date: Fri Jul 24 00:41:54 2009
New Revision: 150037

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150037
Log:
2009-06-13  Ryan Mansfield  

PR lto/40429
* lto-wrapper.c (run_gcc): Handle no space between -o and filename
argument.

Modified:
branches/lto/gcc/ChangeLog.lto
branches/lto/gcc/lto-wrapper.c


-- 


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

[Bug fortran/40727] [4.4] ICE gfc_simplify_dcmplx(): Bad type when passing BT_COMPLEX to cmplx

[kargl at gcc dot gnu dot org]

--- Comment #5 from kargl at gcc dot gnu dot org  2009-07-24 00:31 ---
Fixed.


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug fortran/40727] [4.4] ICE gfc_simplify_dcmplx(): Bad type when passing BT_COMPLEX to cmplx

[kargl at gcc dot gnu dot org]

--- Comment #4 from kargl at gcc dot gnu dot org  2009-07-24 00:28 ---
Subject: Bug 40727

Author: kargl
Date: Fri Jul 24 00:28:43 2009
New Revision: 150036

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150036
Log:
2009-07-23  Steven G. Kargl  

PR fortran/40727
* fortran/check.c (gfc_check_cmplx, gfc_check_dcmplx): Add check that
the optional second argument isn't of COMPLEX type.

2009-07-23  Steven G. Kargl  

PR fortran/40727
* gfortran.dg/intrinsic_cmplx.f90: New test.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/intrinsic_cmplx.f90
  - copied unchanged from r149793,
trunk/gcc/testsuite/gfortran.dg/intrinsic_cmplx.f90
Modified:
branches/gcc-4_4-branch/gcc/fortran/ChangeLog
branches/gcc-4_4-branch/gcc/fortran/check.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/40843] access violation not detected for non dependent qualified enum value

[sipych at gmail dot com]

--- Comment #4 from sipych at gmail dot com  2009-07-24 00:00 ---
// More similar cases. Static members also may be accessed

#include 

class A {
enum { value=1 };   // private
static const int ci=2;
static int fi() { return 3; }
};

template // bug appears only if B is a template
struct B {
 enum { value=A::value }; // <- silently access private member
// enum { v2=A::ci  };// this error is detected @ any instantiation 
 static const int v3=A::value;  // not detected
 static const int v4=A::ci; // not detected
 static int f5() { return A::value; }   // not detected
 static int f6() { return A::ci; }  // detected only if f6() accessed
 static int f7() { return A::fi(); }// detected only if f7() accessed,
reported twice
};

int main() {
  std::cout << B<1>::value << B<1>::v3 << B<1>::v4 << B<1>::f5() 
// << B<1>::f6()// error will be detected
// << B<1>::f7()// error will be detected, and reported TWICE
   << std::endl;
  return 0;
}


-- 


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

[Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817

[pthaugen at gcc dot gnu dot org]

--- Comment #23 from pthaugen at gcc dot gnu dot org  2009-07-23 23:48 
---
I opened a new bugzilla, 40482, for the Load-hit-store RA issue discussed in
comments 17-20 since that's a separate problem.


-- 


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

[Bug bootstrap/40597] Powerpc bootstrap is broken due to changes in expmed.c

[bonzini at gnu dot org]

--- Comment #36 from bonzini at gnu dot org  2009-07-23 23:01 ---
No, all patches were committed.


-- 


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

[Bug bootstrap/40597] Powerpc bootstrap is broken due to changes in expmed.c

[meissner at linux dot vnet dot ibm dot com]

--- Comment #35 from meissner at linux dot vnet dot ibm dot com  2009-07-23 
23:00 ---
Subject: Re:  Powerpc bootstrap is broken due to changes in expmed.c

On Thu, Jul 23, 2009 at 10:52:01PM -, paolo dot bonzini at gmail dot com
wrote:
> 
> 
> --- Comment #34 from paolo dot bonzini at gmail dot com  2009-07-23 22:52 
> ---
> Subject: Re:  Powerpc bootstrap is broken due to changes
>  in expmed.c
> 
> On 07/23/2009 02:37 PM, krebbel at gcc dot gnu dot org wrote:
> > In emit_store_flag the following code now invokes emit_store_flag_1 instead 
> > of
> > emit_store_flag:
> 
> This one in particular should be a recursive call indeed.  Can you 
> prepare a patch?
> 
> 
> -- 
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40597
> 
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.

Just to be sure we are on the same page, is the trunk up to date, or are there
patches to the trunk that haven't been committed yet.  It looks like the patch
was committed.


-- 


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

[Bug bootstrap/40597] Powerpc bootstrap is broken due to changes in expmed.c

[paolo dot bonzini at gmail dot com]

--- Comment #34 from paolo dot bonzini at gmail dot com  2009-07-23 22:52 
---
Subject: Re:  Powerpc bootstrap is broken due to changes
 in expmed.c

On 07/23/2009 02:37 PM, krebbel at gcc dot gnu dot org wrote:
> In emit_store_flag the following code now invokes emit_store_flag_1 instead of
> emit_store_flag:

This one in particular should be a recursive call indeed.  Can you 
prepare a patch?


-- 


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

[Bug c++/40843] access violation not detected for non dependent qualified enum value

[sipych at gmail dot com]

--- Comment #3 from sipych at gmail dot com  2009-07-23 22:46 ---
Also present in gcc 4.4.0


-- 

sipych at gmail dot com changed:

   What|Removed |Added

  Known to fail||4.1.2 4.3.3 4.4.0


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

[Bug libstdc++/40841] Application segfaults when throwing an exception that destroys an fstream

[zlynx at acm dot org]

--- Comment #5 from zlynx at acm dot org  2009-07-23 22:26 ---
The actual segfault seems to happen in the .plt section. I am not entirely
clear on how this is laid out and how to find what symbol is where.

But on entry to the plt code, the r1 register is set to an invalid memory
location and it is then read from. It appears that r1 is supposed to be set
from r35 much earlier, perhaps it gets overwritten.

It sort of looks like the exception unwinder changed the register value but the
code expects the register to still hold the right offset to the PLT.


-- 


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

[Bug tree-optimization/38785] [4.3/4.4/4.5 Regression] huge performance regression on EEMBC bitmnp01

[stevenb dot gcc at gmail dot com]

--- Comment #18 from stevenb dot gcc at gmail dot com  2009-07-23 22:23 
---
Subject: Re:  [4.3/4.4/4.5 Regression] huge 
performance regression on EEMBC bitmnp01

I had the patch ready but Matz' PRE patch means I have to rework things a bit.
Since I only have time for this in weekends...


-- 


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

[Bug c++/40843] access violation not detected for non dependent qualified enum value

[sipych at gmail dot com]

--- Comment #2 from sipych at gmail dot com  2009-07-23 22:08 ---
(In reply to comment #1)
> I think this is a duplicate of bug 21008.
> 

Not shure, A::value may not be accessible neither at the template definition,
nor at the instantiation time.


-- 


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

[Bug tree-optimization/38785] [4.3/4.4/4.5 Regression] huge performance regression on EEMBC bitmnp01

[drow at gcc dot gnu dot org]

--- Comment #17 from drow at gcc dot gnu dot org  2009-07-23 21:50 ---
Steven, have you had time for this?  Anything we can do to help?


-- 

drow at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||steven at gcc dot gnu dot
   ||org, drow at gcc dot gnu dot
   ||org


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

[Bug c++/40843] access violation not detected for non dependent qualified enum value

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-07-23 21:46 ---
I think this is a duplicate of bug 21008.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||accepts-invalid
Summary|private access violation:   |access violation not
   |compile bad code|detected for non dependent
   ||qualified enum value


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

[Bug c++/40843] New: private access violation: compile bad code

[sipych at gmail dot com]

// Illegal access to private member not detected, program compiles silently.
// bug found in:
// g++ (GCC) 4.1.2 20080704 (Red Hat 4.1.2-44)
// g++ (Ubuntu 4.3.3-5ubuntu4) 4.3.3
#include 

class A {
enum { value=1 };   // private
};

template // bug appears only if B is a template
struct B {
 enum { value=A::value }; // <- silently access private member
};

int main() {
  std::cout << B<1>::value << std::endl;
  return 0;
}


-- 
   Summary: private access violation:  compile bad code
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sipych at gmail dot com


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

[Bug rtl-optimization/40842] Poor register class choice in IRA

[pthaugen at gcc dot gnu dot org]

--- Comment #1 from pthaugen at gcc dot gnu dot org  2009-07-23 21:33 
---
Created an attachment (id=18248)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18248&action=view)
Testcase

The reduced testcase (since you can't attatch one when opening a new bz).


-- 


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

[Bug rtl-optimization/40842] New: Poor register class choice in IRA

[pthaugen at gcc dot gnu dot org]

Moving this issue from bz 39976 since it is a separate problem than the
original documented there.

Verified the behavior still exists using current trunk revision (150020).  The
testcase comes from cpu2000 sixtrack benchmark. Following is original comment I
posted:

===
The attatched testcase exhibits the problem with the load-hit-store. It's
resulting from choosing a bad register class (GENERAL_REGS) for a pseudo that
should get assigned to FLOAT_REGS. Since there is no FPR -> GPR move for
-mcpu=power6 the copy must go through memory.  I compiled the testcase with
-m64 -O3 -mcpu=power6 using trunk revision 149376.  The pseudo in question is
361.

Following are the 3 insns referencing reg 361 in the sched1 dump (before ira):

(insn 51 238 241 8 thin6d_reduced.f:178 (set (reg:DF 361 [ prephitmp.35 ])
(reg:DF 358 [ prephitmp.35 ])) 351 {*movdf_hardfloat64} (nil))
...
(insn 47 46 231 9 thin6d_reduced.f:178 (set (reg:DF 361 [ prephitmp.35 ])
(reg:DF 179 [ prephitmp.35 ])) 351 {*movdf_hardfloat64} (nil))
...
(insn 196 194 198 11 thin6d_reduced.f:169 (set (mem/c/i:DF (plus:DI (reg/f:DI
477)
(const_int 56 [0x38])) [2 crkve+0 S8 A64])
(reg:DF 361 [ prephitmp.35 ])) 351 {*movdf_hardfloat64}
(expr_list:REG_DEAD (reg:DF 361 [ prephitmp.35 ])
(nil)))


And from the ira dump:

Pass1 cost computation:
a71 (r361,l1) best GENERAL_REGS, cover GENERAL_REGS
a3 (r361,l0) best GENERAL_REGS, cover GENERAL_REGS
  a3(r361,l0) costs: BASE_REGS:0,0 GENERAL_REGS:0,0 FLOAT_REGS:0,0
LINK_REGS:156,1836 CTR_REGS:156,1836 SPECIAL_REGS:156,1836 MEM:156
  a71(r361,l1) costs: BASE_REGS:0,0 GENERAL_REGS:0,0 FLOAT_REGS:0,0
LINK_REGS:1680,1680 CTR_REGS:1680,1680 SPECIAL_REGS:1680,1680 MEM:1120


Pass 2 cost computation:
r361: preferred GENERAL_REGS, alternative NO_REGS
  a3(r361,l0) costs: BASE_REGS:0,2240 GENERAL_REGS:0,2240 FLOAT_REGS:312,2552
LINK_REGS:234,4154 CTR_REGS:234,4154 SPECIAL_REGS:234,4154 MEM:156
  a71(r361,l1) costs: BASE_REGS:2240,2240 GENERAL_REGS:2240,2240
FLOAT_REGS:2240,2240 LINK_REGS:3920,3920 CTR_REGS:3920,3920
SPECIAL_REGS:3920,3920 MEM:3360


-- 
   Summary: Poor register class choice in IRA
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pthaugen at gcc dot gnu dot org
 GCC build triplet: powerpc64*-*-*
  GCC host triplet: powerpc64*-*-*
GCC target triplet: powerpc64*-*-*


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

[Bug libstdc++/40841] Application segfaults when throwing an exception that destroys an fstream

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2009-07-23 21:09 
---
I see, I can't reproduce it on x86_64-linux, maybe Richard can help for ia64
testing... If that's really the case, however, probably not a libstdc++-proper
issue.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

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


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

[Bug libstdc++/40841] Application segfaults when throwing an exception that destroys an fstream

[zlynx at acm dot org]

--- Comment #3 from zlynx at acm dot org  2009-07-23 21:03 ---
Also note that this seems to be a IA64 problem, not x86.


-- 


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

[Bug libstdc++/40841] Application segfaults when throwing an exception that destroys an fstream

[zlynx at acm dot org]

--- Comment #2 from zlynx at acm dot org  2009-07-23 21:01 ---
Created an attachment (id=18247)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18247&action=view)
reproduce


-- 


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

[Bug libstdc++/40841] Application segfaults when throwing an exception that destroys an fstream

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2009-07-23 20:46 
---
First of all, please provide a complete, small, self contained, snippet showing
the problem. Thanks.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
Summary|Application segfaults when  |Application segfaults when
   |throwing an exception that  |throwing an exception that
   |destroys an fstream |destroys an fstream


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

[Bug libstdc++/40841] New: Application segfaults when throwing an exception that destroys an fstream

[zlynx at acm dot org]

I configure the fstream like this:

ifstream is; 
is.exceptions(ifstream::badbit | ifstream::failbit);
is.open(filename, ifstream::in | ifstream::binary);

When it tries to open a file that does not exist, it throws an exception just
as it should. If this is immediately inside a try/catch block it works. If it
is inside a function call however, the program segfaults.

I believe that the problem is inside the ifstream class. Further testing showed
that declaring a function like this:
void f() {
  ifstream is;
  throw 1;
}
also causes a segfault.

If the exception is not caught in the functions above f() there is an exception
abort but no segfault.

I tried this on GCC 4.4.1 and 4.4.2, both from SVN. GCC 4.3 from Fedora does
not do this.

I believe that the problem is in the libraries, not the GCC binary, because the
Fedora GCC *does* show the problem if I allow it to link to the libraries from
GCC 4.4.2. A -static build on GCC 4.3 works, and a -static build on GCC 4.4.2
fails.

Binutils are Fedora 9 default:
$ ld -v
GNU ld version 2.18.50.0.6-2 20080403


I configured my SVN GCCs like this:
$ gcc -v
Using built-in specs.
Target: ia64-redhat-linux
Configured with: ../configure --prefix=/opt/gcc-4.4 --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-languages=c,c++
--build=ia64-redhat-linux
Thread model: posix
gcc version 4.4.2 20090722 (prerelease) (GCC) 

Fedora 9's GCC is configured like this:
$ /usr/bin/gcc -v
Using built-in specs.
Target: ia64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--build=ia64-redhat-linux
Thread model: posix
gcc version 4.3.0 20080428 (Red Hat 4.3.0-8) (GCC)


-- 
   Summary: Application segfaults when throwing an exception that
destroys an fstream
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zlynx at acm dot org
  GCC host triplet: ia64-redhat-linux


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

[Bug middle-end/38770] internal compiler error: asm clobber conflict with output operand

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2009-07-23 20:24 ---
This error is correct as we have:
register int overflow __asm__("%g6");
...
__asm__ ( "addcc %2,%3,%0;   addx  %%g0,%%g0,%1" : "=r" (__value), "=r"
(overflow) : "r" (__arg1), "r" (__arg2) : "%g6","cc");

So the asm is saying g6 is clobbered and an output.  How can that be true?  It
cannot be clobbered when it is an output.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug middle-end/38770] internal compiler error: asm clobber conflict with output operand

[doubletwist at fearthepenguin dot net]

--- Comment #2 from doubletwist at fearthepenguin dot net  2009-07-23 20:21 
---
I see the exact same error on Solaris 8 Sparc using GCC 4.3.2


-- 

doubletwist at fearthepenguin dot net changed:

   What|Removed |Added

 CC||doubletwist at
   ||fearthepenguin dot net


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

[Bug c++/40840] Segfault with SPU C++ compiler 4.1.1 (const member + vector array)

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-07-23 20:14 ---
Fixed in 4.4.0.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c++/40840] New: Segfault with SPU C++ compiler 4.1.1 (const member + vector array)

[dimitrij dot kotrev at googlemail dot com]

spu-g++ -v

Using built-in specs.
Target: spu
Configured with: ../toolchain/gcc/configure --prefix=/opt/cell/toolchain
--mandir=/opt/cell/toolchain/man --infodir=/opt/cell/toolchain/info
--with-sysroot=/opt/cell/sysroot --disable-shared --disable-threads
--disable-checking --with-headers --with-system-zlib --with-newlib
--enable-languages=c,c++,fortran --disable-nls
--enable-version-specific-runtime-libs --disable-libssp --program-prefix=spu-
--target=spu
Thread model: single
gcc version 4.1.1

It's the compiler from IBM SDK 3.1.


cat vector.cpp 

template
class TestClass {
public:
static const int d = 2;
};

template
void f() {
vector float x[TestClass::d];
}

int
main() {
f();
return 0;
}


spu-g++ -Wall -o tst vector.cpp 
vector.cpp: In function 'void f()':
vector.cpp:9: internal compiler error: Segmentation fault


-- 
   Summary: Segfault with SPU C++ compiler 4.1.1 (const member +
vector array)
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dimitrij dot kotrev at googlemail dot com
GCC target triplet: spu


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

RE: Failed to build plural.c on IRIX64 6.5

[Tovrea, George W (US SSA)]

As you suggested, I downloaded/built bison 1.875 (plus the latest m4)
and got passed the problem below. However, there is a new problem. File
config.cache in the gcc directory is empty and no Makefile was
generated. Consequently, the following error occurs: 

make[3]: Entering directory
`/home/users/tovrea/FFMPEG/gcc-4.4.0-objdir-sgi6/gcc'
make[3]: *** No rule to make target `all'.  Stop.
make[3]: Leaving directory
`/home/users/tovrea/FFMPEG/gcc-4.4.0-objdir-sgi6/gcc'

I didn't see any suspicious errors in config.log.

-Original Message-
From: Ian Lance Taylor [mailto:i...@google.com] 
Sent: Thursday, July 23, 2009 9:49 AM
To: Tovrea, George W (US SSA)
Subject: Re: Failed to build plural.c on IRIX64 6.5

"Tovrea, George W (US SSA)"  writes:

> Ran
>
> gcc -c -g --save-temps -DHAVE_CONFIG_H -I.
> -I/home/users/tovrea/FFMPEG/gcc-4.4.0-RC-20090414/intl plural.c
>
> The plural.i filed contained 
>
> # 112
> "/home/users/tovrea/FFMPEG/gcc-4.4.0-RC-20090414/intl/plural-exp.h"
> extern void libintl_gettext_free_exp (struct expression *exp)
>   ;
> extern int libintl_gettextparse (void *arg);
> extern struct expression libintl_gettext_germanic_plural ;
> extern void libintl_gettext_extract_plural (const char *nullentry,
> struct expression **pluralp, unsigned long int *npluralsp)
> ...
> # 3 "bison.simple"
> # 153 "bison.simple"
> int libintl_gettextparse (void);
> # 196 "bison.simple"
> # 216 "bison.simple"
> int
> libintl_gettextparse(arg)
>  void *arg;

Please also send messages to the mailing list, not just to me.  Thanks.

This looks like libintl/plural.c was rebuilt with an old or somehow
incompatible version of bison.  plural.c is distributed with gcc; it
need not be rebuilt.

Ian

[Bug c++/40834] [4.5 Regression] Revision 149750 failed 483.xalancbmk in SPEC CPU 2006

[hjl dot tools at gmail dot com]

--- Comment #9 from hjl dot tools at gmail dot com  2009-07-23 19:16 ---
This patch:

Index: cp-gimplify.c
===
--- cp-gimplify.c   (revision 149933)
+++ cp-gimplify.c   (working copy)
@@ -804,15 +804,6 @@ cp_genericize_r (tree *stmt_p, int *walk
}
 }

-  else if (TREE_CODE (stmt) == BIND_EXPR)
-{
-  VEC_safe_push (tree, heap, wtd->bind_expr_stack, stmt);
-  cp_walk_tree (&BIND_EXPR_BODY (stmt),
-   cp_genericize_r, data, NULL);
-  VEC_pop (tree, wtd->bind_expr_stack);
-  *walk_subtrees = 0;
-}
-
   else if (TREE_CODE (stmt) == USING_STMT)
 {
   tree block = NULL_TREE;

fixed the problem. Does it make any senses?


-- 


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

[Bug c++/40834] [4.5 Regression] Revision 149750 failed 483.xalancbmk in SPEC CPU 2006

[hjl dot tools at gmail dot com]

--- Comment #8 from hjl dot tools at gmail dot com  2009-07-23 18:57 ---
Jason, can you take a look at this?


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||jason at redhat dot com


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

[Bug c++/40834] [4.5 Regression] Revision 149750 failed 483.xalancbmk in SPEC CPU 2006

[hjl dot tools at gmail dot com]

--- Comment #7 from hjl dot tools at gmail dot com  2009-07-23 18:56 ---
Here are the differences between good and bad

GOOD const struct XalanDOMString & theFirstString = (const struct
XalanDOMString &) (const struct XalanDOMString *) OBJ_TYPE_REF(*(SAVE_EXPR

(&arg1)>->D.20005._vptr.XalanReferenceCountedObject + 72);SAVE_EXPR
 (&arg1)>->9) (SAVE_EXPR
 (&arg1)>);
BAD const struct XalanDOMString & theFirstString = (const struct XalanDOMString
&) (const struct XalanDOMString *) OBJ_TYPE_REF(*(SAVE_EXPR
 ((const struct XObjectPtr *)
arg1)>->D.20005._vptr.XalanReferenceCountedObject + 72);SAVE_EXPR
 ((const struct XObjectPtr *) arg1)>->9)
(SAVE_EXPR  ((const struct XObjectPtr *)
arg1)>);

That is

(&arg1)>->D.20005._vptr.XalanReferenceCountedObject + 72)

vs.

((const struct XObjectPtr *) arg1)>->D.20005._vptr.XalanReferenceCountedObject
+ 72)

The correct one is an address. The wrong one is a cast to pointer.


-- 


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

[Bug c++/40834] [4.5 Regression] Revision 149750 failed 483.xalancbmk in SPEC CPU 2006

[hjl dot tools at gmail dot com]

--- Comment #6 from hjl dot tools at gmail dot com  2009-07-23 18:48 ---
Created an attachment (id=18246)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18246&action=view)
A testcase

You can compare the outputs before and after change.


-- 


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

[Bug bootstrap/37739] [4.4 Regression] bootstrap broken with core gcc > gcc-4.2.x

[giffordj at la dot twcbc dot com]

--- Comment #26 from giffordj at la dot twcbc dot com  2009-07-23 18:36 
---
Looks like it's being used. Any ideas?

gcc -isystem /usr/include -m32   -g -fkeep-inline-functions -DIN_GCC   -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
-Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common 
-DHAVE_CONFIG_H -DGENERATOR_FILE -Wl,-rpath-link,/lib -m32  -Wl,--relax -o
build/genoutput \
gcc -isystem /usr/include -m32   -g -fkeep-inline-functions -DIN_GCC   -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
-Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common 
-DHAVE_CONFIG_H -DGENERATOR_FILE -Wl,-rpath-link,/lib -m32  -Wl,--relax -o
build/genpeep \
gcc -isystem /usr/include -m32   -g -fkeep-inline-functions -DIN_GCC   -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
-Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common 
-DHAVE_CONFIG_H -DGENERATOR_FILE -Wl,-rpath-link,/lib -m32  -Wl,--relax -o
build/genrecog \
gcc -isystem /usr/include -m32   -g -fkeep-inline-functions -DIN_GCC   -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
-Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common 
-DHAVE_CONFIG_H -DGENERATOR_FILE -Wl,-rpath-link,/lib -m32  -Wl,--relax
build/gcov-iov.o -o build/gcov-iov


-- 


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

[Bug c++/40834] [4.5 Regression] Revision 149750 failed 483.xalancbmk in SPEC CPU 2006

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2009-07-23 18:19 ---
(In reply to comment #4)
> FunctionSubstringAfter.cpp  FunctionSubstringBefore.cpp  FunctionSubstring.cpp
> are miscompiled. I have to replace all of them to get a working binary,
> 

It fails even with -O0. Replace those 3 files gives me a working binary.


-- 


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

[Bug c++/40834] [4.5 Regression] Revision 149750 failed 483.xalancbmk in SPEC CPU 2006

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2009-07-23 18:15 ---
FunctionSubstringAfter.cpp  FunctionSubstringBefore.cpp  FunctionSubstring.cpp
are miscompiled. I have to replace all of them to get a working binary,


-- 


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

[Bug fortran/40839] gfortran segmentation fault when a unit number is missing

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2009-07-23 18:09 ---
Subject: Bug 40839

Author: jakub
Date: Thu Jul 23 18:09:43 2009
New Revision: 150021

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150021
Log:
PR fortran/40839
* io.c (gfc_resolve_dt): Add LOC argument.  Fail if
dt->io_unit is NULL.  Return FAILURE after issuing error about
negative UNIT number.
(match_io_element): Don't segfault if current_dt->io_unit is NULL.
* gfortran.h (gfc_resolve_dt): Adjust prototype.
* resolve.c (resolve_code): Adjust caller.

* gfortran.dg/pr40839.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr40839.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/io.c
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/40676] [4.5 Regression] internal compiler error: verify_ssa error: definition in block 5 does not dominate use in block 7

[hjl at gcc dot gnu dot org]

--- Comment #9 from hjl at gcc dot gnu dot org  2009-07-23 17:51 ---
Subject: Bug 40676

Author: hjl
Date: Thu Jul 23 17:50:56 2009
New Revision: 150020

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150020
Log:
2009-07-23  H.J. Lu  

Backport from mainline:
2009-07-22  Richard Guenther  

PR c++/40799
* g++.dg/lookup/using21.C: New testcase.

2009-07-19  Jan Hubicka  

PR tree-optimization/40676
* gcc.c-torture/compile/pr40676.c: New testcase.

2009-07-15  Richard Guenther  

PR middle-end/40753
* gcc.c-torture/compile/pr40753.c: New testcase.

2009-07-14  Dodji Seketeli  

PR debug/40705
* g++.dg/debug/dwarf2/typedef1.C: New test.

PR c++/40357
* g++.dg/other/typedef3.C: New test.

2009-07-10  Richard Guenther  

PR tree-optimization/40496
* g++.dg/opt/pr40496.C: New testcase.

2009-07-09  Jakub Jelinek  

PR middle-end/40692
* gcc.c-torture/compile/pr40692.c: New test.

2009-07-08  Jerry DeLisle  

PR libfortran/40330
PR libfortran/40662
* gfortran.dg/fmt_cache_1.f: New test.

Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/debug/dwarf2/typedef1.C
  - copied unchanged from r150018,
trunk/gcc/testsuite/g++.dg/debug/dwarf2/typedef1.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/lookup/using21.C
  - copied unchanged from r150018,
trunk/gcc/testsuite/g++.dg/lookup/using21.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/opt/pr40496.C
  - copied unchanged from r150018, trunk/gcc/testsuite/g++.dg/opt/pr40496.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/other/typedef3.C
  - copied unchanged from r150018,
trunk/gcc/testsuite/g++.dg/other/typedef3.C
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40676.c
  - copied unchanged from r150018,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40676.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40692.c
  - copied unchanged from r150018,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40692.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40753.c
  - copied unchanged from r150018,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40753.c
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/fmt_cache_1.f
  - copied unchanged from r150018,
trunk/gcc/testsuite/gfortran.dg/fmt_cache_1.f
Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/40692] [4.5 Regression] Endless recursion between fold_ternary and fold_cond_expr_with_comparison

[hjl at gcc dot gnu dot org]

--- Comment #4 from hjl at gcc dot gnu dot org  2009-07-23 17:51 ---
Subject: Bug 40692

Author: hjl
Date: Thu Jul 23 17:50:56 2009
New Revision: 150020

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150020
Log:
2009-07-23  H.J. Lu  

Backport from mainline:
2009-07-22  Richard Guenther  

PR c++/40799
* g++.dg/lookup/using21.C: New testcase.

2009-07-19  Jan Hubicka  

PR tree-optimization/40676
* gcc.c-torture/compile/pr40676.c: New testcase.

2009-07-15  Richard Guenther  

PR middle-end/40753
* gcc.c-torture/compile/pr40753.c: New testcase.

2009-07-14  Dodji Seketeli  

PR debug/40705
* g++.dg/debug/dwarf2/typedef1.C: New test.

PR c++/40357
* g++.dg/other/typedef3.C: New test.

2009-07-10  Richard Guenther  

PR tree-optimization/40496
* g++.dg/opt/pr40496.C: New testcase.

2009-07-09  Jakub Jelinek  

PR middle-end/40692
* gcc.c-torture/compile/pr40692.c: New test.

2009-07-08  Jerry DeLisle  

PR libfortran/40330
PR libfortran/40662
* gfortran.dg/fmt_cache_1.f: New test.

Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/debug/dwarf2/typedef1.C
  - copied unchanged from r150018,
trunk/gcc/testsuite/g++.dg/debug/dwarf2/typedef1.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/lookup/using21.C
  - copied unchanged from r150018,
trunk/gcc/testsuite/g++.dg/lookup/using21.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/opt/pr40496.C
  - copied unchanged from r150018, trunk/gcc/testsuite/g++.dg/opt/pr40496.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/other/typedef3.C
  - copied unchanged from r150018,
trunk/gcc/testsuite/g++.dg/other/typedef3.C
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40676.c
  - copied unchanged from r150018,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40676.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40692.c
  - copied unchanged from r150018,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40692.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40753.c
  - copied unchanged from r150018,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40753.c
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/fmt_cache_1.f
  - copied unchanged from r150018,
trunk/gcc/testsuite/gfortran.dg/fmt_cache_1.f
Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/40496] [4.5 Regression] ICE in verify_stmts with -fprefetch-loop-arrays

[hjl at gcc dot gnu dot org]

--- Comment #6 from hjl at gcc dot gnu dot org  2009-07-23 17:51 ---
Subject: Bug 40496

Author: hjl
Date: Thu Jul 23 17:50:56 2009
New Revision: 150020

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150020
Log:
2009-07-23  H.J. Lu  

Backport from mainline:
2009-07-22  Richard Guenther  

PR c++/40799
* g++.dg/lookup/using21.C: New testcase.

2009-07-19  Jan Hubicka  

PR tree-optimization/40676
* gcc.c-torture/compile/pr40676.c: New testcase.

2009-07-15  Richard Guenther  

PR middle-end/40753
* gcc.c-torture/compile/pr40753.c: New testcase.

2009-07-14  Dodji Seketeli  

PR debug/40705
* g++.dg/debug/dwarf2/typedef1.C: New test.

PR c++/40357
* g++.dg/other/typedef3.C: New test.

2009-07-10  Richard Guenther  

PR tree-optimization/40496
* g++.dg/opt/pr40496.C: New testcase.

2009-07-09  Jakub Jelinek  

PR middle-end/40692
* gcc.c-torture/compile/pr40692.c: New test.

2009-07-08  Jerry DeLisle  

PR libfortran/40330
PR libfortran/40662
* gfortran.dg/fmt_cache_1.f: New test.

Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/debug/dwarf2/typedef1.C
  - copied unchanged from r150018,
trunk/gcc/testsuite/g++.dg/debug/dwarf2/typedef1.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/lookup/using21.C
  - copied unchanged from r150018,
trunk/gcc/testsuite/g++.dg/lookup/using21.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/opt/pr40496.C
  - copied unchanged from r150018, trunk/gcc/testsuite/g++.dg/opt/pr40496.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/other/typedef3.C
  - copied unchanged from r150018,
trunk/gcc/testsuite/g++.dg/other/typedef3.C
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40676.c
  - copied unchanged from r150018,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40676.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40692.c
  - copied unchanged from r150018,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40692.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40753.c
  - copied unchanged from r150018,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40753.c
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/fmt_cache_1.f
  - copied unchanged from r150018,
trunk/gcc/testsuite/gfortran.dg/fmt_cache_1.f
Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug libfortran/40330] [4.5 Regression] incorrect IO

[hjl at gcc dot gnu dot org]

--- Comment #38 from hjl at gcc dot gnu dot org  2009-07-23 17:51 ---
Subject: Bug 40330

Author: hjl
Date: Thu Jul 23 17:50:56 2009
New Revision: 150020

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150020
Log:
2009-07-23  H.J. Lu  

Backport from mainline:
2009-07-22  Richard Guenther  

PR c++/40799
* g++.dg/lookup/using21.C: New testcase.

2009-07-19  Jan Hubicka  

PR tree-optimization/40676
* gcc.c-torture/compile/pr40676.c: New testcase.

2009-07-15  Richard Guenther  

PR middle-end/40753
* gcc.c-torture/compile/pr40753.c: New testcase.

2009-07-14  Dodji Seketeli  

PR debug/40705
* g++.dg/debug/dwarf2/typedef1.C: New test.

PR c++/40357
* g++.dg/other/typedef3.C: New test.

2009-07-10  Richard Guenther  

PR tree-optimization/40496
* g++.dg/opt/pr40496.C: New testcase.

2009-07-09  Jakub Jelinek  

PR middle-end/40692
* gcc.c-torture/compile/pr40692.c: New test.

2009-07-08  Jerry DeLisle  

PR libfortran/40330
PR libfortran/40662
* gfortran.dg/fmt_cache_1.f: New test.

Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/debug/dwarf2/typedef1.C
  - copied unchanged from r150018,
trunk/gcc/testsuite/g++.dg/debug/dwarf2/typedef1.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/lookup/using21.C
  - copied unchanged from r150018,
trunk/gcc/testsuite/g++.dg/lookup/using21.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/opt/pr40496.C
  - copied unchanged from r150018, trunk/gcc/testsuite/g++.dg/opt/pr40496.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/other/typedef3.C
  - copied unchanged from r150018,
trunk/gcc/testsuite/g++.dg/other/typedef3.C
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40676.c
  - copied unchanged from r150018,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40676.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40692.c
  - copied unchanged from r150018,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40692.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40753.c
  - copied unchanged from r150018,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40753.c
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/fmt_cache_1.f
  - copied unchanged from r150018,
trunk/gcc/testsuite/gfortran.dg/fmt_cache_1.f
Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/40662] gfortran 4.5 segfaults when specific FORMAT is invoked twice

[hjl at gcc dot gnu dot org]

--- Comment #7 from hjl at gcc dot gnu dot org  2009-07-23 17:51 ---
Subject: Bug 40662

Author: hjl
Date: Thu Jul 23 17:50:56 2009
New Revision: 150020

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150020
Log:
2009-07-23  H.J. Lu  

Backport from mainline:
2009-07-22  Richard Guenther  

PR c++/40799
* g++.dg/lookup/using21.C: New testcase.

2009-07-19  Jan Hubicka  

PR tree-optimization/40676
* gcc.c-torture/compile/pr40676.c: New testcase.

2009-07-15  Richard Guenther  

PR middle-end/40753
* gcc.c-torture/compile/pr40753.c: New testcase.

2009-07-14  Dodji Seketeli  

PR debug/40705
* g++.dg/debug/dwarf2/typedef1.C: New test.

PR c++/40357
* g++.dg/other/typedef3.C: New test.

2009-07-10  Richard Guenther  

PR tree-optimization/40496
* g++.dg/opt/pr40496.C: New testcase.

2009-07-09  Jakub Jelinek  

PR middle-end/40692
* gcc.c-torture/compile/pr40692.c: New test.

2009-07-08  Jerry DeLisle  

PR libfortran/40330
PR libfortran/40662
* gfortran.dg/fmt_cache_1.f: New test.

Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/debug/dwarf2/typedef1.C
  - copied unchanged from r150018,
trunk/gcc/testsuite/g++.dg/debug/dwarf2/typedef1.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/lookup/using21.C
  - copied unchanged from r150018,
trunk/gcc/testsuite/g++.dg/lookup/using21.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/opt/pr40496.C
  - copied unchanged from r150018, trunk/gcc/testsuite/g++.dg/opt/pr40496.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/other/typedef3.C
  - copied unchanged from r150018,
trunk/gcc/testsuite/g++.dg/other/typedef3.C
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40676.c
  - copied unchanged from r150018,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40676.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40692.c
  - copied unchanged from r150018,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40692.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40753.c
  - copied unchanged from r150018,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40753.c
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/fmt_cache_1.f
  - copied unchanged from r150018,
trunk/gcc/testsuite/gfortran.dg/fmt_cache_1.f
Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/40357] [4.5 Regression] compiler hang for C++ code

[hjl at gcc dot gnu dot org]

--- Comment #8 from hjl at gcc dot gnu dot org  2009-07-23 17:51 ---
Subject: Bug 40357

Author: hjl
Date: Thu Jul 23 17:50:56 2009
New Revision: 150020

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150020
Log:
2009-07-23  H.J. Lu  

Backport from mainline:
2009-07-22  Richard Guenther  

PR c++/40799
* g++.dg/lookup/using21.C: New testcase.

2009-07-19  Jan Hubicka  

PR tree-optimization/40676
* gcc.c-torture/compile/pr40676.c: New testcase.

2009-07-15  Richard Guenther  

PR middle-end/40753
* gcc.c-torture/compile/pr40753.c: New testcase.

2009-07-14  Dodji Seketeli  

PR debug/40705
* g++.dg/debug/dwarf2/typedef1.C: New test.

PR c++/40357
* g++.dg/other/typedef3.C: New test.

2009-07-10  Richard Guenther  

PR tree-optimization/40496
* g++.dg/opt/pr40496.C: New testcase.

2009-07-09  Jakub Jelinek  

PR middle-end/40692
* gcc.c-torture/compile/pr40692.c: New test.

2009-07-08  Jerry DeLisle  

PR libfortran/40330
PR libfortran/40662
* gfortran.dg/fmt_cache_1.f: New test.

Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/debug/dwarf2/typedef1.C
  - copied unchanged from r150018,
trunk/gcc/testsuite/g++.dg/debug/dwarf2/typedef1.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/lookup/using21.C
  - copied unchanged from r150018,
trunk/gcc/testsuite/g++.dg/lookup/using21.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/opt/pr40496.C
  - copied unchanged from r150018, trunk/gcc/testsuite/g++.dg/opt/pr40496.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/other/typedef3.C
  - copied unchanged from r150018,
trunk/gcc/testsuite/g++.dg/other/typedef3.C
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40676.c
  - copied unchanged from r150018,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40676.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40692.c
  - copied unchanged from r150018,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40692.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40753.c
  - copied unchanged from r150018,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40753.c
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/fmt_cache_1.f
  - copied unchanged from r150018,
trunk/gcc/testsuite/gfortran.dg/fmt_cache_1.f
Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug bootstrap/40753] [4.5 Regression] ICE in refs_may_alias_p_1 for libffi/src/powerpc/ffi.c

[hjl at gcc dot gnu dot org]

--- Comment #5 from hjl at gcc dot gnu dot org  2009-07-23 17:51 ---
Subject: Bug 40753

Author: hjl
Date: Thu Jul 23 17:50:56 2009
New Revision: 150020

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150020
Log:
2009-07-23  H.J. Lu  

Backport from mainline:
2009-07-22  Richard Guenther  

PR c++/40799
* g++.dg/lookup/using21.C: New testcase.

2009-07-19  Jan Hubicka  

PR tree-optimization/40676
* gcc.c-torture/compile/pr40676.c: New testcase.

2009-07-15  Richard Guenther  

PR middle-end/40753
* gcc.c-torture/compile/pr40753.c: New testcase.

2009-07-14  Dodji Seketeli  

PR debug/40705
* g++.dg/debug/dwarf2/typedef1.C: New test.

PR c++/40357
* g++.dg/other/typedef3.C: New test.

2009-07-10  Richard Guenther  

PR tree-optimization/40496
* g++.dg/opt/pr40496.C: New testcase.

2009-07-09  Jakub Jelinek  

PR middle-end/40692
* gcc.c-torture/compile/pr40692.c: New test.

2009-07-08  Jerry DeLisle  

PR libfortran/40330
PR libfortran/40662
* gfortran.dg/fmt_cache_1.f: New test.

Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/debug/dwarf2/typedef1.C
  - copied unchanged from r150018,
trunk/gcc/testsuite/g++.dg/debug/dwarf2/typedef1.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/lookup/using21.C
  - copied unchanged from r150018,
trunk/gcc/testsuite/g++.dg/lookup/using21.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/opt/pr40496.C
  - copied unchanged from r150018, trunk/gcc/testsuite/g++.dg/opt/pr40496.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/other/typedef3.C
  - copied unchanged from r150018,
trunk/gcc/testsuite/g++.dg/other/typedef3.C
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40676.c
  - copied unchanged from r150018,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40676.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40692.c
  - copied unchanged from r150018,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40692.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40753.c
  - copied unchanged from r150018,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40753.c
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/fmt_cache_1.f
  - copied unchanged from r150018,
trunk/gcc/testsuite/gfortran.dg/fmt_cache_1.f
Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug debug/40705] [4.5 Regression] ICE in gen_type_die_with_usage, at dwarf2out.c:15117

[hjl at gcc dot gnu dot org]

--- Comment #8 from hjl at gcc dot gnu dot org  2009-07-23 17:51 ---
Subject: Bug 40705

Author: hjl
Date: Thu Jul 23 17:50:56 2009
New Revision: 150020

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150020
Log:
2009-07-23  H.J. Lu  

Backport from mainline:
2009-07-22  Richard Guenther  

PR c++/40799
* g++.dg/lookup/using21.C: New testcase.

2009-07-19  Jan Hubicka  

PR tree-optimization/40676
* gcc.c-torture/compile/pr40676.c: New testcase.

2009-07-15  Richard Guenther  

PR middle-end/40753
* gcc.c-torture/compile/pr40753.c: New testcase.

2009-07-14  Dodji Seketeli  

PR debug/40705
* g++.dg/debug/dwarf2/typedef1.C: New test.

PR c++/40357
* g++.dg/other/typedef3.C: New test.

2009-07-10  Richard Guenther  

PR tree-optimization/40496
* g++.dg/opt/pr40496.C: New testcase.

2009-07-09  Jakub Jelinek  

PR middle-end/40692
* gcc.c-torture/compile/pr40692.c: New test.

2009-07-08  Jerry DeLisle  

PR libfortran/40330
PR libfortran/40662
* gfortran.dg/fmt_cache_1.f: New test.

Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/debug/dwarf2/typedef1.C
  - copied unchanged from r150018,
trunk/gcc/testsuite/g++.dg/debug/dwarf2/typedef1.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/lookup/using21.C
  - copied unchanged from r150018,
trunk/gcc/testsuite/g++.dg/lookup/using21.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/opt/pr40496.C
  - copied unchanged from r150018, trunk/gcc/testsuite/g++.dg/opt/pr40496.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/other/typedef3.C
  - copied unchanged from r150018,
trunk/gcc/testsuite/g++.dg/other/typedef3.C
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40676.c
  - copied unchanged from r150018,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40676.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40692.c
  - copied unchanged from r150018,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40692.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40753.c
  - copied unchanged from r150018,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40753.c
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/fmt_cache_1.f
  - copied unchanged from r150018,
trunk/gcc/testsuite/gfortran.dg/fmt_cache_1.f
Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/40799] [4.5 Regression] Revision 149750 failed 483.xalancbmk in SPEC CPU 2006

[hjl at gcc dot gnu dot org]

--- Comment #10 from hjl at gcc dot gnu dot org  2009-07-23 17:51 ---
Subject: Bug 40799

Author: hjl
Date: Thu Jul 23 17:50:56 2009
New Revision: 150020

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150020
Log:
2009-07-23  H.J. Lu  

Backport from mainline:
2009-07-22  Richard Guenther  

PR c++/40799
* g++.dg/lookup/using21.C: New testcase.

2009-07-19  Jan Hubicka  

PR tree-optimization/40676
* gcc.c-torture/compile/pr40676.c: New testcase.

2009-07-15  Richard Guenther  

PR middle-end/40753
* gcc.c-torture/compile/pr40753.c: New testcase.

2009-07-14  Dodji Seketeli  

PR debug/40705
* g++.dg/debug/dwarf2/typedef1.C: New test.

PR c++/40357
* g++.dg/other/typedef3.C: New test.

2009-07-10  Richard Guenther  

PR tree-optimization/40496
* g++.dg/opt/pr40496.C: New testcase.

2009-07-09  Jakub Jelinek  

PR middle-end/40692
* gcc.c-torture/compile/pr40692.c: New test.

2009-07-08  Jerry DeLisle  

PR libfortran/40330
PR libfortran/40662
* gfortran.dg/fmt_cache_1.f: New test.

Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/debug/dwarf2/typedef1.C
  - copied unchanged from r150018,
trunk/gcc/testsuite/g++.dg/debug/dwarf2/typedef1.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/lookup/using21.C
  - copied unchanged from r150018,
trunk/gcc/testsuite/g++.dg/lookup/using21.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/opt/pr40496.C
  - copied unchanged from r150018, trunk/gcc/testsuite/g++.dg/opt/pr40496.C
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/other/typedef3.C
  - copied unchanged from r150018,
trunk/gcc/testsuite/g++.dg/other/typedef3.C
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40676.c
  - copied unchanged from r150018,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40676.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40692.c
  - copied unchanged from r150018,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40692.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr40753.c
  - copied unchanged from r150018,
trunk/gcc/testsuite/gcc.c-torture/compile/pr40753.c
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/fmt_cache_1.f
  - copied unchanged from r150018,
trunk/gcc/testsuite/gfortran.dg/fmt_cache_1.f
Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/40684] ICE in tsubst

[hjl dot tools at gmail dot com]

-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

   Target Milestone|--- |4.4.1


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

[Bug c++/35989] code rejected in template specialization (4.2 did accept)

[da_cra_hunt at yahoo dot com]

--- Comment #3 from da_cra_hunt at yahoo dot com  2009-07-23 17:34 ---
Simple case :


template struct A {};
template struct B { struct Inner {}; };

template
struct A::Inner> {};


4.1.2/VS2005 compile quietly. 4.3.2 (g++ -c test.cpp) gives :

kk.cpp:5: error: template parameters not used in partial specialization:
kk.cpp:5: error: ‘K’


-- 

da_cra_hunt at yahoo dot com changed:

   What|Removed |Added

 CC||da_cra_hunt at yahoo dot com


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

[Bug bootstrap/37739] [4.4 Regression] bootstrap broken with core gcc > gcc-4.2.x

[jakub at gcc dot gnu dot org]

--- Comment #25 from jakub at gcc dot gnu dot org  2009-07-23 16:56 ---
Is -Wl,--relax passed to the compiler driver when linking the binary that fails
to link then?  If yes, you are looking at a ld problem.


-- 


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

[Bug bootstrap/37739] [4.4 Regression] bootstrap broken with core gcc > gcc-4.2.x

[giffordj at la dot twcbc dot com]

--- Comment #24 from giffordj at la dot twcbc dot com  2009-07-23 16:50 
---
root:/var/build_system/work/gcc-build# grep xmake_file= gcc/Makefile
xmake_file= $(srcdir)/config/rs6000/x-rs6000
$(srcdir)/config/rs6000/x-linux-relax $(srcdir)/config/x-linux

root:/var/build_system$ gcc -Wl,--version
GNU ld (GNU Binutils for Cross-LFS - Retrieved on 20090707) 2.19.1
Copyright 2007 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

This binutils is standard 2.19.1 plus two patches.
The first patch is what's in the 2_19 cvs.
http://svn.cross-lfs.org/svn/repos/patches/binutils/binutils-2.19.1-branch_update-6.patch.
The second patch is updates (That I as a CLFS Developer) thought would fix the
issue on PPC.
http://svn.cross-lfs.org/svn/repos/patches/binutils/binutils-2.19.1-fixes-1.patch


-- 


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

[Bug c++/40828] Rejected valid specialization of member class template

[andhow at gmail dot com]

--- Comment #3 from andhow at gmail dot com  2009-07-23 16:31 ---
That is very strange indeed; sorry for the mistake!


-- 


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

[Bug fortran/40839] gfortran segmentation fault when a unit number is missing

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2009-07-23 16:29 ---
Created an attachment (id=18245)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18245&action=view)
gcc45-pr40839.patch

Patch I'm going to test.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED


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

[Bug tree-optimization/40759] [4.5 Regression] segfault in useless_type_conversion_p

[hubicka at ucw dot cz]

--- Comment #4 from hubicka at ucw dot cz  2009-07-23 16:15 ---
Subject: Re:  [4.5 Regression] segfault in useless_type_conversion_p

Hi,
the problem here is in removing virtual PHI.  We replace uses of the
virtual PHI results by the corresponding VAR_DECL and send symbol for
renaming.  However the replacement is done only for live statements and
we send for renaming only if any live statements are found.

The problem here is that virutal PHI defines vop used by dead statement.
The dead statement however define vop used by live statement.  At the
time we are removing the dead statement, live statement gets former PHI
result, now dead in its vuse.

The following patch solves it by simply updating all uses, dead or
alive.  It woudl be possible to keep this check and add check into code
deleting dead_statements to update when result of dead PHI is propagated
through.

I am bootsrapping/regtesting this version.

Index: tree-ssa-dce.c
===
--- tree-ssa-dce.c  (revision 150009)
+++ tree-ssa-dce.c  (working copy)
@@ -828,9 +828,6 @@ mark_virtual_phi_result_for_renaming (gi
 }
   FOR_EACH_IMM_USE_STMT (stmt, iter, gimple_phi_result (phi))
 {
-  if (gimple_code (stmt) != GIMPLE_PHI
- && !gimple_plf (stmt, STMT_NECESSARY))
-continue;
   FOR_EACH_IMM_USE_ON_STMT (use_p, iter)
 SET_USE (use_p, SSA_NAME_VAR (gimple_phi_result (phi)));
   update_stmt (stmt);


-- 


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

[Bug fortran/40820] gfortran does not recognize -Wno-unused-parameters

[wirawan0 at gmail dot com]

--- Comment #4 from wirawan0 at gmail dot com  2009-07-23 16:03 ---
Sorry for my confusion. It turned out that the option -Wno-unused-parameter (no
s) did work on 4.3.2. Marking this bug as invalid.


-- 

wirawan0 at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/40752] -Wconversion generates false warnings for operands not larger than target type

[manu at gcc dot gnu dot org]

--- Comment #15 from manu at gcc dot gnu dot org  2009-07-23 15:35 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01179.html


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2009-
   ||07/msg01179.html


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

[Bug fortran/40839] New: gfortran segmentation fault when a unit number is missing

[Philippe dot Poilbarbe at cls dot fr]

Compiling this code with gfortran (4.3.2 and 4.3.3, Linux and Solaris) produces
a segmentation fault in gfortran (internal error):
write(fmt='(''STRING'')')
end

Compile command: gfortran FilecontainingCode.f
Message:
f951: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

It is because the unit number has been forgotten.
With this code:
write(*,fmt='(''STRING'')')
end
it works


Gfortran from Mandriva 2009.0

Using built-in specs.
Target: i586-manbo-linux-gnu
Configured with: ../configure --prefix=/usr --libexecdir=/usr/lib
--with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info
--enable-checking=release
--enable-languages=c,c++,ada,fortran,objc,obj-c++,java
--build=i586-manbo-linux-gnu --host=i586-manbo-linux-gnu --with-cpu=generic
--with-system-zlib --enable-threads=posix --enable-shared --enable-long-long
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--enable-java-awt=gtk --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-gtk-cairo
--disable-libjava-multilib --enable-ssp --disable-libssp --disable-werror
Thread model: posix
gcc version 4.3.2 (GCC)


-- 
   Summary: gfortran segmentation fault when a unit number is
missing
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Philippe dot Poilbarbe at cls dot fr


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

[Bug bootstrap/40833] gcc configure problem with mpfr.h

[david dot sagan at gmail dot com]

--- Comment #4 from david dot sagan at gmail dot com  2009-07-23 15:32 
---
> It has nothing to do with the version number.  Read the log file you
> included in your original post.  You'll find

Thanks for the information. As I see it, the problem here is that the error
message from configure: 
  checking for correct version of mpfr.h... no
  configure: error: Building GCC requires GMP 4.1+ and MPFR 2.3.2+.
is wrong in this case. I would suggest that either 1) The error message be
changed to reflect the fact that other things could be wrong or, preferably, 2)
separate the mpfr test into pieces so accurate diagnostic messages can be
generated. 

-- Again Thanks, David


-- 


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

[Bug c++/40834] [4.5 Regression] Revision 149750 failed 483.xalancbmk in SPEC CPU 2006

[rguenther at suse dot de]

--- Comment #3 from rguenther at suse dot de  2009-07-23 15:21 ---
Subject: Re:  [4.5 Regression] Revision 149750 failed
 483.xalancbmk in SPEC CPU 2006

On Thu, 23 Jul 2009, hjl dot tools at gmail dot com wrote:

> --- Comment #2 from hjl dot tools at gmail dot com  2009-07-23 14:40 
> ---
> (In reply to comment #1)
> > Can you try with the patch for 40799 applied before gimplification
> > unit-at-a-time? Does the failure reproduce with the test data or only with 
> > the
> > ref data?
> > 
> 
> I applied the patch for PR 40799 on revision 149748 and
> I got the same failure with both test/ref input data.

Ok, I will have a look next week.  If you can figure out which source
file of 483.xalancbmk has the relevant change until then you receive
extra bonus points ;)  I'm really curious that dropping lang-specific
tree earlier causes problems ...

Richard.


-- 


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

[Bug c++/40828] Rejected valid specialization of member class template

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2009-07-23 15:06 
---
Thanks Jon.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug target/40837] trampolines not working on x86-64 windows vista

[charlet at gcc dot gnu dot org]

--- Comment #6 from charlet at gcc dot gnu dot org  2009-07-23 15:02 ---
My confusion: I thought I had tested with GCC 4.5 but in fact I had used
GCC 4.3 which does not have the 'MINGW_ENABLE_EXECUTE_STACK' macro (and
__enable_execute_stack symbol).

Arno


-- 

charlet at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.4.0
Version|4.5.0   |4.3.4


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

[Bug bootstrap/40833] gcc configure problem with mpfr.h

[kargl at gcc dot gnu dot org]

--- Comment #3 from kargl at gcc dot gnu dot org  2009-07-23 14:55 ---
(In reply to comment #2)
> The commands show:
> 
> lnx498:/nfs/acc/temp/dcs/gcc/gcc_tmp> find /usr -name gmp.h
> /usr/include/gmp.h
> find: /usr/share/ssl/CA: Permission denied
> [1]  + Done  emacs -g 100x80 ~/.chsrc
> lnx498:/nfs/acc/temp/dcs/gcc/gcc_tmp> find /usr -name libgmp\*
> /usr/lib/libgmpxx.a
> /usr/lib/libgmp.so.3
> /usr/lib/libgmpxx.so.3.0.5
> /usr/lib/libgmp.so
> /usr/lib/libgmp.so.3.3.3
> /usr/lib/sse2/libgmp.so.3
> /usr/lib/sse2/libgmpxx.so.3.0.5
> /usr/lib/sse2/libgmp.so.3.3.3
> /usr/lib/sse2/libgmpxx.so.3
> /usr/lib/libgmpxx.so
> /usr/lib/libgmp.a
> /usr/lib/libgmpxx.so.3
> find: /usr/share/ssl/CA: Permission denied
> 
> 
> Yes mpfr was built against a different version of gmp. 
> I did not realize this would make a difference.
> But how does this relate to the message that the version number in mpfr.h is
> not correct when it is?
> 

It has nothing to do with the version number.  Read the log file you
included in your original post.  You'll find

/home/dcs/dcs/usr_local/lib/libmpfr.so: undefined reference to
`__gmpz_tdiv_q_2exp'
/home/dcs/dcs/usr_local/lib/libmpfr.so: undefined reference to
`__gmpz_fdiv_q_2exp'
/home/dcs/dcs/usr_local/lib/libmpfr.so: undefined reference to `__gmpz_clear'
/home/dcs/dcs/usr_local/lib/libmpfr.so: undefined reference to

so the mpfr test never compiled and configure assumes the mpfr
test fails.  

It of course makes a difference.  mpfr must be linked with the version
of libgmp that was used when mpfr was built.


-- 


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

[Bug c++/40834] [4.5 Regression] Revision 149750 failed 483.xalancbmk in SPEC CPU 2006

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2009-07-23 14:40 ---
(In reply to comment #1)
> Can you try with the patch for 40799 applied before gimplification
> unit-at-a-time? Does the failure reproduce with the test data or only with the
> ref data?
> 

I applied the patch for PR 40799 on revision 149748 and
I got the same failure with both test/ref input data.


-- 


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

[Bug other/40784] [4.5 Regression] Revision 149725 caused autoconf warning in libstdc++

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2009-07-23 14:38 ---
Fixed.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mikulas at artax dot karlin dot mff dot cuni dot cz]

--- Comment #10 from mikulas at artax dot karlin dot mff dot cuni dot cz  
2009-07-23 14:36 ---
Jakub: so try that "test $15, %esp; jnz abort" at every function, as I proposed
in bug #38496. There are much more places that will trigger this. Just go catch
them.


-- 


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

[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI

[mikulas at artax dot karlin dot mff dot cuni dot cz]

--- Comment #23 from mikulas at artax dot karlin dot mff dot cuni dot cz  
2009-07-23 14:34 ---
So, Joseph is basically arguing that it doesn't make sense to follow bad
standards. Fine. So let's ignore the "i386 ABI standard" thing for a moment a
look at the change from the practical point of view:

--- If we assume 16-bit stack alignment, who gets the advantage?

* some scientists doing number crunching, it will save stack realign. Most
desktop applications don't use SSE heavily (or not at all). Maybe video players
(most of them have sse in assembler though and don't rely on gcc for sse
generation).

--- If we assume 16-bit stack alignment, what problems will it bring?

* anything called from an inline assembler will have a possibility to fail.
Assembler programmers don't know about this alignment requirement and have been
writing "pushl $0; pushl $1; call function; addl $8, %esp" for ages.

* anything compiled by Intel CC, TCC or other compilers.
Intel CC assumes 4-byte alignment and uses some algorithm to realign only at
certain points (if the function can be only called from stack-aligned
functions, it doesn't have to have the stack realigned). If Intel CC does only
integer arithmetics, it aligns the stack only for 4 bytes.
Intel CC-generated code calls glibc that is being compiled by gcc, so failures
will come from there.

* anything autogenerated (java, dosbox, qemu, firefox 3.5...)

* anything compiled with gcc 2.95.* and earlier.

The worst thing about these failures is that they'll happen only very
sporadically, gcc autovectorizer doesn't generate vector functions in most of
the glibc, so most of the code will be seemingly unaffected. If at random place
in some library gcc vectorizes something and that random place will be called
from any of the above code, the crash will happen. So you'll get crashes at
random points.

To turn these random crashes into deterministic crashes, I suggest to try this.
Hack gcc to generate test $15, %esp; jnz abort at the beginning of every
function. Compile the whole Linux distribution with this gcc. Test it
(including various 3rd party Linux program). If it works, come back later to
this debate and propose how stacks should be 16-byte aligned.


-- 


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

[Bug c++/40828] Rejected valid specialization of member class template

[jwakely dot gcc at gmail dot com]

--- Comment #1 from jwakely dot gcc at gmail dot com  2009-07-23 14:06 
---
The code is invalid.  This is allowed:

template <>
template 
class Outer::Inner {};

but not the other way around.  The diagnostic is correct to say "enclosing
class templates are not explicitly specialized"

See the last specialisation in the example following 14.7.3 [temp.expl.spec]
paragraph 18


-- 


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

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[hjl dot tools at gmail dot com]

--- Comment #9 from hjl dot tools at gmail dot com  2009-07-23 13:56 ---
(In reply to comment #7)
> 
> Another point: if gcc realigns the stack, why then use movdqu to store the
> values on the stack? That is suboptimal.
> 

This is a dup for PR 39315.


-- 


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

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2009-07-23 13:54 ---
Please read Joseph's responses in PR38496.

If you are aware of places in glibc that don't maintain 16 byte stack
alignment, please report them.  Certainly calling glibc (or any other default
compiler flags compiled) library with non-16 byte aligned stack is a bug.

You are free to come up with a different ABI for the OS, but it will not be the
ABI everybody is using.


-- 


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

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mikulas at artax dot karlin dot mff dot cuni dot cz]

--- Comment #7 from mikulas at artax dot karlin dot mff dot cuni dot cz  
2009-07-23 13:49 ---
See bug #27537, quoting "GNU/Linux follows the SYSV x86 ABI which is
documented, maybe you cannot find it but it does exist. The SYSV x86 ABI says
the stack is aligned 4 byte aligned."

That bug seems to reappear.

As Agner noted, 16-byte stack alignment requirement also break compatibility
with Intel CC. I found even some part of current glibc that violates this
16-byte alignment (calling push %eax; call exit from the assembler without
aligning the stack size).

Another point: if gcc realigns the stack, why then use movdqu to store the
values on the stack? That is suboptimal.


-- 


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

[Bug target/40837] trampolines not working on x86-64 windows vista

[sezeroz at gmail dot com]

--- Comment #5 from sezeroz at gmail dot com  2009-07-23 13:46 ---
Compiled my same toolchain on linux-x86_64 and compiled the test for
x86_64-pc-mingw32, the resulting exe prints 369 on Vista-SP2-x64 and exits
normally.


-- 


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

[Bug middle-end/39315] Unaligned move used on aligned stack variable

[hjl dot tools at gmail dot com]

--- Comment #11 from hjl dot tools at gmail dot com  2009-07-23 13:43 
---
*** Bug 40838 has been marked as a duplicate of this bug. ***


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||mikulas at artax dot karlin
   ||dot mff dot cuni dot cz


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

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[hjl dot tools at gmail dot com]

--- Comment #6 from hjl dot tools at gmail dot com  2009-07-23 13:43 ---


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


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug bootstrap/37739] [4.4 Regression] bootstrap broken with core gcc > gcc-4.2.x

[jakub at gcc dot gnu dot org]

--- Comment #23 from jakub at gcc dot gnu dot org  2009-07-23 13:36 ---
Can you please
grep xmake_file= gcc/Makefile
in the gcc build directory as well as write what
gcc -Wl,--version
prints?  Binutils 2.19 and later have the needed relax fixes I think, so
rs6000/x-linux-relax should be used...


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|jakub at gcc dot gnu dot org|unassigned at gcc dot gnu
   ||dot org
 Status|REOPENED|NEW


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

[Bug rtl-optimization/40667] [4.4/4.5 Regression] stack frames are generated even with -fomit-frame-pointer

[mikulas at artax dot karlin dot mff dot cuni dot cz]

--- Comment #20 from mikulas at artax dot karlin dot mff dot cuni dot cz  
2009-07-23 13:28 ---
I see, if it gets spilled to the stack as a local variable, it realigns the
stack, if it doesn't get spilled, it doesn't. But shouldn't "passing the
variable as an argument on the stack" be treated equal to spilling? It is the
same instruction.


-- 


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

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2009-07-23 13:24 ---
The ABI has changed 8+ years ago, you are coming too late.


-- 


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

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mikulas at artax dot karlin dot mff dot cuni dot cz]

--- Comment #4 from mikulas at artax dot karlin dot mff dot cuni dot cz  
2009-07-23 13:19 ---
"Linux/ix86 ABI says that stack must be 16 byte aligned."

No it doesn't. There is a plenty of Linux code that doesn't have the stack
aligned on 16-byte boundary. (at least anything that was compiled with the old
gcc that didn't have -mpreferred-stack-boundary switch).

Please don't change i386 ABI.

AFAIK only MacOSX/x86 enforced aligned stack.


-- 

mikulas at artax dot karlin dot mff dot cuni dot cz changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|DUPLICATE   |


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

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mikulas at artax dot karlin dot mff dot cuni dot cz]

--- Comment #3 from mikulas at artax dot karlin dot mff dot cuni dot cz  
2009-07-23 13:15 ---
What I would propose to fix this and bug #40667:

Each type has required alignment and preferred alignment. Enforced alignment is
what is needed to not crash and not violate the ABI, preferred alignment is the
alignment that has the best performance. For i386, all the types have enforced
alignment 4-byte, except 128-bit SSE type having enforced alignment 16-bytes
(the movdqa instruction crashes otherwise). Preferred alignment is 8 for double
and 8-byte vector types and 16 for long double and 16-byte vector types.

Now, if the function has some variable with the enforced alignment greater than
the ABI standard (4), the stack must be realigned. The ABI mandates 4-byte
alignment and the function may be called from anywhere. As an optimization, the
realign may be skipped if the function is static and it is proved to be called
only from functions with greater or equal enforced alignment and having stack
size aligned.

Each function aligns its stack size to -mpreferred-stack-boundary, which
basically means "if the stack was aligned before (the most common case),
performance will be good". But you can't rely on this for correctness, as in
the pathological cases, the stack doesn't have to be aligned.

As an optimization, if you can prove that the function will call only functions
manipulating types with preferred alignment at most X and X is lower than
-mpreferred-stack-boundary, you can lower stack alignment to X (so that if
there's a call graph of functions using only "double", you don't have to align
the stack on the default 16 bytes, 8 bytes is sufficient).


-- 


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

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2009-07-23 13:13 ---


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


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI

[jakub at gcc dot gnu dot org]

--- Comment #22 from jakub at gcc dot gnu dot org  2009-07-23 13:13 ---
*** Bug 40838 has been marked as a duplicate of this bug. ***


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||mikulas at artax dot karlin
   ||dot mff dot cuni dot cz


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

[Bug target/40837] trampolines not working on x86-64 windows vista

[charlet at gcc dot gnu dot org]

--- Comment #4 from charlet at gcc dot gnu dot org  2009-07-23 13:10 ---
Interesting, thanks for the feedback. Let me double check a few things on
my side (testing various GCC versions).

Arno


-- 


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

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2009-07-23 12:56 ---
Linux/ix86 ABI says that stack must be 16 byte aligned.  So GCC can rely on it.


-- 


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

[Bug rtl-optimization/40838] New: gcc shouldn't assume that the stack is aligned

[mikulas at artax dot karlin dot mff dot cuni dot cz]

typedef int v4si __attribute__ ((vector_size (16)));

v4si y(v4si *s3)
{
return *s3;
}

extern v4si s1, s2;

v4si x(void)
{
v4si s3 = s1 + s2;
return y(&s3);
}

And compile it with -O2 -fno-inline -msse2 -fomit-frame-pointer

The variable s3 is stored using unaligned store (movdqu) and loaded using
aligned load (movdqa). -mpreferred-stack-boundary=4 doesn't guarantee stack
alignment, it only advises that there is stack alignment (the function may be
called from OS callback, signal, another library compiled with lesser
alignment, etc... --- and i386 mandates only 4-byte stack alignment), so use of
movdqa is incorrect. (does GCC ABI mandate that all vector types must be
aligned? If so, then movdqa is correct, but storing it on the stack, relying on
alignment -mpreferred-stack-boundary=4 is not correct).

Now, if you compile it with -mpreferred-stack-boundary=2, function "x" aligns
the stack but uses movdqu to store on the aligned stack, so it generates
suboptimal code.


-- 
   Summary: gcc shouldn't assume that the stack is aligned
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikulas at artax dot karlin dot mff dot cuni dot cz
 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=40838

[Bug target/40837] trampolines not working on x86-64 windows vista

[sezeroz at gmail dot com]

--- Comment #3 from sezeroz at gmail dot com  2009-07-23 12:40 ---
I cross-compile from i686-linux to x86_64-pc-mingw32.  (I can also try
cross-compiling from x86_64-linux to x86_64-pc-mingw32, if you want.)


-- 


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

[Bug bootstrap/40597] Powerpc bootstrap is broken due to changes in expmed.c

[krebbel at gcc dot gnu dot org]

--- Comment #33 from krebbel at gcc dot gnu dot org  2009-07-23 12:37 
---
Your patch from 2009-06-30 prevents the following code from being implemented
jumpless on S/390:

int a, b;
...
int x = a == b;

In emit_store_flag the following code now invokes emit_store_flag_1 instead of
emit_store_flag:
  if ((code == EQ || code == NE) && op1 != const0_rtx)
{
  tem = expand_binop (mode, xor_optab, op0, op1, subtarget, 1,
  OPTAB_WIDEN);

  if (tem == 0)
tem = expand_binop (mode, sub_optab, op0, op1, subtarget, 1,
OPTAB_WIDEN);
  if (tem != 0)
tem = emit_store_flag_1 (target, code, tem, const0_rtx,
 mode, unsignedp, normalizep, target_mode);
  if (tem != 0)
return tem;

  delete_insns_since (last);
}

But emit_store_flag_1 is not sufficient to implement this case jumpless since
the code emitting the abs, sub and neg instructions is only in emit_store_flag:

  if (code == EQ || code == NE)
{
  /* For EQ or NE, one way to do the comparison is to apply an operation
 that converts the operand into a positive number if it is nonzero
 or zero if it was originally zero.  Then, for EQ, we subtract 1 and
 for NE we negate.  This puts the result in the sign bit.  Then we
 normalize with a shift, if needed.
...


-- 

krebbel at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||krebbel at gcc dot gnu dot
   ||org


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

[Bug rtl-optimization/40667] [4.4/4.5 Regression] stack frames are generated even with -fomit-frame-pointer

[jakub at gcc dot gnu dot org]

--- Comment #19 from jakub at gcc dot gnu dot org  2009-07-23 12:33 ---
Because you need to decide whether to use a frame pointer or not before
register allocation, and only during/after register allocation you can find out
that something needs to be spilled to stack.


-- 


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

[Bug target/40837] trampolines not working on x86-64 windows vista

[charlet at gcc dot gnu dot org]

--- Comment #2 from charlet at gcc dot gnu dot org  2009-07-23 12:20 ---
Are you using a 64 bit compiler?


-- 


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

[Bug rtl-optimization/40667] [4.4/4.5 Regression] stack frames are generated even with -fomit-frame-pointer

[mikulas at artax dot karlin dot mff dot cuni dot cz]

--- Comment #18 from mikulas at artax dot karlin dot mff dot cuni dot cz  
2009-07-23 12:16 ---
The bug is this: you don't align the stack and you generate the frame. Why?
Why don't you do one of these?:

* generate the frame and align
* don't generate the frame and don't align

these two would be reasonable, but generating the frame and not aligning is
not.


-- 


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

[Bug middle-end/40830] gcc.dg/vect/vect-pre-interact.c doesn't work on Linux/ia32

[matz at gcc dot gnu dot org]

--- Comment #3 from matz at gcc dot gnu dot org  2009-07-23 12:05 ---
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=40830

[Bug middle-end/40830] gcc.dg/vect/vect-pre-interact.c doesn't work on Linux/ia32

[matz at gcc dot gnu dot org]

--- Comment #2 from matz at gcc dot gnu dot org  2009-07-23 12:03 ---
Subject: Bug 40830

Author: matz
Date: Thu Jul 23 12:02:37 2009
New Revision: 14

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=14
Log:
PR middle-end/40830
* gcc.dg/vect/vect-pre-interact.c: Require vect_float, and
don't set options ourself.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/vect-pre-interact.c


-- 


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

[Bug rtl-optimization/40667] [4.4/4.5 Regression] stack frames are generated even with -fomit-frame-pointer

[jakub at gcc dot gnu dot org]

--- Comment #17 from jakub at gcc dot gnu dot org  2009-07-23 11:36 ---
Incorrect?  Why do you think so?
double on ix86 has 8 byte alignment, and unlike long long it has also
performance effects when you misalign it (in theory, we could handle double the
same as long long with -Os though).  When gcc needs to decide whether to align
the stack or not, it doesn't yet know whether any temporaries of that type will
need to be spilled to stack.  -mpreferred-stack-boundary=2 is typically only
used in the kernel anyway and that one doesn't have floating point stuff, as
this option affects the Linux ABI (you can't call libc functions from code
compiled that way among other things).


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


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

[Bug rtl-optimization/40667] [4.4/4.5 Regression] stack frames are generated even with -fomit-frame-pointer

[mikulas at artax dot karlin dot mff dot cuni dot cz]

--- Comment #16 from mikulas at artax dot karlin dot mff dot cuni dot cz  
2009-07-23 11:18 ---
In the above example, the output of assembler is:

f:
pushl   %ebp
movl%esp, %ebp
subl$8, %esp
fldl8(%ebp)
fstpl   (%esp)
callg
xorl%eax, %eax
leave
ret


-- 


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