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

[jv244 at cam dot ac dot uk]

--- Comment #19 from jv244 at cam dot ac dot uk  2009-06-10 07:22 ---
(In reply to comment #18)
> > I was able to do a regression hunt.  Going to r145209 just before the big 
> > I/O
> > patch eliminates the error.  I then moved forward to r145636 and confirmed 
> > the
> > breakage.
> 
> Is 4.5 also affected?

yes, it is (in addition to the other issues that plague trunk PR40383,
PR40332).


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

Summary|[4.4 Regression] incorrect  |[4.4, 4.5 Regression]
   |IO  |incorrect IO


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

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

[jv244 at cam dot ac dot uk]

--- Comment #20 from jv244 at cam dot ac dot uk  2009-06-10 07:24 ---
(In reply to comment #16)
> Joost, can you explain what the following means?
> 
> CP2K| condition FAILED at line 195
>  CP2K| Abnormal program termination, stopped by process number 0
> Aborted

In this case it means that the file water_1-r-0.inp is corrupted, but I guess
you've found that already. That file is the 'restart' that has just been
written by the part of the code that triggers the valgrind warnings.


-- 


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

[Bug middle-end/40388] [4.5 Regression] another null pointer in remove_unreachable_regions

[dcb314 at hotmail dot com]

--- Comment #2 from dcb314 at hotmail dot com  2009-06-10 08:28 ---
Created an attachment (id=17973)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17973&action=view)
C++ source code


-- 


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

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

[jv244 at cam dot ac dot uk]

--- Comment #21 from jv244 at cam dot ac dot uk  2009-06-10 09:25 ---
reduced testcase:

MODULE M1
 IMPLICIT NONE
CONTAINS
 SUBROUTINE S1(I)
   INTEGER :: I,K
   CHARACTER(LEN=100) :: a,b
   write(a,'(I0,A)') I,"X"
   write(b,*) I
   write(6,FMT='('//TRIM(a)//",a,' ')", ADVANCE="NO") TRIM(b)
 END SUBROUTINE S1
END MODULE

USE M1
CALL S1(3)
CALL S1(3)
END


-- 


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

[Bug middle-end/40391] Segfault with -O, iostream, anonymous namespace on PPC

[jwakely dot gcc at gmail dot com]

--- Comment #4 from jwakely dot gcc at gmail dot com  2009-06-10 10:33 
---
The code is invalid

MyStream::
MyStream ()
  : std::iostream (&m_buf),
m_buf ()
{
}

m_buf has not been cosntructed when you pass it to the base constructor, so
m_buf.init() is called on an uncosntructed streambuf.

You shoudl either pass a null pointer to the base class, then call m_buf.init()
in the MyStream constructor body, or use the base-from-member idiom to
initialise m_buf before the base class.


-- 


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

[Bug c/40394] New: Variable values calculated differently depending on storage class

[goran dot steen at enea dot com]

/* CODE EXAMPLE ***/ 
#include  
#include  

typedef unsigned int U32; 
typedef unsigned short U16; 
typedef unsigned char U8; 

#ifndef __GNUC__ 
#define __attribute__(a) 
#endif /* __GNUC__ */ 
#define APP6DR_PACK_STRUCT __attribute__((packed)) 

#define APP6DR_INLINE_FUNC(func) \ 
   __inline__ func __attribute__((always_inline)); \ 
   extern __inline__ __attribute__((gnu_inline)) func 

struct app6drIpHdr 
{ 
   unsigned int ip_v :4; 
   unsigned int ip_hl :4; 
   U8 ip_tos; 
   U16 ip_len; 
   U16 ip_id; 
   U16 ip_off; 
   U8 ip_ttl; 
   U8 ip_p; 
   U16 ip_sum; 
   struct 
   { 
  U32 ip_sa; 
  U32 ip_da; 
   } ip_addr_r; 
} APP6DR_PACK_STRUCT; 
typedef struct app6drIpHdr App6drIpHdr; 

#define APP6DR_CALC_CSUM(hdr_p,len,cs) App6dr_calcCs16((const char*)(hdr_p),
(len), &(cs)) 
APP6DR_INLINE_FUNC(void App6dr_calcCs16(const char* hdr_p, 
U32 len, 
volatile U16* cs_p)) 
{ 
   U32 i, sum; 
   for(i=0, sum=0; i<(len)/2; i++) 
   { 
  U32 val = ((U32*)hdr_p)[i]; 
  sum += ((val&0x) + (val>>16)); 
   } 
   if ((len) & 1) sum += ((U16*)hdr_p)[(len)-1]; 
   while(sum>>16) sum = (sum&0x)+(sum>>16); 
   *cs_p = (U16)(~sum); 
} 

#define APP6DR_CALC_IPV4_CSUM(ipv4_p) \ 
   (ipv4_p)->ip_sum = 0x; \ 
   APP6DR_CALC_CSUM((char*)(ipv4_p),sizeof(App6drIpHdr)/2,(ipv4_p)->ip_sum) 


#define DOIT() \ 
  memset((void*)&iph, 0xfe, sizeof(App6drIpHdr)); \ 
  iph.ip_v = 4; \ 
  iph.ip_hl = 5; \ 
  iph.ip_tos = 0; \ 
  iph.ip_len = 0; \ 
  iph.ip_id = 0; \ 
  iph.ip_off = 0; \ 
  iph.ip_ttl = 64; /* XXX */ \ 
  iph.ip_p = 50; /* ESP */ \ 
  iph.ip_addr_r.ip_sa = (U32) sa; \ 
  iph.ip_addr_r.ip_da = (U32) da; \ 
  APP6DR_CALC_IPV4_CSUM(&iph);\ 
  fprintf(stderr, "checksum = 0x%04x\n", iph.ip_sum); 


void testchksum2(U32 sa, U32 da) 
{ 
  static App6drIpHdr iph; 
  DOIT(); 
} 

void testchksum1(U32 sa, U32 da) 
{ 
  App6drIpHdr iph; 
  DOIT(); 
} 

int main() 
{ 
testchksum1(0x0a0a0a14, 0x0a0a0a01); 
testchksum2(0x0a0a0a14, 0x0a0a0a01); 
return 0; 
} 
/ END OF CODE EXAMPLE **/ 


Compiled with 
gcc -Os -Wall -pedantic main.c -o runme

Output:
checksum = 0xa89c
checksum = 0xa542

The only difference between outputs are that the variables made calculations on
have different storage classes, ie automatic and static.


-- 
   Summary: Variable values calculated differently depending on
storage class
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: goran dot steen at enea dot com


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

[Bug middle-end/40391] Segfault with -O, iostream, anonymous namespace on PPC

[jwakely dot gcc at gmail dot com]

--- Comment #5 from jwakely dot gcc at gmail dot com  2009-06-10 10:42 
---
(In reply to comment #4)
> 
> You shoudl either pass a null pointer to the base class, then call 
> m_buf.init()

Oops, I got that a bit wrong, don't pass a null pointer to the base
constructor.

You should either call the default constructor of the base class, then call
this->init(&m_buf) ...

> in the MyStream constructor body, or use the base-from-member idiom to
> initialise m_buf before the base class.



-- 


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

[Bug c/40395] New: Variable values calculated differently depending on storage class

[goran dot steen at enea dot com]

/* CODE EXAMPLE ***/ 
#include  
#include  

typedef unsigned int U32; 
typedef unsigned short U16; 
typedef unsigned char U8; 

#ifndef __GNUC__ 
#define __attribute__(a) 
#endif /* __GNUC__ */ 
#define APP6DR_PACK_STRUCT __attribute__((packed)) 

#define APP6DR_INLINE_FUNC(func) \ 
   __inline__ func __attribute__((always_inline)); \ 
   extern __inline__ __attribute__((gnu_inline)) func 

struct app6drIpHdr 
{ 
   unsigned int ip_v :4; 
   unsigned int ip_hl :4; 
   U8 ip_tos; 
   U16 ip_len; 
   U16 ip_id; 
   U16 ip_off; 
   U8 ip_ttl; 
   U8 ip_p; 
   U16 ip_sum; 
   struct 
   { 
  U32 ip_sa; 
  U32 ip_da; 
   } ip_addr_r; 
} APP6DR_PACK_STRUCT; 
typedef struct app6drIpHdr App6drIpHdr; 

#define APP6DR_CALC_CSUM(hdr_p,len,cs) App6dr_calcCs16((const char*)(hdr_p),
(len), &(cs)) 
APP6DR_INLINE_FUNC(void App6dr_calcCs16(const char* hdr_p, 
U32 len, 
volatile U16* cs_p)) 
{ 
   U32 i, sum; 
   for(i=0, sum=0; i<(len)/2; i++) 
   { 
  U32 val = ((U32*)hdr_p)[i]; 
  sum += ((val&0x) + (val>>16)); 
   } 
   if ((len) & 1) sum += ((U16*)hdr_p)[(len)-1]; 
   while(sum>>16) sum = (sum&0x)+(sum>>16); 
   *cs_p = (U16)(~sum); 
} 

#define APP6DR_CALC_IPV4_CSUM(ipv4_p) \ 
   (ipv4_p)->ip_sum = 0x; \ 
   APP6DR_CALC_CSUM((char*)(ipv4_p),sizeof(App6drIpHdr)/2,(ipv4_p)->ip_sum) 


#define DOIT() \ 
  memset((void*)&iph, 0xfe, sizeof(App6drIpHdr)); \ 
  iph.ip_v = 4; \ 
  iph.ip_hl = 5; \ 
  iph.ip_tos = 0; \ 
  iph.ip_len = 0; \ 
  iph.ip_id = 0; \ 
  iph.ip_off = 0; \ 
  iph.ip_ttl = 64; /* XXX */ \ 
  iph.ip_p = 50; /* ESP */ \ 
  iph.ip_addr_r.ip_sa = (U32) sa; \ 
  iph.ip_addr_r.ip_da = (U32) da; \ 
  APP6DR_CALC_IPV4_CSUM(&iph);\ 
  fprintf(stderr, "checksum = 0x%04x\n", iph.ip_sum); 


void testchksum2(U32 sa, U32 da) 
{ 
  static App6drIpHdr iph; 
  DOIT(); 
} 

void testchksum1(U32 sa, U32 da) 
{ 
  App6drIpHdr iph; 
  DOIT(); 
} 

int main() 
{ 
testchksum1(0x0a0a0a14, 0x0a0a0a01); 
testchksum2(0x0a0a0a14, 0x0a0a0a01); 
return 0; 
} 
/ END OF CODE EXAMPLE **/ 


Compiled with 
gcc -Os -Wall -pedantic main.c -o runme

Output:
checksum = 0xa89c
checksum = 0xa542

The only difference between outputs are that the variables made calculations on
have different storage classes, ie automatic and static.


-- 
   Summary: Variable values calculated differently depending on
storage class
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: goran dot steen at enea dot com


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

[Bug c/40396] New: Variable values calculated differently depending on storage class

[goran dot steen at enea dot com]

/* CODE EXAMPLE ***/ 
#include  
#include  

typedef unsigned int U32; 
typedef unsigned short U16; 
typedef unsigned char U8; 

#ifndef __GNUC__ 
#define __attribute__(a) 
#endif /* __GNUC__ */ 
#define APP6DR_PACK_STRUCT __attribute__((packed)) 

#define APP6DR_INLINE_FUNC(func) \ 
   __inline__ func __attribute__((always_inline)); \ 
   extern __inline__ __attribute__((gnu_inline)) func 

struct app6drIpHdr 
{ 
   unsigned int ip_v :4; 
   unsigned int ip_hl :4; 
   U8 ip_tos; 
   U16 ip_len; 
   U16 ip_id; 
   U16 ip_off; 
   U8 ip_ttl; 
   U8 ip_p; 
   U16 ip_sum; 
   struct 
   { 
  U32 ip_sa; 
  U32 ip_da; 
   } ip_addr_r; 
} APP6DR_PACK_STRUCT; 
typedef struct app6drIpHdr App6drIpHdr; 

#define APP6DR_CALC_CSUM(hdr_p,len,cs) App6dr_calcCs16((const char*)(hdr_p),
(len), &(cs)) 
APP6DR_INLINE_FUNC(void App6dr_calcCs16(const char* hdr_p, 
U32 len, 
volatile U16* cs_p)) 
{ 
   U32 i, sum; 
   for(i=0, sum=0; i<(len)/2; i++) 
   { 
  U32 val = ((U32*)hdr_p)[i]; 
  sum += ((val&0x) + (val>>16)); 
   } 
   if ((len) & 1) sum += ((U16*)hdr_p)[(len)-1]; 
   while(sum>>16) sum = (sum&0x)+(sum>>16); 
   *cs_p = (U16)(~sum); 
} 

#define APP6DR_CALC_IPV4_CSUM(ipv4_p) \ 
   (ipv4_p)->ip_sum = 0x; \ 
   APP6DR_CALC_CSUM((char*)(ipv4_p),sizeof(App6drIpHdr)/2,(ipv4_p)->ip_sum) 


#define DOIT() \ 
  memset((void*)&iph, 0xfe, sizeof(App6drIpHdr)); \ 
  iph.ip_v = 4; \ 
  iph.ip_hl = 5; \ 
  iph.ip_tos = 0; \ 
  iph.ip_len = 0; \ 
  iph.ip_id = 0; \ 
  iph.ip_off = 0; \ 
  iph.ip_ttl = 64; /* XXX */ \ 
  iph.ip_p = 50; /* ESP */ \ 
  iph.ip_addr_r.ip_sa = (U32) sa; \ 
  iph.ip_addr_r.ip_da = (U32) da; \ 
  APP6DR_CALC_IPV4_CSUM(&iph);\ 
  fprintf(stderr, "checksum = 0x%04x\n", iph.ip_sum); 


void testchksum2(U32 sa, U32 da) 
{ 
  static App6drIpHdr iph; 
  DOIT(); 
} 

void testchksum1(U32 sa, U32 da) 
{ 
  App6drIpHdr iph; 
  DOIT(); 
} 

int main() 
{ 
testchksum1(0x0a0a0a14, 0x0a0a0a01); 
testchksum2(0x0a0a0a14, 0x0a0a0a01); 
return 0; 
} 
/ END OF CODE EXAMPLE **/ 


Compiled with 
gcc -Os -Wall -pedantic main.c -o runme

Output:
checksum = 0xa89c
checksum = 0xa542

The only difference between outputs are that the variables made calculations on
have different storage classes, ie automatic and static.


-- 
   Summary: Variable values calculated differently depending on
storage class
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: goran dot steen at enea dot com


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

[Bug c/40397] New: Variable values calculated differently depending on storage class

[goran dot steen at enea dot com]

/* CODE EXAMPLE ***/ 
#include  
#include  

typedef unsigned int U32; 
typedef unsigned short U16; 
typedef unsigned char U8; 

#ifndef __GNUC__ 
#define __attribute__(a) 
#endif /* __GNUC__ */ 
#define APP6DR_PACK_STRUCT __attribute__((packed)) 

#define APP6DR_INLINE_FUNC(func) \ 
   __inline__ func __attribute__((always_inline)); \ 
   extern __inline__ __attribute__((gnu_inline)) func 

struct app6drIpHdr 
{ 
   unsigned int ip_v :4; 
   unsigned int ip_hl :4; 
   U8 ip_tos; 
   U16 ip_len; 
   U16 ip_id; 
   U16 ip_off; 
   U8 ip_ttl; 
   U8 ip_p; 
   U16 ip_sum; 
   struct 
   { 
  U32 ip_sa; 
  U32 ip_da; 
   } ip_addr_r; 
} APP6DR_PACK_STRUCT; 
typedef struct app6drIpHdr App6drIpHdr; 

#define APP6DR_CALC_CSUM(hdr_p,len,cs) App6dr_calcCs16((const char*)(hdr_p),
(len), &(cs)) 
APP6DR_INLINE_FUNC(void App6dr_calcCs16(const char* hdr_p, 
U32 len, 
volatile U16* cs_p)) 
{ 
   U32 i, sum; 
   for(i=0, sum=0; i<(len)/2; i++) 
   { 
  U32 val = ((U32*)hdr_p)[i]; 
  sum += ((val&0x) + (val>>16)); 
   } 
   if ((len) & 1) sum += ((U16*)hdr_p)[(len)-1]; 
   while(sum>>16) sum = (sum&0x)+(sum>>16); 
   *cs_p = (U16)(~sum); 
} 

#define APP6DR_CALC_IPV4_CSUM(ipv4_p) \ 
   (ipv4_p)->ip_sum = 0x; \ 
   APP6DR_CALC_CSUM((char*)(ipv4_p),sizeof(App6drIpHdr)/2,(ipv4_p)->ip_sum) 


#define DOIT() \ 
  memset((void*)&iph, 0xfe, sizeof(App6drIpHdr)); \ 
  iph.ip_v = 4; \ 
  iph.ip_hl = 5; \ 
  iph.ip_tos = 0; \ 
  iph.ip_len = 0; \ 
  iph.ip_id = 0; \ 
  iph.ip_off = 0; \ 
  iph.ip_ttl = 64; /* XXX */ \ 
  iph.ip_p = 50; /* ESP */ \ 
  iph.ip_addr_r.ip_sa = (U32) sa; \ 
  iph.ip_addr_r.ip_da = (U32) da; \ 
  APP6DR_CALC_IPV4_CSUM(&iph);\ 
  fprintf(stderr, "checksum = 0x%04x\n", iph.ip_sum); 


void testchksum2(U32 sa, U32 da) 
{ 
  static App6drIpHdr iph; 
  DOIT(); 
} 

void testchksum1(U32 sa, U32 da) 
{ 
  App6drIpHdr iph; 
  DOIT(); 
} 

int main() 
{ 
testchksum1(0x0a0a0a14, 0x0a0a0a01); 
testchksum2(0x0a0a0a14, 0x0a0a0a01); 
return 0; 
} 
/ END OF CODE EXAMPLE **/ 


Compiled with 
gcc -Os -Wall -pedantic main.c -o runme

Output:
checksum = 0xa89c
checksum = 0xa542

The only difference between outputs are that the variables made calculations on
have different storage classes, ie automatic and static.


-- 
   Summary: Variable values calculated differently depending on
storage class
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: goran dot steen at enea dot com


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

[Bug c/40398] New: Variable values calculated differently depending on storage class

[goran dot steen at enea dot com]

/* CODE EXAMPLE ***/ 
#include  
#include  

typedef unsigned int U32; 
typedef unsigned short U16; 
typedef unsigned char U8; 

#ifndef __GNUC__ 
#define __attribute__(a) 
#endif /* __GNUC__ */ 
#define APP6DR_PACK_STRUCT __attribute__((packed)) 

#define APP6DR_INLINE_FUNC(func) \ 
   __inline__ func __attribute__((always_inline)); \ 
   extern __inline__ __attribute__((gnu_inline)) func 

struct app6drIpHdr 
{ 
   unsigned int ip_v :4; 
   unsigned int ip_hl :4; 
   U8 ip_tos; 
   U16 ip_len; 
   U16 ip_id; 
   U16 ip_off; 
   U8 ip_ttl; 
   U8 ip_p; 
   U16 ip_sum; 
   struct 
   { 
  U32 ip_sa; 
  U32 ip_da; 
   } ip_addr_r; 
} APP6DR_PACK_STRUCT; 
typedef struct app6drIpHdr App6drIpHdr; 

#define APP6DR_CALC_CSUM(hdr_p,len,cs) App6dr_calcCs16((const char*)(hdr_p),
(len), &(cs)) 
APP6DR_INLINE_FUNC(void App6dr_calcCs16(const char* hdr_p, 
U32 len, 
volatile U16* cs_p)) 
{ 
   U32 i, sum; 
   for(i=0, sum=0; i<(len)/2; i++) 
   { 
  U32 val = ((U32*)hdr_p)[i]; 
  sum += ((val&0x) + (val>>16)); 
   } 
   if ((len) & 1) sum += ((U16*)hdr_p)[(len)-1]; 
   while(sum>>16) sum = (sum&0x)+(sum>>16); 
   *cs_p = (U16)(~sum); 
} 

#define APP6DR_CALC_IPV4_CSUM(ipv4_p) \ 
   (ipv4_p)->ip_sum = 0x; \ 
   APP6DR_CALC_CSUM((char*)(ipv4_p),sizeof(App6drIpHdr)/2,(ipv4_p)->ip_sum) 


#define DOIT() \ 
  memset((void*)&iph, 0xfe, sizeof(App6drIpHdr)); \ 
  iph.ip_v = 4; \ 
  iph.ip_hl = 5; \ 
  iph.ip_tos = 0; \ 
  iph.ip_len = 0; \ 
  iph.ip_id = 0; \ 
  iph.ip_off = 0; \ 
  iph.ip_ttl = 64; /* XXX */ \ 
  iph.ip_p = 50; /* ESP */ \ 
  iph.ip_addr_r.ip_sa = (U32) sa; \ 
  iph.ip_addr_r.ip_da = (U32) da; \ 
  APP6DR_CALC_IPV4_CSUM(&iph);\ 
  fprintf(stderr, "checksum = 0x%04x\n", iph.ip_sum); 


void testchksum2(U32 sa, U32 da) 
{ 
  static App6drIpHdr iph; 
  DOIT(); 
} 

void testchksum1(U32 sa, U32 da) 
{ 
  App6drIpHdr iph; 
  DOIT(); 
} 

int main() 
{ 
testchksum1(0x0a0a0a14, 0x0a0a0a01); 
testchksum2(0x0a0a0a14, 0x0a0a0a01); 
return 0; 
} 
/ END OF CODE EXAMPLE **/ 


Compiled with 
gcc -Os -Wall -pedantic main.c -o runme

Output:
checksum = 0xa89c
checksum = 0xa542

The only difference between outputs are that the variables made calculations on
have different storage classes, ie automatic and static.


-- 
   Summary: Variable values calculated differently depending on
storage class
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: goran dot steen at enea dot com


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

[Bug c/40399] New: Variable values calculated differently depending on storage class

[goran dot steen at enea dot com]

/* CODE EXAMPLE ***/ 
#include  
#include  

typedef unsigned int U32; 
typedef unsigned short U16; 
typedef unsigned char U8; 

#ifndef __GNUC__ 
#define __attribute__(a) 
#endif /* __GNUC__ */ 
#define APP6DR_PACK_STRUCT __attribute__((packed)) 

#define APP6DR_INLINE_FUNC(func) \ 
   __inline__ func __attribute__((always_inline)); \ 
   extern __inline__ __attribute__((gnu_inline)) func 

struct app6drIpHdr 
{ 
   unsigned int ip_v :4; 
   unsigned int ip_hl :4; 
   U8 ip_tos; 
   U16 ip_len; 
   U16 ip_id; 
   U16 ip_off; 
   U8 ip_ttl; 
   U8 ip_p; 
   U16 ip_sum; 
   struct 
   { 
  U32 ip_sa; 
  U32 ip_da; 
   } ip_addr_r; 
} APP6DR_PACK_STRUCT; 
typedef struct app6drIpHdr App6drIpHdr; 

#define APP6DR_CALC_CSUM(hdr_p,len,cs) App6dr_calcCs16((const char*)(hdr_p),
(len), &(cs)) 
APP6DR_INLINE_FUNC(void App6dr_calcCs16(const char* hdr_p, 
U32 len, 
volatile U16* cs_p)) 
{ 
   U32 i, sum; 
   for(i=0, sum=0; i<(len)/2; i++) 
   { 
  U32 val = ((U32*)hdr_p)[i]; 
  sum += ((val&0x) + (val>>16)); 
   } 
   if ((len) & 1) sum += ((U16*)hdr_p)[(len)-1]; 
   while(sum>>16) sum = (sum&0x)+(sum>>16); 
   *cs_p = (U16)(~sum); 
} 

#define APP6DR_CALC_IPV4_CSUM(ipv4_p) \ 
   (ipv4_p)->ip_sum = 0x; \ 
   APP6DR_CALC_CSUM((char*)(ipv4_p),sizeof(App6drIpHdr)/2,(ipv4_p)->ip_sum) 


#define DOIT() \ 
  memset((void*)&iph, 0xfe, sizeof(App6drIpHdr)); \ 
  iph.ip_v = 4; \ 
  iph.ip_hl = 5; \ 
  iph.ip_tos = 0; \ 
  iph.ip_len = 0; \ 
  iph.ip_id = 0; \ 
  iph.ip_off = 0; \ 
  iph.ip_ttl = 64; /* XXX */ \ 
  iph.ip_p = 50; /* ESP */ \ 
  iph.ip_addr_r.ip_sa = (U32) sa; \ 
  iph.ip_addr_r.ip_da = (U32) da; \ 
  APP6DR_CALC_IPV4_CSUM(&iph);\ 
  fprintf(stderr, "checksum = 0x%04x\n", iph.ip_sum); 


void testchksum2(U32 sa, U32 da) 
{ 
  static App6drIpHdr iph; 
  DOIT(); 
} 

void testchksum1(U32 sa, U32 da) 
{ 
  App6drIpHdr iph; 
  DOIT(); 
} 

int main() 
{ 
testchksum1(0x0a0a0a14, 0x0a0a0a01); 
testchksum2(0x0a0a0a14, 0x0a0a0a01); 
return 0; 
} 
/ END OF CODE EXAMPLE **/ 


Compiled with 
gcc -Os -Wall -pedantic main.c -o runme

Output:
checksum = 0xa89c
checksum = 0xa542

The only difference between outputs are that the variables made calculations on
have different storage classes, ie automatic and static.


-- 
   Summary: Variable values calculated differently depending on
storage class
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: goran dot steen at enea dot com


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

[Bug target/26397] Program crashes when rethrowing exception

[jwakely dot gcc at gmail dot com]

--- Comment #13 from jwakely dot gcc at gmail dot com  2009-06-10 11:45 
---
(In reply to comment #12)
> Subject: Bug 26397
> 
> Author: dje
> Date: Thu Nov  6 15:32:40 2008
> New Revision: 141646
> 
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141646
> Log:
> PR target/26397
> * config/rs6000/aix.h (LIBSTDCXX_STATIC): Define.
> 
> cp/
> * g++spec.c (LIBSTDCXX_STATIC): New.
> (lang_spec_driver): Use LIBSTDCXX_STATIC when not shared_libgcc.
> 
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/config/rs6000/aix.h
> trunk/gcc/cp/ChangeLog
> trunk/gcc/cp/g++spec.c
> 

http://gcc.gnu.org/ml/gcc/2009-06/msg00231.html shows that the string "-lstdc++
-lsupc++" is passed to collect2 as a single argument via execvp, resulting in
an attempt to link to "libstdc++ -lsupc++" which is not valid.


-- 


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

[Bug middle-end/40388] [4.5 Regression] another null pointer in remove_unreachable_regions

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2009-06-10 12:00 ---
It is caused by revision 146776:

http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01418.html


-- 


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

[Bug fortran/40383] [4.5 Regression] incorrect bounds checking with optional character arguments

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2009-06-10 12:02 ---
Patch -- I believe it does the right thing; especially, it preserves
backend_decl. If one copied the type earlier, the backend_decl would be
different and the backend does not like it, when the same type has different
declarations. (It still happens independent of this patch, but it makes sense
not to make the problem worse; cf. PR 38913. The "->next" should also be
correct, I think.

--- trans-decl.c(revision 148340)
+++ trans-decl.c(working copy)
@@ -1694,6 +1694,22 @@ create_function_arglist (gfc_symbol * sy
  gfc_finish_decl (length);

  /* Remember the passed value.  */
+  if (f->sym->ts.cl->passed_length != NULL)
+{
+ /* This can happen if the same type is used for multiple
+arguments. We need to copy cl as otherwise
+cl->passed_length gets overwritten.  */
+ gfc_charlen *cl, *cl2;
+ cl = f->sym->ts.cl;
+ f->sym->ts.cl = gfc_get_charlen();
+ f->sym->ts.cl->length = cl->length;
+ f->sym->ts.cl->backend_decl = cl->backend_decl;
+ f->sym->ts.cl->length_from_typespec = cl->length_from_typespec;
+ f->sym->ts.cl->resolved = cl->resolved;
+ cl2 = f->sym->ts.cl->next;
+ f->sym->ts.cl->next = cl;
+  cl->next = cl2;
+}
  f->sym->ts.cl->passed_length = length;

  /* Use the passed value for assumed length variables.  */


-- 


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

[Bug fortran/40383] [4.5 Regression] incorrect bounds checking with optional character arguments

[burnus at gcc dot gnu dot org]

--- Comment #5 from burnus at gcc dot gnu dot org  2009-06-10 12:05 ---
Forgot to mention: I will not be able to regtest/submit the patch before Monday
evening.


-- 


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

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

[jvdelisle at gcc dot gnu dot org]

--- Comment #22 from jvdelisle at gcc dot gnu dot org  2009-06-10 12:32 
---
Thanks for reduced test.

$ ./a.out >badfile
$ xxd badfile 
000: 2020 2020 2020 2020 2020 2020 2020 33203 
010: 2020 2020 2020 2020 2020 2020 2020 33003.

The NULL in the last byte should be a space.


-- 


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

[Bug c/40400] New: Variable values calculated differently depending on storage class

[goran dot steen at enea dot com]

/* CODE EXAMPLE ***/ 
#include  
#include  

typedef unsigned int U32; 
typedef unsigned short U16; 
typedef unsigned char U8; 

#ifndef __GNUC__ 
#define __attribute__(a) 
#endif /* __GNUC__ */ 
#define APP6DR_PACK_STRUCT __attribute__((packed)) 

#define APP6DR_INLINE_FUNC(func) \ 
   __inline__ func __attribute__((always_inline)); \ 
   extern __inline__ __attribute__((gnu_inline)) func 

struct app6drIpHdr 
{ 
   unsigned int ip_v :4; 
   unsigned int ip_hl :4; 
   U8 ip_tos; 
   U16 ip_len; 
   U16 ip_id; 
   U16 ip_off; 
   U8 ip_ttl; 
   U8 ip_p; 
   U16 ip_sum; 
   struct 
   { 
  U32 ip_sa; 
  U32 ip_da; 
   } ip_addr_r; 
} APP6DR_PACK_STRUCT; 
typedef struct app6drIpHdr App6drIpHdr; 

#define APP6DR_CALC_CSUM(hdr_p,len,cs) App6dr_calcCs16((const char*)(hdr_p),
(len), &(cs)) 
APP6DR_INLINE_FUNC(void App6dr_calcCs16(const char* hdr_p, 
U32 len, 
volatile U16* cs_p)) 
{ 
   U32 i, sum; 
   for(i=0, sum=0; i<(len)/2; i++) 
   { 
  U32 val = ((U32*)hdr_p)[i]; 
  sum += ((val&0x) + (val>>16)); 
   } 
   if ((len) & 1) sum += ((U16*)hdr_p)[(len)-1]; 
   while(sum>>16) sum = (sum&0x)+(sum>>16); 
   *cs_p = (U16)(~sum); 
} 

#define APP6DR_CALC_IPV4_CSUM(ipv4_p) \ 
   (ipv4_p)->ip_sum = 0x; \ 
   APP6DR_CALC_CSUM((char*)(ipv4_p),sizeof(App6drIpHdr)/2,(ipv4_p)->ip_sum) 


#define DOIT() \ 
  memset((void*)&iph, 0xfe, sizeof(App6drIpHdr)); \ 
  iph.ip_v = 4; \ 
  iph.ip_hl = 5; \ 
  iph.ip_tos = 0; \ 
  iph.ip_len = 0; \ 
  iph.ip_id = 0; \ 
  iph.ip_off = 0; \ 
  iph.ip_ttl = 64; /* XXX */ \ 
  iph.ip_p = 50; /* ESP */ \ 
  iph.ip_addr_r.ip_sa = (U32) sa; \ 
  iph.ip_addr_r.ip_da = (U32) da; \ 
  APP6DR_CALC_IPV4_CSUM(&iph);\ 
  fprintf(stderr, "checksum = 0x%04x\n", iph.ip_sum); 


void testchksum2(U32 sa, U32 da) 
{ 
  static App6drIpHdr iph; 
  DOIT(); 
} 

void testchksum1(U32 sa, U32 da) 
{ 
  App6drIpHdr iph; 
  DOIT(); 
} 

int main() 
{ 
testchksum1(0x0a0a0a14, 0x0a0a0a01); 
testchksum2(0x0a0a0a14, 0x0a0a0a01); 
return 0; 
} 
/ END OF CODE EXAMPLE **/ 


Compiled with 
gcc -Os -Wall -pedantic main.c -o runme

Output:
checksum = 0xa89c
checksum = 0xa542

The only difference between outputs are that the variables made calculations on
have different storage classes, ie automatic and static.


-- 
   Summary: Variable values calculated differently depending on
storage class
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: goran dot steen at enea dot com


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

[Bug c/40395] Variable values calculated differently depending on storage class

[goran dot steen at enea dot com]

--- Comment #1 from goran dot steen at enea dot com  2009-06-10 12:42 
---


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


-- 

goran dot steen at enea dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c/40394] Variable values calculated differently depending on storage class

[goran dot steen at enea dot com]

--- Comment #1 from goran dot steen at enea dot com  2009-06-10 12:42 
---
*** Bug 40395 has been marked as a duplicate of this bug. ***


-- 


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

[Bug c/40396] Variable values calculated differently depending on storage class

[goran dot steen at enea dot com]

--- Comment #1 from goran dot steen at enea dot com  2009-06-10 12:42 
---


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


-- 

goran dot steen at enea dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c/40394] Variable values calculated differently depending on storage class

[goran dot steen at enea dot com]

--- Comment #2 from goran dot steen at enea dot com  2009-06-10 12:42 
---
*** Bug 40396 has been marked as a duplicate of this bug. ***


-- 


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

[Bug c/40394] Variable values calculated differently depending on storage class

[goran dot steen at enea dot com]

--- Comment #3 from goran dot steen at enea dot com  2009-06-10 12:42 
---
*** Bug 40397 has been marked as a duplicate of this bug. ***


-- 


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

[Bug c/40397] Variable values calculated differently depending on storage class

[goran dot steen at enea dot com]

--- Comment #1 from goran dot steen at enea dot com  2009-06-10 12:42 
---


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


-- 

goran dot steen at enea dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c/40394] Variable values calculated differently depending on storage class

[goran dot steen at enea dot com]

--- Comment #4 from goran dot steen at enea dot com  2009-06-10 12:43 
---
*** Bug 40398 has been marked as a duplicate of this bug. ***


-- 


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

[Bug c/40398] Variable values calculated differently depending on storage class

[goran dot steen at enea dot com]

--- Comment #1 from goran dot steen at enea dot com  2009-06-10 12:43 
---


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


-- 

goran dot steen at enea dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c/40394] Variable values calculated differently depending on storage class

[goran dot steen at enea dot com]

--- Comment #5 from goran dot steen at enea dot com  2009-06-10 12:43 
---
*** Bug 40399 has been marked as a duplicate of this bug. ***


-- 


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

[Bug c/40399] Variable values calculated differently depending on storage class

[goran dot steen at enea dot com]

--- Comment #1 from goran dot steen at enea dot com  2009-06-10 12:43 
---


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


-- 

goran dot steen at enea dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c/40400] Variable values calculated differently depending on storage class

[goran dot steen at enea dot com]

--- Comment #1 from goran dot steen at enea dot com  2009-06-10 12:43 
---


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


-- 

goran dot steen at enea dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c/40394] Variable values calculated differently depending on storage class

[goran dot steen at enea dot com]

--- Comment #6 from goran dot steen at enea dot com  2009-06-10 12:43 
---
*** Bug 40400 has been marked as a duplicate of this bug. ***


-- 


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

[Bug middle-end/40391] Segfault with -O, iostream, anonymous namespace on PPC

[fp at mc dot com]

--- Comment #6 from fp at mc dot com  2009-06-10 12:50 ---
Jonathan,

thank you for identifying the bug in my original code.

According to my copy of ISO 14992:1998, std::iostream does not have a default
constructor.  However, my reading of the standard leads me to believe that it
is valid to pass a null pointer.  The description for basic_ios::init()
(27.4.4.1) says that, as a postcondition, rdstate() is "goodbit if sb is not a
null pointer, otherwise badbit".

libstdc++ does provide a default constructor for std::iostream.

However, either way, passing a null std::streambuf pointer to std::iostream
(which I believe is valid), or calling the "gcc extension" default constructor,
both still lead to a crash.

I've looked at the source code for std::iostream and its base classes and it
does not appear to dereference sb, it merely assigns the pointer to a meber
variable and tests it for non-null.

I am updating the test case.

Can someone please do me a favor and test this with a more current version of
gcc?


-- 


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

[Bug middle-end/40391] Segfault with -O, iostream, anonymous namespace on PPC

[fp at mc dot com]

--- Comment #7 from fp at mc dot com  2009-06-10 12:51 ---
Created an attachment (id=17974)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17974&action=view)
iostest.zip

Fixes test case to avoid invalid code.  (Passes null pointer to base class then
calls this->init(&m_buf).)


-- 

fp at mc dot com changed:

   What|Removed |Added

  Attachment #17972|0   |1
is obsolete||


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

[Bug middle-end/40391] Segfault with -O, iostream, anonymous namespace on PPC

[jwakely dot gcc at gmail dot com]

--- Comment #8 from jwakely dot gcc at gmail dot com  2009-06-10 13:09 
---
(In reply to comment #6)
> According to my copy of ISO 14992:1998, std::iostream does not have a default
> constructor.  However, my reading of the standard leads me to believe that it
> is valid to pass a null pointer.  The description for basic_ios::init()
> (27.4.4.1) says that, as a postcondition, rdstate() is "goodbit if sb is not a
> null pointer, otherwise badbit".

You're right, I should have checked before replying.

> Can someone please do me a favor and test this with a more current version of
> gcc?

I can't test on ppc. Where is the segfault? gdb or valgrind should tell you.



-- 


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

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

[jv244 at cam dot ac dot uk]

--- Comment #23 from jv244 at cam dot ac dot uk  2009-06-10 13:18 ---
(In reply to comment #22)
> Thanks for reduced test.
> 
> $ ./a.out >badfile
> $ xxd badfile 
> 000: 2020 2020 2020 2020 2020 2020 2020 33203 
> 010: 2020 2020 2020 2020 2020 2020 2020 33003.
> 
> The NULL in the last byte should be a space.

I guess this is try as well, in addition there are also the same valgrind
warnings about using data from a deallocated buffer:

==24239== Invalid read of size 1
==24239==at 0x4BE3C4C: formatted_transfer (transfer.c:874)
==24239==by 0x400D21: __m1_MOD_s1 (t.f90:9)
==24239==by 0x400D91: MAIN__ (t.f90:15)
==24239==by 0x400DC9: main (fmain.c:21)
==24239==  Address 0x55da8a6 is 6 bytes inside a block of size 640 free'd
==24239==at 0x4A2196E: free (vg_replace_malloc.c:323)
==24239==by 0x400D5E: __m1_MOD_s1 (t.f90:9)
==24239==by 0x400D87: MAIN__ (t.f90:14)
==24239==by 0x400DC9: main (fmain.c:21)
==24239==
==24239== Invalid read of size 1
==24239==at 0x4BE3C60: formatted_transfer (transfer.c:878)
==24239==by 0x400D21: __m1_MOD_s1 (t.f90:9)
==24239==by 0x400D91: MAIN__ (t.f90:15)
==24239==by 0x400DC9: main (fmain.c:21)
==24239==  Address 0x55da8a7 is 7 bytes inside a block of size 640 free'd
==24239==at 0x4A2196E: free (vg_replace_malloc.c:323)
==24239==by 0x400D5E: __m1_MOD_s1 (t.f90:9)
==24239==by 0x400D87: MAIN__ (t.f90:14)
==24239==by 0x400DC9: main (fmain.c:21)


-- 


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

[Bug middle-end/40391] Segfault with -O, iostream, anonymous namespace on PPC

[fp at mc dot com]

--- Comment #9 from fp at mc dot com  2009-06-10 13:18 ---
gdb reports

Program received signal SIGSEGV, Segmentation fault.
0x10001384 in make ()
at
/opt/timesys/toolchains/lib/gcc/powerpc-timesys-linux-gnu/4.2.1/../../../../powerpc-timesys-linux-gnu/include/c++/4.2.1/ostream:366
366   basic_ostream() { }

which doesn't look very helpful.  I'll attach the result from "disassemble".


-- 


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

[Bug middle-end/40391] Segfault with -O, iostream, anonymous namespace on PPC

[fp at mc dot com]

--- Comment #10 from fp at mc dot com  2009-06-10 13:20 ---
Created an attachment (id=17975)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17975&action=view)
disassemble.txt

Assembly dump of the function that crashes.  gdb reports that the crash occurs
at address 0x10001384.


-- 


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

[Bug middle-end/40401] New: ICE: verify_gimple failed

[rmansfield at qnx dot com]

$ cat /home/ryan/ice.i
typedef void (*malloc_error_fptr_t)(const char * const __file, unsigned int
__lineno, const char * const __msg);
extern void (*_malloc_error)(const char *file, unsigned int lineno, const char
*msg);

void _malloc_error_internal(const char * const fn);
malloc_error_fptr_t _malloc_error = _malloc_error_internal;

void malloc_abort(int status) {
(*_malloc_error)("mprobe", 1, mcheck_error(status));
}


$ ./xgcc -B. ~/ice.i
/home/ryan/ice.i:5:1: warning: initialization from incompatible pointer type
/home/ryan/ice.i: In function âmalloc_abortâ:
/home/ryan/ice.i:8:2: warning: passing argument 3 of â_malloc_errorâ makes
pointer from integer without a cast
/home/ryan/ice.i:8:2: note: expected âconst char * constâ but argument is of
type âintâ
/home/ryan/ice.i:9:1: error: non-trivial conversion at assignment
void (*) (const char * const, unsigned int, const char * const)
void (*) (const char *, unsigned int, const char *)
_malloc_error.0 = _malloc_error;

/home/ryan/ice.i:9:1: internal compiler error: verify_gimple failed
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

$ ./xgcc -B. -v
Reading specs from ./specs
Target: i686-pc-linux-gnu
Configured with: ../configure --enable-languages=c --disable-bootstrap
Thread model: posix
gcc version 4.5.0 20090610 (experimental) [trunk revision 148341] (GCC)


-- 
   Summary: ICE: verify_gimple failed
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rmansfield at qnx dot com
 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=40401

[Bug c/40394] Variable values calculated differently depending on storage class

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2009-06-10 14:02 ---
You are violating C aliasing rules.  Use -fno-strict-aliasing.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug middle-end/40401] [4.5 Regression] ICE: verify_gimple failed

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
Summary|ICE: verify_gimple failed   |[4.5 Regression] ICE:
   ||verify_gimple failed
   Target Milestone|--- |4.5.0


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

[Bug fortran/40402] New: Problem with data statement involving structure constructors

[philippe dot marguinaud at meteo dot fr]

The code:

  TYPE POINT
REAL :: X 
  ENDTYPE
  TYPE(POINT) :: P != POINT(1.+X)
  DATA P / POINT(1.+X) /
  END

[phi...@dune tmp]$ gfortran -c t.F 
t.F: In function ‘MAIN__’:
t.F:1: erreur interne du compilateur: dans gfc_conv_constant, à
fortran/trans-const.c:348
Veuillez soumettre un rapport complet d'anomalies,
avec le source pré-traité si nécessaire.
Consultez http://bugzilla.redhat.com/bugzilla> pour plus de détail.

It breaks both gfortran 4.1.2 and 4.5.0.


-- 
   Summary: Problem with data statement involving structure
constructors
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: philippe dot marguinaud at meteo dot fr
 GCC build triplet: x86_64-redhat-linux
  GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux


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

[Bug fortran/40402] Problem with data statement involving structure constructors containing non-initialisation expressions

[jv244 at cam dot ac dot uk]

--- Comment #1 from jv244 at cam dot ac dot uk  2009-06-10 14:10 ---
this is not valid code, but a gfortran bug nevertheless.

line 5: X is not permitted in an initialisation expression


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-invalid-code
  Known to fail||4.3.1 4.4.1 4.5.0
   Last reconfirmed|-00-00 00:00:00 |2009-06-10 14:10:09
   date||
Summary|Problem with data statement |Problem with data statement
   |involving structure |involving structure
   |constructors|constructors containing non-
   ||initialisation expressions


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

[Bug middle-end/40388] [4.5 Regression] another null pointer in remove_unreachable_regions

[reichelt at gcc dot gnu dot org]

--- Comment #4 from reichelt at gcc dot gnu dot org  2009-06-10 14:43 
---
Confirmed. Reduced testcase (already crashes with "-O"):

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

struct B
{
  A* p;

  ~B()
  {
if (p)
  delete p;
delete p;
  }
};

struct C
{
  B* q;

  ~C()
  {
try
{
  delete q;
}
catch (...)
{
}
  }
};

void foo()
{
  C c1, c2;
}
==


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||reichelt at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-06-10 14:43:14
   date||


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

[Bug middle-end/40388] [4.5 Regression] another null pointer in remove_unreachable_regions

[reichelt at gcc dot gnu dot org]

--- Comment #5 from reichelt at gcc dot gnu dot org  2009-06-10 15:50 
---
Even shorter testcase:

==
void foo();

struct A
{
  ~A()
  {
try
{
  foo();
  foo();
}
catch (...)
{
}
  }
};

void bar()
{
  A a1, a2;
}
==


-- 


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

[Bug lto/40403] New: lto: misalignment after cgraph section

[rmansfield at qnx dot com]

$ cat t.i
__asm__ (
   " .globl\t_start_\n"
   "\t _start_:\n"
   "\tnop\n"
);
$ ./xgcc -B.   t.i -c
$ ./xgcc -B. -flto t.i -c
/tmp/ccPizQGw.s: Assembler messages:
/tmp/ccPizQGw.s:47: Error: instruction address is not a multiple of 4


.section.gnu.lto_.opts,"",@progbits
.align 2
.string "x\234cd``\340"
.string "b\026\006T"
.string ""
.string "\001\020"
.ascii  "\016"
.section.gnu.lto_.cgraph
#APP
 .globl _start_
 _start_:
nop

$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: powerpc-unknown-linux-gnu
Configured with: ../configure --target=powerpc-unknown-linux-gnu
--prefix=/home/ryan/cross/powerpc-unknown-linux-gnu/
--with-local-prefix=/home/ryan/cross/powerpc-unknown-linux-gnu/powerpc-unknown-linux-gnu/sys-root
--disable-multilib
--with-sysroot=/home/ryan/cross/powerpc-unknown-linux-gnu/powerpc-unknown-linux-gnu/sys-root
--enable-shared --with-gmp=/home/ryan/cross/powerpc-unknown-linux-gnu
--with-mpfr=/home/ryan/cross/powerpc-unknown-linux-gnu --enable-__cxa_atexit
--disable-nls --enable-symvers=gnu --enable-languages=c
--enable-target-optspace --enable-lto
Thread model: posix
gcc version 4.5.0 20090605 (experimental) (lto merged with rev 148228)


-- 
   Summary: lto: misalignment after cgraph section
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rmansfield at qnx dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: powerpc-unknown-linux-gnu


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

[Bug lto/40403] lto: misalignment after cgraph section

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-06-10 16:32 ---
This code is invalid  There is a duplicate of the same bug for -g3.


-- 


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

[Bug inline-asm/33932] miscalculation of asm labels with -g3

[pinskia at gcc dot gnu dot org]

--- Comment #23 from pinskia at gcc dot gnu dot org  2009-06-10 16:32 
---
*** Bug 40403 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rmansfield at qnx dot com


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

[Bug lto/40403] lto: misalignment after cgraph section

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-06-10 16:32 ---


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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug tree-optimization/28632] VRP should understand bitwise OR and AND

[aldot at gcc dot gnu dot org]

-- 

aldot at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |aldot at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-08-08 00:37:24 |2009-06-10 16:48:37
   date||


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

[Bug tree-optimization/40210] gcc byte swap builtins inadequately optimized

[hp at gcc dot gnu dot org]

--- Comment #8 from hp at gcc dot gnu dot org  2009-06-10 17:36 ---
(In reply to comment #7)
> I do think that bit operations in general
> could be handled a lot better, and that would help out a whole lot of code. 

If you add (compilable) test-cases with enhancement requests, carefully noting
target and gcc version where you observed the lack of optimization, this would
help a lot.

> Once that framework was in place optimizing the byteswap builtin would be
> trivial.

We already have a "framework".


-- 


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

[Bug c/40404] New: Comparison involving unsigned int:17 bitfield seems wrong

[foo at mailinator dot com]

#include 
struct S {
unsigned int ui17 : 17;
} s;
int main()
{
s.ui17 = 0x1;
printf("%x\n", (unsigned int)s.ui17);
if (s.ui17 >= 0xfffeu)
puts("FAIL");
return 0;
}

Maybe I don't understand GCC's rules for the promotion of bitfields, but it
seems to me that s.ui17 should evaluate to ((unsigned int)0x1), which is
less than 0xfffeu, so "FAIL" should not be printed. But "FAIL" is printed.
I can't explain why; it's almost as if GCC is truncating the rhs to 0x1fffe
before doing the comparison!

Changing s.ui17 from 17 bits to 15 bits makes the test pass (i.e., not print
"FAIL"). I believe in that case GCC promotes s.ui17 to "unsigned short"... but
that should undergo usual arithmetic conversion to "unsigned int" at which
point we ought to see the same FAIL behavior happening.

Reproduced with GCC 4.2.4 and 4.3.3.


-- 
   Summary: Comparison involving unsigned int:17 bitfield seems
wrong
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: foo at mailinator dot com


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

[Bug c/40404] Comparison involving unsigned int:17 bitfield seems wrong

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-06-10 18:41 ---
unsigned int:17  gets promoted to int IIRC.


-- 


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

[Bug fortran/38718] some simplifiers for elemental intrinsics missing; required for init expressions

[fxcoudert at gcc dot gnu dot org]

--- Comment #3 from fxcoudert at gcc dot gnu dot org  2009-06-10 19:35 
---
(In reply to comment #2)
> Commit in #1 added a simplifier for MERGE. Having a closer look at
> IS_IOSTAT_{END, EOR}, I think they won't make much sense in init expr anyway.

IS_IOSTAT_{END,EOR} are allowed by the standard as initialization expressions.
They may not be high priority, but they're the only remaining ones from F2003
(the others are GNU extensions).

  DREAL  (GNU extension)
  ISNAN  (GNU extension)
  LSHIFT (GNU extension)
  RSHIFT (GNU extension)
  IS_IOSTAT_END  (F2003)
  IS_IOSTAT_EOR  (F2003)

Anyway, I'll get that assigned to myself.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |fxcoudert at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-03-29 08:42:17 |2009-06-10 19:35:16
   date||


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

[Bug c++/40389] optimizer bug (possibly)

[jason at gcc dot gnu dot org]

--- Comment #8 from jason at gcc dot gnu dot org  2009-06-10 19:37 ---
As Jakub says, it's not a problem to take the address of a local variable as
long as that address is only used during the variable's lifetime; the
destructor for the temporary removes all references to its address, so there's
nothing undefined.

The problem here seems to be that the address of the object escapes during its
own construction.  I guess we need a type flag to indicate this situation so we
can mark variables of such a type addressable when we create them.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-06-09 17:11:13 |2009-06-10 19:37:07
   date||


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

[Bug c++/40389] optimizer bug (possibly)

[jason at gcc dot gnu dot org]

--- Comment #9 from jason at gcc dot gnu dot org  2009-06-10 19:40 ---
Actually, I'm not sure I'm the right person to work on this bug, as we might
want this analysis to happen more in the optimizer.  That is, we see that
"this" escapes in one of the H constructors, so all H must be treated as
addressable.


-- 

jason at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c++/40389] optimizer bug (possibly)

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2009-06-10 19:47 
---
Can we have a less convoluted C-only testcase?  I still don't see what is
going on ...


-- 


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

[Bug c++/40405] New: [4.3/4.4/4.5 Regression] ICE with invalid initialization of template member

[reichelt at gcc dot gnu dot org]

The following invalid code snippet triggers an ICE sincd GCC 3.4.5
(with the exception of GCC 4.0.0 and 4.0.1):

=
template struct A
{
  static int i;
};

template int A<0,0>::i = 0;

int j = A<0,0>::i;
=

bug.cc:6:27: error: got 1 template parameters for 'int A<0, 0>::i'
bug.cc:6:27: error:   but 2 required
bug.cc:8:18: internal compiler error: in import_export_decl, at cp/decl2.c:2244
Please submit a full bug report, [etc.]


-- 
   Summary: [4.3/4.4/4.5 Regression] ICE with invalid initialization
of template member
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, error-recovery, monitored
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug c++/40405] [4.3/4.4/4.5 Regression] ICE with invalid initialization of template member

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.3.4


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

[Bug c++/40406] New: ICE with broken template member declaration

[reichelt at gcc dot gnu dot org]

The following invalid code snippet triggers an ICE since at least GCC 2.95.3:


template struct A
{
  template template void A::foo() {}
};


bug.cc:3:36: error: extra qualification 'A< >::' on member 'foo'
bug.cc:3:45: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]


-- 
   Summary: ICE with broken template member declaration
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code, error-recovery, monitored
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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

[Bug c++/40389] optimizer bug (possibly)

[jason at gcc dot gnu dot org]

--- Comment #11 from jason at gcc dot gnu dot org  2009-06-10 20:12 ---
I don't think it's possible to reproduce this in C because C doesn't have
constructors, so it's obvious when the address is taken.  Here's what's
happening:

baz uses new to allocate an A with f=0,l=0, call it A'
baz creates and returns a temporary H' with a=A',p=0,n=0
 bar modifies A', setting f and l to &H'.
(elided copy)
main calls operator= to copy H' to g.
 this sets a=A',p=0,n=0
  then bar sets g.p to &H', H'.n to &g and A'.l to &g.
main destroys H'.
 H'.p is 0, so we set A'.f to H'.n, or &g.
 H'.n is &g, so we set g.p to H'.p, or 0.


-- 


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

[Bug tree-optimization/40384] [4.5 regression] Revision 148277 failed gcc.dg/tree-ssa/prefetch-5.c

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2009-06-10 20:14 ---
(In reply to comment #2)
> The new cost model added in revision 148277 supresses prefetching in a loop
> when it is unlikely to be profitable. One such non-profitable case is a loop
> with an unknown trip count and a high prefeching cost. The prefetching cost is
> modeled by the ratio between the prefetch count and the total instruction 
> count
> in a loop. When this ratio is greater than 1/10 in a loop with an unknown trip
> count, prefetching is considered non-profitable and no prefetches are issued.
> The first two loops in this test case fall under this category, where the trip
> count is not known and the prefetch-to-insn ratio is 1/5. Possible fixes are:
> 
> 1. Add more computation to the loop bodies in the test case to reduce the
> prefetch-to-insn ratios and hence make the loops profitable from the cost
> model's point of view.
> 2. Use a commad line option to set the maximum profitable prefetch-to-insn
> ratio to 1/5. The syntax is --param min-insn-to-prefetch-ratio=5
> 3. Change the expected output such that it does not expect prefetches in this
> case.
> 

I prefer #2 since this is a prefetch test.


-- 

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=40384

[Bug c/40404] Comparison involving unsigned int:17 bitfield seems wrong

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-06-10 20:15 ---
This has been fixed in GCC 4.4, likely by removing some shorten-compare stuff
in the frontend.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
  Known to fail||4.3.3
  Known to work||4.4.0


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

[Bug c/40404] Comparison involving unsigned int:17 bitfield seems wrong

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-06-10 20:25 ---
Can someone identify the patch that fixed that on the trunk?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||wrong-code


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

[Bug c++/40407] New: Value increment problems

[ivranos at freemail dot gr]

The produced value is not the expected.


The code:

#include 
#include 

int main()
{
using namespace std;

long double x= numeric_limits::max();

cout<< fixed;

for(unsigned i= 0; i< 10; ++i)
{
cout<< x<< endl;
++x;
}

cout<< endl<< x<< endl<< numeric_limits::max()<< endl;
}


It produces:

j...@john-laptop:~/Projects/anjuta/cpp/src$ g++ -ansi -pedantic-errors -Wall
main.cc -o foobar 
j...@john-laptop:~/Projects/anjuta/cpp/src$ ./foobar 
18446744073709551615.00
18446744073709551616.00
18446744073709551616.00
18446744073709551616.00
18446744073709551616.00
18446744073709551616.00
18446744073709551616.00
18446744073709551616.00
18446744073709551616.00
18446744073709551616.00

18446744073709551616.00
18446744073709551615
j...@john-laptop:~/Projects/anjuta/cpp/src$


-- 
   Summary: Value increment problems
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ivranos at freemail dot gr
 GCC build triplet: Ubuntu Linux Desktop Edition 9.04 x64
  GCC host triplet: Ubuntu Linux Desktop Edition 9.04 x64
GCC target triplet: Ubuntu Linux Desktop Edition 9.04 x64 ("Target: x86_64-
linux-gnu


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

[Bug c++/40407] Value increment problems

[ivranos at freemail dot gr]

--- Comment #1 from ivranos at freemail dot gr  2009-06-10 20:30 ---
Created an attachment (id=17976)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17976&action=view)
The main.ii file produced with " g++ -ansi -pedantic-errors -Wall -save-temps
main.cc -o foobar"


-- 


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

[Bug c++/40407] Value increment problems

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-06-10 20:35 ---
This is called rounding.  I think you need to look at the hex values of the
long double to see what happens rather than printing out the value.


-- 


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

[Bug bootstrap/40408] New: [4.5 Regression] bootstrap boken again!

[dominiq at lps dot ens dot fr]

At revision 148352 bootstrapping is broken again on *-apple-darwin9 with:

...
/opt/gcc/i686-darwin/./prev-gcc/xgcc -B/opt/gcc/i686-darwin/./prev-gcc/
-B/opt/gcc/gcc4.5w/i686-apple-darwin9/bin/
-B/opt/gcc/gcc4.5w/i686-apple-darwin9/bin/
-B/opt/gcc/gcc4.5w/i686-apple-darwin9/lib/ -isystem
/opt/gcc/gcc4.5w/i686-apple-darwin9/include -isystem
/opt/gcc/gcc4.5w/i686-apple-darwin9/sys-include-c  -g -O2
-fomit-frame-pointer -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 -Werror -fno-common  -DHAVE_CONFIG_H -I. -I.
-I../../gcc-4.5-work/gcc -I../../gcc-4.5-work/gcc/.
-I../../gcc-4.5-work/gcc/../include -I./../intl
-I../../gcc-4.5-work/gcc/../libcpp/include -I/opt/mpc/build/include 
-I/sw/include  -I../../gcc-4.5-work/gcc/../libdecnumber
-I../../gcc-4.5-work/gcc/../libdecnumber/dpd -I../libdecnumber -I/sw/include 
-I/sw/include -DCLOOG_PPL_BACKEND   ../../gcc-4.5-work/gcc/graphite.c -o
graphite.o
In file included from /sw/include/cloog/cloog.h:45:0,
 from ../../gcc-4.5-work/gcc/graphite.c:66:
/sw/include/cloog/ppl_backend.h:178:6: warning: using 'polyhedron' as both a
typedef and a tag is invalid in C++
/sw/include/cloog/ppl_backend.h:173:18: note: originally defined here
/sw/include/cloog/ppl_backend.h:194:6: warning: using 'polyhedra_union' as both
a typedef and a tag is invalid in C++
/sw/include/cloog/ppl_backend.h:190:18: note: originally defined here
../../gcc-4.5-work/gcc/graphite.c: In function
'loop_iv_stack_patch_for_consts':
../../gcc-4.5-work/gcc/graphite.c:507:25: warning: enum constant defined in
struct or union is not visible in C++
/sw/include/cloog/clast.h:9:12: note: enum constant defined here
cc1: warnings being treated as errors
../../gcc-4.5-work/gcc/graphite.c: In function 'add_conditions_to_domain':
../../gcc-4.5-work/gcc/graphite.c:3227:9: error: case value '138' not in
enumerated type 'enum gimple_code'
../../gcc-4.5-work/gcc/graphite.c: In function 'clast_to_gcc_expression':
../../gcc-4.5-work/gcc/graphite.c:3851:10: warning: enum constant defined in
struct or union is not visible in C++
/sw/include/cloog/clast.h:9:12: note: enum constant defined here
../../gcc-4.5-work/gcc/graphite.c:3881:10: warning: enum constant defined in
struct or union is not visible in C++
/sw/include/cloog/clast.h:9:33: note: enum constant defined here
../../gcc-4.5-work/gcc/graphite.c:3902:10: warning: enum constant defined in
struct or union is not visible in C++
/sw/include/cloog/clast.h:9:23: note: enum constant defined here
../../gcc-4.5-work/gcc/graphite.c: In function 'gcc_type_for_clast_expr':
../../gcc-4.5-work/gcc/graphite.c:3944:10: warning: enum constant defined in
struct or union is not visible in C++
/sw/include/cloog/clast.h:9:12: note: enum constant defined here
../../gcc-4.5-work/gcc/graphite.c:3954:10: warning: enum constant defined in
struct or union is not visible in C++
/sw/include/cloog/clast.h:9:33: note: enum constant defined here
../../gcc-4.5-work/gcc/graphite.c:3973:10: warning: enum constant defined in
struct or union is not visible in C++
/sw/include/cloog/clast.h:9:23: note: enum constant defined here
../../gcc-4.5-work/gcc/graphite.c: In function 'find_cloog_iv_in_expr':
../../gcc-4.5-work/gcc/graphite.c:5335:21: warning: enum constant defined in
struct or union is not visible in C++
/sw/include/cloog/clast.h:9:12: note: enum constant defined here
../../gcc-4.5-work/gcc/graphite.c:5339:21: warning: enum constant defined in
struct or union is not visible in C++
/sw/include/cloog/clast.h:9:12: note: enum constant defined here
../../gcc-4.5-work/gcc/graphite.c:5342:21: warning: enum constant defined in
struct or union is not visible in C++
/sw/include/cloog/clast.h:9:33: note: enum constant defined here


-- 
   Summary: [4.5 Regression] bootstrap boken again!
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
 GCC build triplet: *-apple-darwin9
  GCC host triplet: *-apple-darwin9
GCC target triplet: *-apple-darwin9


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

[Bug bootstrap/40408] [4.5 Regression] bootstrap boken again!

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-06-10 20:45 ---
case SWITCH_EXPR:

Should be changed to:
case GIMPLE_SWITCH:

that will fix at least one warning/error.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ian at gcc dot gnu dot org
   Keywords||build
   Target Milestone|--- |4.5.0


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

[Bug c++/40389] optimizer bug (possibly)

[jason at gcc dot gnu dot org]

--- Comment #12 from jason at gcc dot gnu dot org  2009-06-10 20:58 ---
Incidentally, the testcase can be simplified by removing the body of the copy
constructor, i.e. reducing it to just the declaration

  H (const H &h);

since it isn't actually called.


-- 


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

[Bug c++/40389] optimizer bug (possibly)

[rguenth at gcc dot gnu dot org]

--- Comment #13 from rguenth at gcc dot gnu dot org  2009-06-10 20:58 
---
Well.  I see as final difference (no SRA vs. with SRA)

 :
   D.2249 = baz (); [return slot optimization]
-  D.2417_8 = D.2249.a;
-  g.a = D.2417_8;
-  D.2415_10 = &D.2417_8->k;
+  SR.101_9 = D.2249.a;
+  SR.102_31 = D.2249.p;
+  SR.103_32 = D.2249.n;
+  g.a = SR.101_9;
+  D.2415_10 = &SR.101_9->k;
   S::bar (D.2415_10, &g);
-  if (D.2417_8 != 0B)
+  if (SR.101_9 != 0B)
 goto ;
   else
 goto ;

 :
-  D.2421_13 = D.2249.p;
-  if (D.2421_13 != 0B)
+  if (SR.102_31 != 0B)
 goto ;
   else
 goto ;

 :
-  D.2422_15 = D.2249.n;
-  D.2421_13->n = D.2422_15;
+  SR.102_31->n = SR.103_32;
   goto ;

etc.

So you say that

   D.2249 = baz (); [return slot optimization]
-  D.2417_8 = D.2249.a;
-  g.a = D.2417_8;

makes D.2249.a escape and thus

   S::bar (D.2415_10, &g);

is allowed to modify D.2249.a because D.2249.a->... may point to D.2249
itself?

If

  D.2249 = baz (); [return slot optimization]

makes D.2249 escape then this is a bug in both points-to analysis and
addressability analysis (the C++ FE should then make sure to set
TREE_ADDRESSABLE on D.2249 as well if it doesn't do so already).


-- 


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

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

[jb at gcc dot gnu dot org]

--- Comment #24 from jb at gcc dot gnu dot org  2009-06-10 21:17 ---
Further reduced testcase:

program pr40330
 implicit none

 call s1()
 call s1()

contains
 subroutine s1()
   character(LEN=100) :: a
   a = "(3X)"
   write(*,FMT='('//trim(a)//",a,' ')", ADVANCE="NO") "3"
 end subroutine s1
end program pr40330

The interesting thing is, if you replace the trim(a) with trim("(3X)") then it
works. Look at -fdump-tree-original to see the difference; in the second case
the format string is a constant, in the first it's not and it's deallocated,
which might be related to why we get the valgrind errors about reading from
free'd storage.


-- 


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

[Bug lto/40409] New: [LTO] ICE in expand_shift, at expmed.c:2263

[rmansfield at qnx dot com]

$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: powerpc-unknown-linux-gnu
Configured with: ../configure --target=powerpc-unknown-linux-gnu
--prefix=/home/ryan/cross/powerpc-unknown-linux-gnu/
--with-local-prefix=/home/ryan/cross/powerpc-unknown-linux-gnu/powerpc-unknown-linux-gnu/sys-root
--disable-multilib
--with-sysroot=/home/ryan/cross/powerpc-unknown-linux-gnu/powerpc-unknown-linux-gnu/sys-root
--enable-shared --with-gmp=/home/ryan/cross/powerpc-unknown-linux-gnu
--with-mpfr=/home/ryan/cross/powerpc-unknown-linux-gnu --enable-__cxa_atexit
--disable-nls --enable-symvers=gnu --enable-languages=c
--enable-target-optspace --enable-lto
Thread model: posix
gcc version 4.5.0 20090605 (experimental) (lto merged with rev 148228)

./xgcc -B. -flto -shared acosh.o acosl.o
In file included from /home/ryan/svn/product/trunk/lib/m/inc/xxacos.h:27:0,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxacos.h:23,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxacos.h:23,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxacos.h:23,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxacos.h:23,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxacos.h:23,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxacos.h:23,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxacos.h:23,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxacos.h:24,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxacos.h:24,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxacos.h:23,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxacos.h:23,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxacos.h:22,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxacos.h:22,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxacos.h:22,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxacos.h:20,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxacos.h:20,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxacos.h:20,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxacos.h:20,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxacos.h:20,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxacos.h:21,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxacos.h:21,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxacos.h:20,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxacos.h:20,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxacos.h:19,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxacos.h:19,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxacos.h:19,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxacos.h:16,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxacos.h:16,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxacos.h:16,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxacos.h:15,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxacos.h:15,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxacos.h:15,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxacos.h:13,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxacos.h:12,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxacos.h:11,
 from /home/ryan/svn/product/trunk/lib/c/inc/xmath.h:188,
 from :16:
/home/ryan/svn/product/trunk/lib/m/inc/xxacos.h: In function 'acosl':
/home/ryan/svn/product/trunk/lib/m/inc/xxacos.h:28:4: internal compiler error:
in expand_shift, at expmed.c:2263
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: ././xgcc returned 1 exit status
collect2: lto-wrapper returned 1 exit status


-- 
   Summary: [LTO] ICE in expand_shift, at expmed.c:2263
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rmansfield at qnx dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: powerpc-unknown-linux-gnu


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

[Bug c++/40389] optimizer bug (possibly)

[jakub at gcc dot gnu dot org]

--- Comment #14 from jakub at gcc dot gnu dot org  2009-06-10 21:27 ---
The gimplifier sees:
TARGET_EXPR >>
>;
and:
arg 0 
addressable ignored BLK file pr40389.C line 67 col 12 size  unit size 
align 64 context >
and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40389

[Bug c++/40389] optimizer bug (possibly)

[jakub at gcc dot gnu dot org]

--- Comment #15 from jakub at gcc dot gnu dot org  2009-06-10 21:28 ---
Shorter testcase:
template  struct S
{
  V *f, *l;
  __attribute__ ((noinline)) S (void) { f = 0, l = 0; }
  void foo (V *x)
  {
if (x->p != 0)
  x->p->n = x->n;
else
  f = x->n;
if (x->n != 0)
  x->n->p = x->p;
else
  l = x->p;
  }
  __attribute__ ((noinline)) void bar (V *x)
  {
x->n = 0;
x->p = l;
if (l != 0)
  l->n = x;
else
  f = x;
l = x;
  }
};

struct H;

struct A
{
  S  k;
};

struct H
{
  A *a;
  H *p, *n;
  __attribute__ ((noinline)) H (void) { p = 0, n = 0, a = 0; }
  __attribute__ ((noinline)) H (A *b) : a (b)
  {
p = n = 0;
if (a != 0)
  a->k.bar (this);
  }
  ~H (void) { if (a != 0) a->k.foo (this); }
  H &operator= (const H &o)
  {
a = o.a;
if (a != 0)
  a->k.bar (this);
return *this;
  }
};

__attribute__ ((noinline))
H baz (void)
{
  return H (new A);
}

H g;

int
main (void)
{
  g = baz ();
  if (g.a->k.f != &g)
__builtin_abort ();
  return 0;
}


-- 


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

[Bug c++/40389] optimizer bug (possibly)

[rguenth at gcc dot gnu dot org]

--- Comment #16 from rguenth at gcc dot gnu dot org  2009-06-10 21:29 
---
In which case the following will fix it (provided the C++ FE sets the
TREE_ADDRESSABLE flag)

Index: gimple.c
===
--- gimple.c(revision 148325)
+++ gimple.c(working copy)
@@ -3264,6 +3264,9 @@ walk_stmt_load_store_addr_ops (gimple st
  && TREE_CODE (gimple_call_chain (stmt)) == ADDR_EXPR)
ret |= visit_addr (stmt, TREE_OPERAND (gimple_call_chain (stmt), 0),
   data);
+  if (visit_addr
+ && gimple_call_return_slot_opt_p (stmt))
+   ret |= visit_addr (stmt, gimple_call_lhs (stmt), data);
 }
   else if (gimple_code (stmt) == GIMPLE_ASM)
 {
Index: tree-ssa-operands.c
===
--- tree-ssa-operands.c (revision 148325)
+++ tree-ssa-operands.c (working copy)
@@ -1035,6 +1035,10 @@ parse_ssa_operands (gimple stmt)
  start = 1;
}

+  if (code == GIMPLE_CALL
+ && gimple_call_return_slot_opt_p (stmt))
+   mark_address_taken (gimple_call_lhs (stmt));
+
   for (i = start; i < gimple_num_ops (stmt); i++)
get_expr_operands (stmt, gimple_op_ptr (stmt, i), opf_use);



-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-06-10 19:37:07 |2009-06-10 21:29:08
   date||


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

[Bug middle-end/40401] [4.5 Regression] ICE: verify_gimple failed

[reichelt at gcc dot gnu dot org]

--- Comment #1 from reichelt at gcc dot gnu dot org  2009-06-10 21:35 
---
Confirmed. Even shorter testcase:


void (*fp)(const int i);
void (*fp)(int i);

void foo()
{
  (*fp)(0);
}


The regression appeared between 2009-04-24 and 2009-05-04.


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||reichelt at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code, monitored
   Last reconfirmed|-00-00 00:00:00 |2009-06-10 21:35:35
   date||


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

[Bug lto/40409] [LTO] ICE in expand_shift, at expmed.c:2263

[rmansfield at gmail dot com]

--- Comment #1 from rmansfield at gmail dot com  2009-06-10 21:53 ---
Created an attachment (id=17977)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17977&action=view)
testcase


-- 


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

[Bug lto/40410] New: [LTO] ICE verify_stmts failed

[rmansfield at qnx dot com]

$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: powerpc-unknown-linux-gnu
Configured with: ../configure --target=powerpc-unknown-linux-gnu
--prefix=/home/ryan/cross/powerpc-unknown-linux-gnu/
--with-local-prefix=/home/ryan/cross/powerpc-unknown-linux-gnu/powerpc-unknown-linux-gnu/sys-root
--disable-multilib
--with-sysroot=/home/ryan/cross/powerpc-unknown-linux-gnu/powerpc-unknown-linux-gnu/sys-root
--enable-shared --with-gmp=/home/ryan/cross/powerpc-unknown-linux-gnu
--with-mpfr=/home/ryan/cross/powerpc-unknown-linux-gnu --enable-__cxa_atexit
--disable-nls --enable-symvers=gnu --enable-languages=c
--enable-target-optspace --enable-lto
Thread model: posix
gcc version 4.5.0 20090605 (experimental) (lto merged with rev 148228)



$ ./xgcc -B. -flto -shared ctanf.o ctanhl.o ctanh.o
In function 'ctanh':
lto1: error: invalid conversion in gimple call
const long double



tv_34 = tan (im.7_33);

lto1: error: invalid conversion in gimple call
const long double



sv_36 = _Sinh (re.3_35, 1.0e+0);

lto1: error: type mismatch in binary expression


const long double

const long double

D.2436_37 = tv_34 * tv_34;

lto1: error: type mismatch in binary expression
const long double



const long double

bv_39 = D.2437_38 * sv_36;

lto1: error: type mismatch in binary expression


const long double

const long double

D.2438_40 = bv_39 * sv_36;

lto1: error: type mismatch in binary expression
const long double





dv_41 = D.2438_40 + 1.0e+0;

lto1: error: type mismatch in comparison expression


const long double
if (D.2439_42 == dv_41)

lto1: error: type mismatch in binary expression


const long double



D.2447_46 = tv_34 * 0.0;

lto1: error: type mismatch in binary expression


const long double

const long double

D.2448_48 = sv_36 * sv_36;

lto1: error: type mismatch in binary expression




const long double

D.2451_51 = D.2450_50 * bv_39;

lto1: error: type mismatch in binary expression




const long double

D.2452_52 = D.2451_51 / dv_41;

lto1: error: type mismatch in binary expression


const long double

const long double

D.2453_53 = tv_34 / dv_41;

lto1: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: ././xgcc returned 1 exit status
collect2: lto-wrapper returned 1 exit status


-- 
   Summary: [LTO] ICE verify_stmts failed
   Product: gcc
   Version: lto
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rmansfield at qnx dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: powerpc-unknown-linux-gnu


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

[Bug lto/40410] [LTO] ICE verify_stmts failed

[rmansfield at qnx dot com]

--- Comment #1 from rmansfield at qnx dot com  2009-06-10 22:08 ---
Created an attachment (id=17978)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17978&action=view)
testcase


-- 


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

[Bug c/40411] New: -std=c99 does not enable c99 mode in Solaris C library

[heydowns at borg dot com]

On Solaris, the C library does not operate in c99 compliant mode by default. 
If c99 compliant operation is desired, the object file
/usr/lib/{32,64}/values-xpg6.o needs to be linked.  The details are in the
Solaris standards(5) manpage.

When linking using "gcc -std=c99", gcc does not instruct the linker to include
this object file.


-- 
   Summary: -std=c99 does not enable c99 mode in Solaris C library
   Product: gcc
   Version: 3.4.6
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: heydowns at borg dot com
 GCC build triplet: sparc-sun-solaris2.10
  GCC host triplet: sparc-sun-solaris2.10
GCC target triplet: sparc-sun-solaris2.10


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

[Bug bootstrap/40408] [4.5 Regression] bootstrap boken again!

[ian at gcc dot gnu dot org]

--- Comment #2 from ian at gcc dot gnu dot org  2009-06-10 22:46 ---
Subject: Bug 40408

Author: ian
Date: Wed Jun 10 22:46:38 2009
New Revision: 148356

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148356
Log:
PR bootstrap/40408
* graphite.c (add_conditions_to_domain): Change SWITCH_EXPR to
GIMPLE_SWITCH.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite.c


-- 


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

[Bug bootstrap/40408] [4.5 Regression] bootstrap boken again!

[ian at airs dot com]

--- Comment #3 from ian at airs dot com  2009-06-10 22:48 ---
Fixed.  Thanks for the bug report.


-- 

ian at airs dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/40289] [4.5 Regression] share/libstdc++/python/ pollutes common namespace

[tromey at gcc dot gnu dot org]

--- Comment #3 from tromey at gcc dot gnu dot org  2009-06-10 22:58 ---
Subject: Bug 40289

Author: tromey
Date: Wed Jun 10 22:58:22 2009
New Revision: 148357

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148357
Log:
PR libstdc++/40289:
* python/Makefile.in: Rebuild.
* python/hook.in: Compute module path relative to objfile.
* python/Makefile.am (pythondir): Redefine.
(gdb.py): Subst toolexeclibdir.
(install-data-local): Rewrite.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/python/Makefile.am
trunk/libstdc++-v3/python/Makefile.in
trunk/libstdc++-v3/python/hook.in


-- 


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

[Bug libstdc++/40289] [4.5 Regression] share/libstdc++/python/ pollutes common namespace

[tromey at gcc dot gnu dot org]

--- Comment #4 from tromey at gcc dot gnu dot org  2009-06-10 23:06 ---
I changed this to install the code in a versioned directory.
I think this fixes the problem; reopen this PR if not.


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

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

[mikpe at it dot uu dot se]

--- Comment #13 from mikpe at it dot uu dot se  2009-06-11 00:01 ---
(In reply to comment #11)
> Fixed.

Not quite. I'm trying to build gcc-4.4-20090609 on powerpc64-unknown-linux-gnu,
with binutils 2.17.50.0.6-6, configured with --enable-languages=c,ada
--with-cpu=default32 --disable-shared, and the first attempt to link gnat1
fails with R_PPC_REL24 errors similar to those shown earlier in this PR entry.

A look in the build log shows that the host C compiler is invoked with -O1
while building the C parts of stage1, but the host gnat is invoked with no
optimisation flags at all. It seems that the workaround to pass -O1 when
--relax is missing isn't propagated into the Ada parts.

If I set CC='gcc -O2' during the initial configure step the build succeeds.


-- 


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

[Bug rtl-optimization/25972] pack and unpack of long doubles via union generates poor code

[bje at gcc dot gnu dot org]

--- Comment #4 from bje at gcc dot gnu dot org  2009-06-11 01:07 ---
Subject: Bug 25972

Author: bje
Date: Thu Jun 11 01:06:53 2009
New Revision: 148363

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148363
Log:
2009-06-11  Alan Modra  

PR target/25972
* config/rs6000/darwin-ldouble.c (longDblUnion): Delete.
(pack): New inline function.  Use throughout in place of packing a
pair of doubles to long double via union.

Modified:
branches/ibm/gcc-4_3-branch/gcc/ChangeLog.ibm
branches/ibm/gcc-4_3-branch/gcc/config/rs6000/darwin-ldouble.c


-- 


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

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

[jvdelisle at gcc dot gnu dot org]

--- Comment #25 from jvdelisle at gcc dot gnu dot org  2009-06-11 01:29 
---
Changing priority to normal.

I have a patch that fixes the reduced test case.  Testing CP2K now.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|critical|normal


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

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

[jvdelisle at gcc dot gnu dot org]

--- Comment #26 from jvdelisle at gcc dot gnu dot org  2009-06-11 02:25 
---
CP2K still fails.  However, I think I have discovered the root cause.  String
constants in formats are saved in the fnode at sting.p which is a pointer. 
When we use cached parsed string data, those constant strings are net getting
copied and saved along with the parsed format.

That "constant" string is used by write_constant_string in transfer.c.  This is
an issue with the concept because the constant string can vary with each
invocation of the IO statement, as is the case with CP2k, and it is freed at
the end of each IO operation.  The benefit of caching is lost if we have to
reparse to find the strings

This leaves the possibility of disabling the caching if a FMT_STRING token is
found while parsing the format the first time. I am going to suggest we revert
format caching from 4.4 right away and probably 4.5 if some better idea does
not pop into my head.


-- 


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

[Bug lto/40409] [LTO] ICE in expand_shift, at expmed.c:2263

[rmansfield at qnx dot com]

--- Comment #2 from rmansfield at qnx dot com  2009-06-11 02:58 ---
I reproduced this on a i686-pc-linux-gnu target:

$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: i686-pc-linux-gnu
Configured with: ../configure --enable-languages=c --enable-lto
--disable-bootstrap
Thread model: posix
gcc version 4.5.0 20090605 (experimental) (lto merged with rev 148228)
r...@ryan:~/gcc/lto/x86-build/gcc$ ./xgcc -B. -shared -flto casinhl.o
In file included from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:117:0,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:117,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:115,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:115,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:114,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:114,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:112,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:111,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:108,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:108,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:108,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:103,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:103,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:103,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:102,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:100,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:100,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:98,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:98,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:98,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:95,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:95,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:93,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:93,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:93,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:90,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:90,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:87,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:86,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:85,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:84,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:81,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:80,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:80,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:78,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:78,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:78,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:78,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:78,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:78,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:77,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:77,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:77,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:77,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:77,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:73,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:73,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:73,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:72,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:70,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:68,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:68,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:68,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:68,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:68,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:68,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:68,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:67,
 from /home/ryan/svn/product/trunk/lib/m/inc/xxcasinh.h:63,
 from /home/ryan/svn/product

[Bug lto/40409] [LTO] ICE in expand_shift, at expmed.c:2263

[rmansfield at qnx dot com]

--- Comment #3 from rmansfield at qnx dot com  2009-06-11 03:01 ---
Created an attachment (id=17979)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17979&action=view)
x86 testcase


-- 


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

[Bug fortran/40402] Problem with data statement involving structure constructors containing non-initialisation expressions

[pault at gcc dot gnu dot org]

--- Comment #2 from pault at gcc dot gnu dot org  2009-06-11 05:27 ---
Created an attachment (id=17980)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17980&action=view)
Fix for the problem

This regtests and bootstraps on trunk.

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug fortran/40402] Problem with data statement involving structure constructors containing non-initialisation expressions

[pault at gcc dot gnu dot org]

--- Comment #3 from pault at gcc dot gnu dot org  2009-06-11 06:21 ---
(In reply to comment #2)
I forgot to add that this demonstrates a proper fix.  At the moment, it
generates an extra, spurious error.  I'll see if I cannot do a proper job
tonight.

Je vous remercie pour le rapport.  Je trouve incroyable qu'il reste encore des
petits coins, meme en F77, ou se trouvent tels erreurs :-(

Paul


-- 


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