date:20100102

[Bug tree-optimization/42586] New: load-modify-store on x86 should be \ single instruction

2010-01-02 Thread pinskia at gcc dot gnu dot org



--- Comment #16 from pinskia at gcc dot gnu dot org  2010-01-03 07:49 
---
(In reply to comment #15)
> As an addendum the unnecessary stack frame seems to be a very common problem,
> it's in a lot of the examples near the end of 
> http://embed.cs.utah.edu/embarrassing/dec_09/harvest/gcc-head_suncc-5.10/
> typically combined with tail call optimization

Well the unnecessary stack frame is due to frame pointer is not omitted by
default with GCC due to debugging/backtrace reasons.  Try -fomit-frame-pointer
:).


-- 


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

[Bug tree-optimization/42586] New: load-modify-store on x86 should be \ single instruction

2010-01-02 Thread andi-gcc at firstfloor dot org



--- Comment #15 from andi-gcc at firstfloor dot org  2010-01-03 07:47 
---
As an addendum the unnecessary stack frame seems to be a very common problem,
it's in a lot of the examples near the end of 
http://embed.cs.utah.edu/embarrassing/dec_09/harvest/gcc-head_suncc-5.10/
typically combined with tail call optimization


-- 


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

[Bug tree-optimization/42591] missing constant evaluation for const union

2010-01-02 Thread pinskia at gcc dot gnu dot org



--- Comment #1 from pinskia at gcc dot gnu dot org  2010-01-03 07:22 ---
fold_const_aggregate_ref should handle it but maybe the CONSTRUCTOR does not
the field set. 


-- 


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

[no subject]

2010-01-02 Thread gcc-bugs-return-303931-archive=jab . org

typedef unsigned long long u64;
union ktime
{
  s64 tv64;
};
typedef union ktime ktime_t;
ktime_t ns_to_ktime (u64 ns);
union ktime const ktime_zero = { 0LL };

ktime_t
ns_to_ktime (u64 ns)
{
  ktime_t __constr_expr_0;

  {
__constr_expr_0.tv64 = (s64) ((u64) ktime_zero.tv64 + ns);
return (__constr_expr_0);
  }
}

/* Checksum = 1A82CF6 */

this generates with 4.5.0 20091219 -O2 

 movq%rdi, %rax
 addqktime_zero(%rip), %rax
 ret

llvm in this case uses the known const value of ktime_zero and just generates
an assignment (this makes more difference with -m32) gcc should too.


-- 
   Summary: missing constant evaluation for const union
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor dot org
  GCC host triplet: x86_64-linux
GCC target triplet: x86-64-linux


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

>From 
Received: (qmail 12960 invoked by uid 48); 3 Jan 2010 07:14:00 -
Date: 3 Jan 2010 07:14:00 -
Subject: [Bug tree-optimization/42591]  New: missing constant evaluation for 
const union
X-Bugzilla-Reason: CC
Message-ID: 
Reply-To: gcc-bugzi...@gcc.gnu.org
To: gcc-bugs@gcc.gnu.org
From: "andi-gcc at firstfloor dot org" 

typedef long long s64;

[Bug tree-optimization/42586] New: load-modify-store on x86 should be \ single instruction

2010-01-02 Thread pinskia at gcc dot gnu dot org



--- Comment #14 from pinskia at gcc dot gnu dot org  2010-01-03 07:10 
---
If we manually do the SRA like SRA would do it in 4.4:
  unsigned char *a, *b, *c;
  a = sptr->curr;
  b = sptr->base;
  c = sptr->last_plus_one;
  a +=4294967295U;
  sptr->curr = a;
  sptr->base = b;
  sptr->last_plus_one = c;

We get the behavior you want.  This is why I said this is all interrelated. 
PRE is able to remove the stores at the tree level on the trunk which then it
looks like what I showed in comment #3.  Again this is all the same issue
really.  And there is no need to file more bugs about the same issue.


-- 


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

[Bug tree-optimization/42586] New: load-modify-store on x86 should be \ single instruction

2010-01-02 Thread pinskia at gcc dot gnu dot org



--- Comment #13 from pinskia at gcc dot gnu dot org  2010-01-03 07:09 
---
(In reply to comment #12)
> Well the other issue is that only post-reload-cse deletes the load/stores
> without SRA doing what needs to be done.  

This was PR 38513 which we still should be done at the RTL level before the
register allocation :).  In fact PR 38513 was fixed at the tree level  for 4.5
which causes the read-modify-store will work after SRA is fixed.


-- 


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

[Bug tree-optimization/42586] New: load-modify-store on x86 should be \ single instruction

2010-01-02 Thread pinskia at gcc dot gnu dot org



--- Comment #12 from pinskia at gcc dot gnu dot org  2010-01-03 07:07 
---
(In reply to comment #11)
> My naive assumption was that the read-modify-write pattern is handled late by
> the RTL backend when generating instructions while SRA is somewhere early in
> the tree oriented middle end.

Well the other issue is that only post-reload-cse deletes the load/stores
without SRA doing what needs to be done.  And since the deletion happens so
late, combine does not combine the three instruction which does the
read-modify-write.  :).


-- 


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

[Bug tree-optimization/42586] New: load-modify-store on x86 should be \ single instruction

2010-01-02 Thread andi-gcc at firstfloor dot org



--- Comment #11 from andi-gcc at firstfloor dot org  2010-01-03 07:03 
---
My naive assumption was that the read-modify-write pattern is handled late by
the RTL backend when generating instructions while SRA is somewhere early in
the tree oriented middle end.


-- 


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

[Bug tree-optimization/42586] New: load-modify-store on x86 should be \ single instruction

2010-01-02 Thread pinskia at gcc dot gnu dot org



--- Comment #10 from pinskia at gcc dot gnu dot org  2010-01-03 07:02 
---
(In reply to comment #9)
> SRA issue handled in #42590

And that is the same as the -Os issue really ...


-- 


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

[Bug tree-optimization/42586] New: load-modify-store on x86 should be \ single instruction

2010-01-02 Thread andi-gcc at firstfloor dot org



--- Comment #9 from andi-gcc at firstfloor dot org  2010-01-03 07:00 ---
SRA issue handled in #42590


-- 


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

[Bug middle-end/42590] New: unnecessary stack frame set up

2010-01-02 Thread andi-gcc at firstfloor dot org

Continuation from 42586 and 42585 who handle other missed optimizations
for this test case.

>From one of the examples of
http://embed.cs.utah.edu/embarrassing/dec_09/harvest/gcc-head_llvm-gcc-head/

struct _fat_ptr
{
  unsigned char *curr;
  unsigned char *base;
  unsigned char *last_plus_one;
};
int Cyc_string_ungetc (int ignore, struct _fat_ptr *sptr);
int
Cyc_string_ungetc (int ignore, struct _fat_ptr *sptr)
{
  struct _fat_ptr *_T0;
  struct _fat_ptr *_T1;
  struct _fat_ptr _T2;
  int _T3;
  struct _fat_ptr _ans;
  int _change;

  {
_T0 = sptr;
_T1 = sptr;
_T2 = *sptr;
_T3 = -1;
_ans = _T2;
_change = -1;
_ans.curr += 4294967295U;
*sptr = _ans;
return (0);
  }
}

generates 

hen compiled with -O2 -m32 on 4.5.0 20091219 generates

Cyc_string_ungetc:
subl$32, %esp
movl40(%esp), %eax
movl(%eax), %edx
subl$1, %edx
movl%edx, (%eax)
xorl%eax, %eax
addl$32, %esp
ret


The stack frame manipulation is completely unnecessary.

A.Pinski commented on the other bug on this:

ell one thing is SRA does not do its job which is why there is useless stack
frame changes.

--- Comment #2 From Andrew Pinski 2010-01-03 06:27 [reply] ---
Oh and -Os is very bad looking :).

--- Comment #3 From Andrew Pinski 2010-01-03 06:30 [reply] ---
Oh in fact I think the reason is the SRA issue.  In that:
int
Cyc_string_ungetc (int ignore, struct _fat_ptr *sptr)
{
  sptr->curr += 4294967295U;
}
Works.

--- Comment #4 From Andrew Pinski 2010-01-03 06:33 [reply] ---
Hmm, 4.5 is worse off than 4.4 with respect of the stack space usage.

--- Comment #5 From Andrew Pinski 2010-01-03 06:35 [reply] ---
4.5 has:
  _T2 = *sptr_1(D);
  _T2$curr_14 = sptr_1(D)->curr;
  _ans = _T2;
  D.2697_7 = _T2$curr_14 + -1;
  *sptr_1(D) = _ans;
  sptr_1(D)->curr = D.2697_7;

While 4.4 does:
  _T2$base = sptr->base;
  D.1587 = sptr->curr + -1;
  sptr->last_plus_one = sptr->last_plus_one;
  sptr->base = _T2$base;
  sptr->curr = D.1587;

--- Comment #6 From Andrew Pinski 2010-01-03 06:38 [reply] ---
I think if we get the old SRA behavior back for this code, we will get this
optimization in 4.5 since we remove the sptr->base and the other unnecessary
store during PRE.


-- 
   Summary: unnecessary stack frame set up
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor dot org
  GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux


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

[Bug tree-optimization/42586] New: load-modify-store on x86 should be \ single instruction

2010-01-02 Thread pinskia at gcc dot gnu dot org



--- Comment #8 from pinskia at gcc dot gnu dot org  2010-01-03 06:57 ---
(In reply to comment #7)
> I reverted the summary to the original one.

Well it is all interrelated :).  Which is what my point was about that.  Did
you notice comment #3 which shows that load-modify-store actually does happen
in some cases.


-- 


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

[Bug tree-optimization/42586] New: load-modify-store on x86 should be \ single instruction

2010-01-02 Thread andi-gcc at firstfloor dot org



--- Comment #7 from andi-gcc at firstfloor dot org  2010-01-03 06:55 ---
This bug was not about the unnecessary stack frame, but about unnecessary 
read-modify-write
(it seems you didn't read my description completely)

For stack frame probably another bug should be opened. I can do that.

I reverted the summary to the original one.


-- 

andi-gcc at firstfloor dot org changed:

   What|Removed |Added

Summary|SRA does not always work|New: load-modify-store on
   ||x86 should be \ single
   ||instruction


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

[Bug middle-end/42588] unnecessary move through x87 stack/local frame for union

2010-01-02 Thread pinskia at gcc dot gnu dot org



--- Comment #3 from pinskia at gcc dot gnu dot org  2010-01-03 06:51 ---
This is related to PR 33989.


-- 


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

[Bug middle-end/42588] unnecessary move through x87 stack/local frame for union

2010-01-02 Thread pinskia at gcc dot gnu dot org



--- Comment #2 from pinskia at gcc dot gnu dot org  2010-01-03 06:49 ---
Here is an example which shows the issue on PPC also:
union __anonunion___u_19
{
  double __d;
  int __i[2];
};
 extern int __signbit (double *__x)
{
  union __anonunion___u_19 __u;
  {
__u.__d = *__x;
return (__u.__i[1] < 0);
  }
}


-- 


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

[Bug rtl-optimization/42589] New: bswap optimization does not work for 32bit (but for 64bit)

2010-01-02 Thread andi-gcc at firstfloor dot org

>From one of the test cases from 
http://embed.cs.utah.edu/embarrassing/dec_09/harvest/gcc-head_llvm-gcc-head/

typedef unsigned int size_t;
typedef unsigned char apr_byte_t;
typedef unsigned long long apr_uint64_t;
struct _SHA512_CTX
{
  apr_uint64_t state[8];
  apr_uint64_t bitcount[2];
  apr_byte_t buffer[128];
};
typedef struct _SHA512_CTX SHA512_CTX;
typedef apr_byte_t sha2_byte;
typedef apr_uint64_t sha2_word64;
/* compiler builtin: 
   unsigned int __builtin_object_size(void * , int  ) ;  */
/* compiler builtin: 
   void *__builtin___memset_chk(void * , int  , unsigned int  , unsigned int  )
;  */
extern __attribute__ ((__nothrow__, __noreturn__))
 void __assert_fail (char const *__assertion,
 char const *__file,
 unsigned int __line, char const *__function);
 void apr__SHA512_Final (apr_byte_t * digest, SHA512_CTX * context);
 void apr__SHA512_Last (SHA512_CTX * context);
 void apr__SHA512_Last (SHA512_CTX * context);
 void apr__SHA512_Final (apr_byte_t * digest, SHA512_CTX * context)
{
  sha2_word64 *d;
  int j;
  sha2_word64 tmp;
  sha2_word64 *tmp___0;
  void __attribute__ ((__artificial__)) * _cil_inline_tmp_228;
  void *_cil_inline_tmp_229;
  int _cil_inline_tmp_230;
  size_t _cil_inline_tmp_231;
  unsigned int _cil_inline_tmp_232;
  void *_cil_inline_tmp_233;

  {
d = (sha2_word64 *) digest;
if (!((unsigned int) context != (unsigned int) ((SHA512_CTX *) 0)))
  {
__assert_fail ("context != (SHA512_CTX*)0", "random/unix/sha2.c",
   870U, "apr__SHA512_Final");
  }
if ((unsigned int) digest != (unsigned int) ((sha2_byte *) 0))
  {
apr__SHA512_Last (context);
j = 0;
while (j < 8)
  {
tmp = context->state[j];
tmp = (tmp >> 32) | (tmp << 32);
tmp =
  ((tmp & 0xff00ff00ff00ff00ULL) >> 8) |
  ((tmp & 71777214294589695ULL) << 8);
context->state[j] =
  ((tmp & 0xULL) >> 16) |
  ((tmp & 281470681808895ULL) << 16);
tmp___0 = d;
d++;
*tmp___0 = context->state[j];
j++;
  }
  }
_cil_inline_tmp_229 = (void *) context;
_cil_inline_tmp_230 = 0;
_cil_inline_tmp_231 = 4U;
_cil_inline_tmp_232 = __builtin_object_size ((void *) context, 0);
_cil_inline_tmp_233 =
  __builtin___memset_chk ((void *) context, 0, 4U, _cil_inline_tmp_232);
_cil_inline_tmp_228 =
  (void __attribute__ ((__artificial__)) *) _cil_inline_tmp_233;
return;
  }
}

/* Checksum = D12A74A3 */


The 64bit gcc generates reasonable code (on par with LLVM with
-fno-reoder-blocks in code size). That includes using bswap for the open coded
endian
conversions

But with -m32 the code is much larger, mostly because bswap is never generated.
I played around with various options including -march=core -mtune=core2 -O2
etc.
but no bswap to be seen.


-- 
   Summary: bswap optimization does not work for 32bit (but for
64bit)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor dot org
  GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux


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

[Bug middle-end/42588] unnecessary move through x87 stack/local frame for union

2010-01-02 Thread pinskia at gcc dot gnu dot org



--- Comment #1 from pinskia at gcc dot gnu dot org  2010-01-03 06:46 ---
;; __u.__d = __x_1(D);

(insn 6 5 0 t.c:15 (set (subreg:DF (reg/v:DI 60 [ __u ]) 0)
(reg/v:DF 62 [ __x ])) -1 (nil))

That causes a reload to happen:
Reload 0: reload_out (DF) = (subreg:DF (reg/v:DI 60 [ __u ]) 0)
FLOAT_REGS, RELOAD_FOR_OUTPUT (opnum = 0)
reload_out_reg: (subreg:DF (reg/v:DI 60 [ __u ]) 0)
reload_reg_rtx: (reg:DF 8 st)

I think I might have another bug about this issue before ...


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||missed-optimization
   Last reconfirmed|-00-00 00:00:00 |2010-01-03 06:46:29
   date||


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

[Bug tree-optimization/42585] [4.5 Regression] SRA is not good for structure copies with one replacement any more

2010-01-02 Thread pinskia at gcc dot gnu dot org



--- Comment #1 from pinskia at gcc dot gnu dot org  2010-01-03 06:41 ---
I think fixing this will also fix the PR 42586 on the trunk.

Confirmed, a regression from 4.4.  SRA is worse off on the trunk for this case
than with 4.4.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu dot
   ||org
   Severity|enhancement |normal
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||missed-optimization
  Known to fail||4.5.0
  Known to work||4.4.0
   Last reconfirmed|-00-00 00:00:00 |2010-01-03 06:41:47
   date||
Summary|-Os not modifying memory|[4.5 Regression] SRA is not
   |object in place |good for structure copies
   ||with one replacement any
   ||more
   Target Milestone|--- |4.5.0
Version|unknown |4.5.0


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

[Bug tree-optimization/42586] SRA does not always work

2010-01-02 Thread pinskia at gcc dot gnu dot org



--- Comment #6 from pinskia at gcc dot gnu dot org  2010-01-03 06:38 ---
I think if we get the old SRA behavior back for this code, we will get this
optimization in 4.5 since we remove the sptr->base and the other unnecessary
store during PRE.


-- 


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

[Bug tree-optimization/42586] SRA does not always work

2010-01-02 Thread pinskia at gcc dot gnu dot org



--- Comment #5 from pinskia at gcc dot gnu dot org  2010-01-03 06:35 ---
4.5 has:
  _T2 = *sptr_1(D);
  _T2$curr_14 = sptr_1(D)->curr;
  _ans = _T2;
  D.2697_7 = _T2$curr_14 + -1;
  *sptr_1(D) = _ans;
  sptr_1(D)->curr = D.2697_7;

While 4.4 does:
  _T2$base = sptr->base;
  D.1587 = sptr->curr + -1;
  sptr->last_plus_one = sptr->last_plus_one;
  sptr->base = _T2$base;
  sptr->curr = D.1587;


-- 


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

[Bug tree-optimization/42586] SRA does not always work

2010-01-02 Thread pinskia at gcc dot gnu dot org



--- Comment #4 from pinskia at gcc dot gnu dot org  2010-01-03 06:33 ---
Hmm, 4.5 is worse off than 4.4 with respect of the stack space usage.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu dot
   ||org


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

[Bug tree-optimization/42586] SRA does not always work

2010-01-02 Thread pinskia at gcc dot gnu dot org



--- Comment #3 from pinskia at gcc dot gnu dot org  2010-01-03 06:30 ---
Oh in fact I think the reason is the SRA issue.  In that:
int
Cyc_string_ungetc (int ignore, struct _fat_ptr *sptr)
{
  sptr->curr += 4294967295U;
}
Works.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|rtl-optimization|tree-optimization
   Keywords||missed-optimization
Summary|load-modify-store on x86|SRA does not always work
   |should be single instruction|
Version|unknown |4.5.0


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

[Bug rtl-optimization/42586] load-modify-store on x86 should be single instruction

2010-01-02 Thread pinskia at gcc dot gnu dot org



--- Comment #2 from pinskia at gcc dot gnu dot org  2010-01-03 06:27 ---
Oh and -Os is very bad looking :).


-- 


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

[Bug rtl-optimization/42586] load-modify-store on x86 should be single instruction

2010-01-02 Thread pinskia at gcc dot gnu dot org



--- Comment #1 from pinskia at gcc dot gnu dot org  2010-01-03 06:27 ---
Well one thing is SRA does not do its job which is why there is useless stack
frame changes.


-- 


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

[Bug middle-end/42588] New: unnecessary move through x87 stack/local frame for union

2010-01-02 Thread andi-gcc at firstfloor dot org

from
http://embed.cs.utah.edu/embarrassing/dec_09/harvest/gcc-head_llvm-gcc-head/

union __anonunion___u_19
{
  double __d;
  int __i[2];
};
extern __attribute__ ((__nothrow__))
 int __signbit (double __x) __attribute__ ((__const__));
 extern __attribute__ ((__nothrow__))
 int __signbit (double __x) __attribute__ ((__const__));
 extern int __signbit (double __x)
{
  union __anonunion___u_19 __u;

  {
__u.__d = __x;
return (__u.__i[1] < 0);
  }
}

/* Checksum = AEFB9790 */

generates with -O2 -m32 -fomit-frame-pointer

 subl$12, %esp
fldl16(%esp)
fstpl   (%esp)
movl4(%esp), %eax
addl$12, %esp
shrl$31, %eax
ret

the move through the x87 stack and the local frame is totally unnecessary;
the shr could be just done on the input stack value

in comparison llvm generates the much neater:

   0:   0f b7 44 24 0c  movzwl 0xc(%esp),%eax
   5:   c1 e8 0fshr$0xf,%eax
   8:   c3  ret


-- 
   Summary: unnecessary move through x87 stack/local frame for union
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor dot org
  GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux -m32


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

[Bug tree-optimization/42587] New: bswap not recognized for union

2010-01-02 Thread andi-gcc at firstfloor dot org

From
http://embed.cs.utah.edu/embarrassing/dec_09/harvest/gcc-head_llvm-gcc-head/

typedef unsigned char u8;
typedef unsigned int u32;
#pragma pack(1)
#pragma pack()
#pragma pack(1)
#pragma pack()
#pragma pack(1)
#pragma pack()
#pragma pack(4)
#pragma pack()
union __anonunion_out_195
{
  u32 value;
  u8 bytes[4];
};
union __anonunion_in_196
{
  u32 value;
  u8 bytes[4];
};
extern void acpi_ut_track_stack_ptr (void);
u32 acpi_ut_dword_byte_swap (u32 value);
u32
acpi_ut_dword_byte_swap (u32 value)
{
  union __anonunion_out_195 out;
  union __anonunion_in_196 in;

  {
acpi_ut_track_stack_ptr ();
in.value = value;
out.bytes[0] = in.bytes[3];
out.bytes[1] = in.bytes[2];
out.bytes[2] = in.bytes[1];
out.bytes[3] = in.bytes[0];
return (out.value);
  }
}

/* Checksum = 1251E213 */


does not turn into bswap, while llvm does that.

There's bswap detection code in tree-ssa-math-ops.c, but it doesn't
seem to work for this union pattern. Perhaps it should?


-- 
   Summary: bswap not recognized for union
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor dot org
  GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux


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

[Bug rtl-optimization/42586] New: load-modify-store on x86 should be single instruction

2010-01-02 Thread andi-gcc at firstfloor dot org

Continuation from 42585

>From one of the examples of
http://embed.cs.utah.edu/embarrassing/dec_09/harvest/gcc-head_llvm-gcc-head/

struct _fat_ptr
{
  unsigned char *curr;
  unsigned char *base;
  unsigned char *last_plus_one;
};
int Cyc_string_ungetc (int ignore, struct _fat_ptr *sptr);
int
Cyc_string_ungetc (int ignore, struct _fat_ptr *sptr)
{
  struct _fat_ptr *_T0;
  struct _fat_ptr *_T1;
  struct _fat_ptr _T2;
  int _T3;
  struct _fat_ptr _ans;
  int _change;

  {
_T0 = sptr;
_T1 = sptr;
_T2 = *sptr;
_T3 = -1;
_ans = _T2;
_change = -1;
_ans.curr += 4294967295U;
*sptr = _ans;
return (0);
  }
}

when compiled with -O2 -m32 on 4.5.0 20091219 generates

Cyc_string_ungetc:
subl$32, %esp
movl40(%esp), %eax
movl(%eax), %edx
subl$1, %edx
movl%edx, (%eax)
xorl%eax, %eax
addl$32, %esp
ret

Apart from the useless stack frame manipulation it should use

   subl $1,(%eax) 

not load-modify-store as recommended in the Intel/AMD optimization
manuals for any modern CPU.

I experimented with different -mtune=s
(thinking it was maybe optimizing for Pentium5 where this made sense), but that
didn't help (apart from turning the subl into a decl). The code snippet
above is for -mtune=generic -m32


-- 
   Summary: load-modify-store on x86 should be single instruction
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor dot org
  GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux -m32


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

[Bug tree-optimization/42585] New: -Os not modifying memory object in place

2010-01-02 Thread andi-gcc at firstfloor dot org

>From one of the examples from
http://embed.cs.utah.edu/embarrassing/dec_09/harvest/gcc-head_llvm-gcc-head/

struct _fat_ptr
{
  unsigned char *curr;
  unsigned char *base;
  unsigned char *last_plus_one;
};
int Cyc_string_ungetc (int ignore, struct _fat_ptr *sptr);
int
Cyc_string_ungetc (int ignore, struct _fat_ptr *sptr)
{
  struct _fat_ptr *_T0;
  struct _fat_ptr *_T1;
  struct _fat_ptr _T2;
  int _T3;
  struct _fat_ptr _ans;
  int _change;

  {
_T0 = sptr;
_T1 = sptr;
_T2 = *sptr;
_T3 = -1;
_ans = _T2;
_change = -1;
_ans.curr += 4294967295U;
*sptr = _ans;
return (0);
  }
}

Testing on GCC: (GNU) 4.5.0 20091219

With -O2 this generates only midly inefficient code (although still a bit
larger
than llvm's very neat
   8b 44 24 08  mov0x8(%esp),%eax
   4:   ff 08   decl   (%eax)
   6:   31 c0   xor%eax,%eax
   8:   c3  ret
)

-O2 code:
subl$32, %esp
movl40(%esp), %eax
movl(%eax), %edx
subl$1, %edx
movl%edx, (%eax)
xorl%eax, %eax
addl$32, %esp
ret


That's a bit dumb because it allocates stack without using it and 
also does not use a subl $1,(eax), but explicit load-modify-store, but not
overly bad (I'll open a separate bug for the load/modify/store)

But with -Os the code is really bad:

pushl   %edi
movl$3, %ecx
pushl   %esi
subl$32, %esp
movl48(%esp), %eax
leal20(%esp), %edi
movl%eax, %esi
rep movsl
leal8(%esp), %edi
leal20(%esp), %esi
movl(%eax), %edx
movb$3, %cl
rep movsl
leal8(%esp), %esi
movl%eax, %edi
decl%edx
movb$3, %cl
rep movsl
movl%edx, (%eax)
addl$32, %esp
xorl%eax, %eax
popl%esi
popl%edi
ret


It doesn't modify the object in place, but instead copies it around.
Unsurprisingly that generates that much larger (and slower code)


-- 
   Summary: -Os not modifying memory object in place
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor dot org
  GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux -m32


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

[Bug bootstrap/42584] New: GCC 4.5 doesn't come close to bootstrapping on MinGW/MSYS

2010-01-02 Thread lxndrmxwll at gmail dot com

According to the GCC 4.5 Release Criteria at
http://gcc.gnu.org/gcc-4.5/criteria.html , MinGW is a secondary platform and
should be able to bootstrap successfully. Currently, GCC 4.5 does not even
build on MinGW/MSYS with --disable-bootstrap , which worked for me with 4.3.x.
(The full bootstrap hasn't worked for me since 4.1.x; at this point I would be
happy to get --disable-bootstrap builds working again.)

Here is my build process in precise detail.

Step 1. Extract to C:\Temp\gcc\msys (or any other location separate from the
working directories used here):

http://sourceforge.net/projects/mingw/files/ > MSYS Base System > msys-1.0.11 >
msysCORE-1.0.11-bin.tar.gz
http://sourceforge.net/projects/mingw/files/ > MSYS Bison > bison-2.4.1-1 >
bison-2.4.1-1-msys-1.0.11-bin.tar.lzma
http://sourceforge.net/projects/mingw/files/ > MSYS Flex > flex-2.5.35-1 >
flex-2.5.35-1-msys-1.0.11-bin.tar.lzma
http://sourceforge.net/projects/mingw/files/ > MSYS regex > regex-1.20090805-1
> libregex-1.20090805-1-msys-1.0.11-dll-1.tar.lzma

Step 2. Save decompressed .tar files to C:\Temp\gcc\sources (this is a staging
area separate from the working directories used here):

http://sourceforge.net/projects/mingw/files/ > MinGW Runtime > mingwrt-3.17 >
mingwrt-3.17-mingw32-dev.tar.gz
http://sourceforge.net/projects/mingw/files/ > MinGW API for MS-Windows >
w32api-3.14 > w32api-3.14-mingw32-dev.tar.gz
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20091231/gcc-core-4.5-20091231.tar.bz2
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20091231/gcc-g++-4.5-20091231.tar.bz2
ftp://ftp.gmplib.org/pub/gmp-4.3.1/gmp-4.3.1.tar.bz2
http://www.mpfr.org/mpfr-current/mpfr-2.4.2.tar.bz2
http://www.mpfr.org/mpfr-current/patches (renamed to mpfr-2.4.2.patch)
http://www.multiprecision.org/mpc/download/mpc-0.8.1.tar.gz

Step 3. In MSYS, run the following commands. This uses C:\Temp\gcc\src ,
C:\Temp\gcc\build , and C:\Temp\gcc\dest as working directories.

cd /c/temp/gcc/sources
tar -C /c/temp/gcc -xf gcc-core-4.5-20091231.tar
tar -C /c/temp/gcc -xf gcc-g++-4.5-20091231.tar
tar -C /c/temp/gcc -xf gmp-4.3.1.tar
tar -C /c/temp/gcc -xf mpfr-2.4.2.tar
patch -Z -d /c/temp/gcc/mpfr-2.4.2 -p1 < mpfr-2.4.2.patch
tar -C /c/temp/gcc -xf mpc-0.8.1.tar
mkdir -p /include
rm -rf /mingw
mkdir /mingw
tar -C /mingw -xf mingwrt-3.17-mingw32-dev.tar
tar -C /mingw -xf w32api-3.14-mingw32-dev.tar
cd /c/temp/gcc
mv gcc-4.5-20091231 src
mv gmp-4.3.1 src/gmp
mv mpfr-2.4.2 src/mpfr
mv mpc-0.8.1 src/mpc
mkdir build dest
cd build

../src/configure --prefix=c:/temp/gcc/dest --enable-languages=c,c++
--enable-threads --disable-nls --disable-win32-registry
--disable-sjlj-exceptions --with-arch=i486 --with-tune=generic
--enable-cxx-flags='-fno-function-sections -fno-data-sections'
--disable-libstdcxx-pch --disable-shared --enable-checking=release
--disable-bootstrap --disable-symvers --enable-fully-dynamic-string

make

This fails with:

make[3]: Leaving directory `/c/temp/gcc/build/mpfr'
make[2]: Leaving directory `/c/temp/gcc/build/mpfr'
mkdir -p -- ./mpc
Configuring in ./mpc
configure: creating cache ./config.cache
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking build system type... i686-pc-mingw32
checking host system type... i686-pc-mingw32
checking for i686-pc-mingw32-gcc... gcc
checking for C compiler default output file name... a.exe
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... .exe
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for a sed that does not truncate output... /bin/sed
checking for DLL/static GMP... static
checking for a sed that does not truncate output... (cached) /bin/sed
checking for fgrep... /bin/grep -F
checking for ld used by gcc... ld
checking if the linker (ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... nm
checking the name lister (nm) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 8192
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking for ld option to reload object files... -r
checking for i686-pc-mingw32-objdump... objdump
checking how to recognize dependent libraries... file_magic ^x86 archive import
   |^x86 DLL
checking for i686-pc-mingw32-ar.

[Bug c++/42555] [4.5 Regression] 16-byte aligned double is disallowed only in templates

2010-01-02 Thread hjl dot tools at gmail dot com



--- Comment #5 from hjl dot tools at gmail dot com  2010-01-02 23:48 ---
(In reply to comment #4)
> I can't reproduce this with the current 4.5 sources.
> 

I still saw it with today's gcc 4.5. You need -O3 -msse2 on
Linux/x86 to see it.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-02 23:48:09
   date||


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

[Bug testsuite/42583] [4.5 Regression] FAIL: gfortran.dg/gomp/recursion1.f90: gfortran: libgomp.spec: No such file or directory

2010-01-02 Thread rguenth at gcc dot gnu dot org



--- Comment #5 from rguenth at gcc dot gnu dot org  2010-01-02 23:45 ---
Your duplicate bug is about sth completely different (even if later comments
talk about an unrelated thing to that bug).


-- 


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

[Bug testsuite/42583] [4.5 Regression] FAIL: gfortran.dg/gomp/recursion1.f90: gfortran: libgomp.spec: No such file or directory

2010-01-02 Thread kargl at gcc dot gnu dot org



--- Comment #4 from kargl at gcc dot gnu dot org  2010-01-02 23:23 ---
(In reply to comment #2)
> Huh?
> 
> The testcase is in the wrong directory, runtime tests have to be in the
> libgomp testsuite.
> 

See the last comment in the PR that I listed as a duplicate.


-- 


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

[Bug c++/42555] [4.5 Regression] 16-byte aligned double is disallowed only in templates

2010-01-02 Thread jason at gcc dot gnu dot org



--- Comment #4 from jason at gcc dot gnu dot org  2010-01-02 23:23 ---
I can't reproduce this with the current 4.5 sources.


-- 


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

[Bug testsuite/42583] [4.5 Regression] FAIL: gfortran.dg/gomp/recursion1.f90: gfortran: libgomp.spec: No such file or directory

2010-01-02 Thread rguenth at gcc dot gnu dot org



--- Comment #3 from rguenth at gcc dot gnu dot org  2010-01-02 23:14 ---
Is broken everywhere.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
  Component|driver  |testsuite
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-02 23:14:54
   date||
Summary|gfortran: libgomp.spec: No  |[4.5 Regression] FAIL:
   |such file or directory  |gfortran.dg/gomp/recursion1.
   ||f90: gfortran: libgomp.spec:
   ||No such file or directory
   Target Milestone|--- |4.5.0


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

[Bug driver/42583] gfortran: libgomp.spec: No such file or directory

2010-01-02 Thread rguenth at gcc dot gnu dot org



--- Comment #2 from rguenth at gcc dot gnu dot org  2010-01-02 23:10 ---
Huh?

The testcase is in the wrong directory, runtime tests have to be in the
libgomp testsuite.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|DUPLICATE   |


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

[Bug target/42564] unrecognizable insn with -O -fPIC

2010-01-02 Thread ebotcazou at gcc dot gnu dot org



--- Comment #8 from ebotcazou at gcc dot gnu dot org  2010-01-02 23:00 
---
The root of the problem is plus_constant wrapping up a TLS symbol in a CONST:

(const:DI (plus:DI (symbol_ref:DI ("m") [flags 0x1a] )
(const_int 4 [0x4])))

what the SPARC back-end doesn't like.  So something like this works:

Index: explow.c
===
--- explow.c(revision 155516)
+++ explow.c(working copy)
@@ -137,7 +137,8 @@ plus_constant (rtx x, HOST_WIDE_INT c)

 case SYMBOL_REF:
 case LABEL_REF:
-  all_constant = 1;
+  if (CONSTANT_ADDRESS_P (x))
+   all_constant = 1;
   break;

 case PLUS:

but I presume other back-ends may not necessarily like it.


-- 


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

[Bug driver/42583] gfortran: libgomp.spec: No such file or directory

2010-01-02 Thread kargl at gcc dot gnu dot org



--- Comment #1 from kargl at gcc dot gnu dot org  2010-01-02 22:51 ---


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


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/41605] Static linking of libgcc/libgfortran/libstdc++ can cause inconsistent symbol resolution.

2010-01-02 Thread kargl at gcc dot gnu dot org



--- Comment #12 from kargl at gcc dot gnu dot org  2010-01-02 22:51 ---
*** Bug 42583 has been marked as a duplicate of this bug. ***


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu dot
   ||org


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

[Bug c++/42364] C++ testsuite fails with -g

2010-01-02 Thread rguenth at gcc dot gnu dot org



--- Comment #5 from rguenth at gcc dot gnu dot org  2010-01-02 22:44 ---
Fixed.


-- 

rguenth 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=42364

[Bug target/42564] unrecognizable insn with -O -fPIC

2010-01-02 Thread ebotcazou at gcc dot gnu dot org



--- Comment #7 from ebotcazou at gcc dot gnu dot org  2010-01-02 22:26 
---
Created an attachment (id=19451)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19451&action=view)
Reduced testcase.

Requires TLS support.


-- 


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

[Bug driver/42583] New: gfortran: libgomp.spec: No such file or directory

2010-01-02 Thread danglin at gcc dot gnu dot org

Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran
-B
/test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../
/test/gnu/gcc/gcc/gcc/testsui
te/gfortran.dg/gomp/recursion1.f90   -O0  -fopenmp -fcheck=recursion 
-B/test/gn
u/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs
-L/test/gnu/gcc/objdir/hppa
64-hp-hpux11.11/./libgfortran/.libs
-L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/.
/libgfortran/.libs -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libiberty  -lm  
 -o ./recursion1.exe(timeout = 300)
gfortran: libgomp.spec: No such file or directory
compiler exited with status 1
output is:
gfortran: libgomp.spec: No such file or directory

FAIL: gfortran.dg/gomp/recursion1.f90  -O0  (test for excess errors)


-- 
   Summary: gfortran: libgomp.spec: No such file or directory
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa64-hp-hpux11.11
  GCC host triplet: hppa64-hp-hpux11.11
GCC target triplet: hppa64-hp-hpux11.11


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

[Bug tree-optimization/42438] [4.4/4.5 Regression] Fix for PR38819 is too conservative

2010-01-02 Thread rguenth at gcc dot gnu dot org



--- Comment #4 from rguenth at gcc dot gnu dot org  2010-01-02 22:08 ---
With the patch we'll still not optimize

extern void bar (void);
int foo (int i, int j, int b)
{
  int res = 0;

  if (b)
res = i/j;

  res += i/j;
  bar ();
  return res;
}

That's not so easy to avoid.  We'd need to separately clean ANTIC_OUT
and EXP_GEN[BLOCK] - TMP_GEN[BLOCK], for the latter we can simply avoid
putting trapping expressions into EXP_GEN if a possibly noreturning call
precedes them in their basic-block.

In theory we might not need to clean EXP_GEN[BLOCK] - TMP_GEN[BLOCK] at all(?),
thus only clean S.  Only if we are also careful not adding expressions that
die in their own block to EXP_GEN.


-- 


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

[Bug tree-optimization/42438] [4.4/4.5 Regression] Fix for PR38819 is too conservative

2010-01-02 Thread rguenth at gcc dot gnu dot org



--- Comment #3 from rguenth at gcc dot gnu dot org  2010-01-02 21:54 ---
int foo (int i, int j, int b)
{
  int res = 0;
  if (b)
res = i/j;
  res += i/j;
  return res;
}

is a testcase that regressed.  I am testing a patch.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|enhancement |normal
Summary|Fix for PR38819 is too  |[4.4/4.5 Regression] Fix for
   |conservative|PR38819 is too conservative
   Target Milestone|--- |4.4.3


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

[Bug libfortran/42420] libgfortran fails to open large files on MINGW32

2010-01-02 Thread jb at gcc dot gnu dot org



--- Comment #7 from jb at gcc dot gnu dot org  2010-01-02 21:39 ---
Patch: http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00083.html


-- 

jb at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jb at gcc dot gnu dot org
   |dot org |
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2010-
   ||01/msg00083.html
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-12-18 08:51:37 |2010-01-02 21:39:09
   date||


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

[Bug bootstrap/42566] Bootstrap fails in stage3 building the libstdc++ PCH

2010-01-02 Thread 3dw4rd at verizon dot net



--- Comment #9 from 3dw4rd at verizon dot net  2010-01-02 21:10 ---
Command line from config.log:

It was created by package-unused configure version-unused, which was
generated by GNU Autoconf 2.64.  Invocation command line was

  $ /Users/ed/gcc/libstdc++-v3/configure --cache-file=./config.cache
--enable-multilib --prefix=/Users/ed/bin --with-gmp=/usr/local
--with-mpfr=/usr/local --with-mpc=/usr/local --enable-decimal-float
--enable-languages=c,c++,fortran,objc,obj-c++ --program-transform-name=s,y,y,
--disable-option-checking --with-target-subdir=powerpc-apple-darwin7.9.0
--build=powerpc-apple-darwin7.9.0 --host=powerpc-apple-darwin7.9.0
--target=powerpc-apple-darwin7.9.0 --srcdir=../../../gcc/libstdc++-v3
build_alias=powerpc-apple-darwin7.9.0 host_alias=powerpc-apple-darwin7.9.0
target_alias=powerpc-apple-darwin7.9.0 CPPFLAGS= --no-create --no-recursion


-- 


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

[Bug middle-end/42582] fortify with optimisation above -O0 cause abort in realpath()

2010-01-02 Thread pinskia at gcc dot gnu dot org



-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
  Component|c   |middle-end


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

[Bug middle-end/41043] [4.4/4.5 Regression] virtual memory exhausted: Cannot allocate memory

2010-01-02 Thread fxcoudert at gcc dot gnu dot org



-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

  GCC build triplet|*-apple-darwin9 |
   GCC host triplet|*-apple-darwin9 |
 GCC target triplet|*-apple-darwin9 |
   Keywords||compile-time-hog, memory-hog
  Known to fail||4.4.1 4.5.0
   Last reconfirmed|2009-08-12 13:14:04 |2010-01-02 21:02:20
   date||
   Target Milestone|4.4.3   |---


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

[Bug target/36502] i386/darwin generates unnecessary stack ops in every function

2010-01-02 Thread fxcoudert at gcc dot gnu dot org



--- Comment #2 from fxcoudert at gcc dot gnu dot org  2010-01-02 20:52 
---
Still present as of rev. 155544.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||missed-optimization
  Known to fail||4.4.0 4.5.0
   Last reconfirmed|-00-00 00:00:00 |2010-01-02 20:52:27
   date||


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

[Bug bootstrap/42566] Bootstrap fails in stage3 building the libstdc++ PCH

2010-01-02 Thread fxcoudert at gcc dot gnu dot org



--- Comment #8 from fxcoudert at gcc dot gnu dot org  2010-01-02 20:48 
---
And the command-line in config.log?


-- 


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

[Bug bootstrap/42566] Bootstrap fails in stage3 building the libstdc++ PCH

2010-01-02 Thread 3dw4rd at verizon dot net



--- Comment #7 from 3dw4rd at verizon dot net  2010-01-02 20:38 ---
Created an attachment (id=19450)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19450&action=view)
Grep for '^CXX' in the libstdc++ testsuite directory.

Multiple attachments would be nice.


-- 


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

[Bug bootstrap/42566] Bootstrap fails in stage3 building the libstdc++ PCH

2010-01-02 Thread 3dw4rd at verizon dot net



--- Comment #6 from 3dw4rd at verizon dot net  2010-01-02 20:37 ---
Created an attachment (id=19449)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19449&action=view)
Grep for '^CXX' in the libstdc++ src directory.


-- 


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

[Bug bootstrap/42566] Bootstrap fails in stage3 building the libstdc++ PCH

2010-01-02 Thread 3dw4rd at verizon dot net



--- Comment #5 from 3dw4rd at verizon dot net  2010-01-02 20:34 ---
Created an attachment (id=19448)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19448&action=view)
Grep for '^CXX' in the libstdc++ include directory.


-- 


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

[Bug middle-end/37921] __builtin_constant_p seems to be giving false positives

2010-01-02 Thread manu at gcc dot gnu dot org



--- Comment #9 from manu at gcc dot gnu dot org  2010-01-02 20:33 ---
(In reply to comment #8)
> Re-confirmed.  The issue is that we fold __builtin_constant_p only after
> VRP1 so the dead code remains and we warn about it.

Perhaps this is the root cause of both PR35392 and PR35903.



-- 


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

[Bug bootstrap/42566] Bootstrap fails in stage3 building the libstdc++ PCH

2010-01-02 Thread 3dw4rd at verizon dot net



--- Comment #4 from 3dw4rd at verizon dot net  2010-01-02 20:32 ---
Created an attachment (id=19447)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19447&action=view)
Greps for '^CXX' in the libstdc++ build directory and sibdirectories.


-- 


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

[Bug c/42582] fortify with optimisation above -O0 cause abort in realpath()

2010-01-02 Thread rguenth at gcc dot gnu dot org



--- Comment #2 from rguenth at gcc dot gnu dot org  2010-01-02 20:27 ---
You also need to attach preprocessed source as it will be very glibc
specific.


-- 


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

[Bug c/42582] fortify with optimisation above -O0 cause abort in realpath()

2010-01-02 Thread truedfx at gentoo dot org



--- Comment #1 from truedfx at gentoo dot org  2010-01-02 20:26 ---
The buffer should be at least PATH_MAX bytes. If PATH_MAX > 1024, then 1024
bytes need not be enough. But anyway, realpath() comes from glibc, so even if
this is a bug, you're reporting it to the wrong folks.


-- 


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

[Bug lto/42581] "gcc -v" doesn't work with lto

2010-01-02 Thread rguenth at gcc dot gnu dot org



--- Comment #1 from rguenth at gcc dot gnu dot org  2010-01-02 20:26 ---
Confirmed.  But -save-temps also doesn't work completely for -fwhopr (and you
need to set the collect2 env vars for -fwhopr).

The proper fix for 4.6 is to move most of the LTO handling to the gcc driver,
away from collect2, lto-wrapper and lto1.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-02 20:26:26
   date||


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

[Bug bootstrap/42566] Bootstrap fails in stage3 building the libstdc++ PCH

2010-01-02 Thread fxcoudert at gcc dot gnu dot org



--- Comment #3 from fxcoudert at gcc dot gnu dot org  2010-01-02 20:02 
---
Can you give us:

  1. The results of "grep '^CXX' Makefile" in directories
/Users/ed/obj/powerpc-apple-darwin7.9.0/libstdc++-v3/include and
/Users/ed/obj/powerpc-apple-darwin7.9.0/libstdc++-v3
  2. The long command line at the top of
Users/ed/obj/powerpc-apple-darwin7.9.0/libstdc++-v3/config.log (following the
text "Invocation command line was")

I don't see why the just built compiler is not picked up in your configuration,
as it is in mine.


-- 


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

[Bug c/42582] New: fortify with optimisation above -O0 cause abort in realpath()

2010-01-02 Thread pva at gentoo dot org

realpath() built with >=gcc-4.3 (where FORTIFY is enabled by default) and -Ox
where x>0 cause application to abort.

Test case: the following code built with gcc -O2:
==
#include 
#include 
#include 

int
main (int argc, char *argv[])
{
int ret;
char device_file_or_mount_point[1024];

if (argc < 2 || strlen (argv[1]) == 0) {
fprintf (stderr, "%s: pass relative path.\n", argv[0]);
return 1;
}

realpath(argv[1], device_file_or_mount_point);

return 0;
}
==

produces:

 $ ./a.out /boot/
*** buffer overflow detected ***: ./a.out terminated
=== Backtrace: =
/lib/libc.so.6(__fortify_fail+0x37)[0x7f1adb1c33a7]
/lib/libc.so.6[0x7f1adb1c03d0]
/lib/libc.so.6[0x7f1adb1c0a9b]
./a.out(main+0x55)[0x7f1adb6518c5]
/lib/libc.so.6(__libc_start_main+0xe6)[0x7f1adb1015c6]
./a.out[0x7f1adb651789]
=== Memory map: 
[snip]


I found this bug with umount.hal helper which started to fail here after this
commit:
http://cgit.freedesktop.org/hal/commit/?id=6d8eed9015a6ca648fe1dad575621b6ea959a748

But probably other applications are affected too. At least I found similar
issue with python reported here:
https://bugs.launchpad.net/ubuntu/+source/gcc-defaults/+bug/286334

Also I found that scilab has 6a5321bddceaf0e4761f29a507bfad6e1f3a7b33 commit
(googable) that basically modifies realpath(r,a) call to a=realpath(r,NULL).


Reproduced with gcc-4.4.2 (glibc-2.11) and gcc-4.3.4 (glibc-2.9_p20081201-r2)
 $ LC_ALL=C gcc --version
gcc (Gentoo 4.4.2 p1.0) 4.4.2
 $ uname -a
Linux tablet 2.6.32-gentoo #2 SMP PREEMPT Sat Dec 19 23:36:55 MSK 2009 x86_64
Intel(R) Core(TM)2 Duo CPU L7500 @ 1.60GHz GenuineIntel GNU/Linux


-- 
   Summary: fortify with optimisation above -O0 cause abort in
realpath()
   Product: gcc
   Version: 4.4.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pva at gentoo dot org


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

[Bug bootstrap/42424] in-tree GMP/MPFR/MPC bootstrap fails

2010-01-02 Thread fxcoudert at gcc dot gnu dot org



--- Comment #3 from fxcoudert at gcc dot gnu dot org  2010-01-02 19:53 
---
OK, I can reproduce the issue.

1. I have a GCC trunk (rev. 155544). In there I put symlinks to gmp-4.3.1,
mpfr-2.4.2 and mpc-0.8.1
2. From an empty build directory, I configure with: ../trunk/configure
--prefix=/Users/fx/devel/gcc/irun --enable-languages=c
3. "make" fails with:

checking for __gmpz_init in -lgmp... no
configure: error: libgmp not found or uses a different ABI.
make[2]: *** [configure-stage1-mpc] Error 1
make[1]: *** [stage1-bubble] Error 2
make: *** [all] Error 2


The problem is actually not an ABI one, but that the mpc configure fails with:

configure:10805: checking for __gmpz_init in -lgmp
configure:10830: gcc -o conftest -g -fkeep-inline-functions
-I/Users/fx/devel/gcc/ibin-intree/./gmp -I/Users/fx/devel/gcc/trunk/mpfr   
conftest.c -lgmp   >&5
ld: library not found for -lgmp

The problem is that mpc isn't told where to find the gmp and mpfr libraries. It
is confirmed by the mpc configure command-line (from mpc/config.log):

/Users/fx/devel/gcc/trunk/mpc/configure --cache-file=./config.cache
--prefix=/Users/fx/devel/gcc/irun --enable-languages=c
--program-transform-name=s,y,y, --disable-option-checking
--build=x86_64-apple-darwin10.2.0 --host=x86_64-apple-darwin10.2.0
--target=x86_64-apple-darwin10.2.0 --srcdir=../../trunk/mpc
--disable-intermodule --enable-checking=yes,types --disable-coverage
--enable-languages=c --disable-shared
--with-gmp-include=/Users/fx/devel/gcc/ibin-intree/./gmp
--with-mpfr-include=/Users/fx/devel/gcc/trunk/mpfr


This can be contrasted with mpfr, which is configured with
'--with-gmp-build=/Users/fx/devel/gcc/ibin-intree/./gmp', and thus knows where
to find libgmp. So it seems that the following patch should be applied to
configure.ac:

Index: configure.ac
===
--- configure.ac(revision 155544)
+++ configure.ac(working copy)
@@ -1287,7 +1287,7 @@
 if test "x$with_mpfr$with_mpfr_include$with_mpfr_lib" = x && test -d
${srcdir}/mpfr; then
   gmplibs='-L$$r/$(HOST_SUBDIR)/mpfr/.libs -L$$r/$(HOST_SUBDIR)/mpfr/_libs
'"$gmplibs"
   gmpinc='-I$$r/$(HOST_SUBDIR)/mpfr -I$$s/mpfr '"$gmpinc"
-  extra_mpc_mpfr_configure_flags='--with-mpfr-include=$$s/mpfr'
+  extra_mpc_mpfr_configure_flags='--with-mpfr-include=$$s/mpfr
--with-mpfr-lib=$$r/$(HOST_SUBDIR)/mpfr/.libs'
   # Do not test the mpfr version.  Assume that it is sufficient, since
   # it is in the source tree, and the library has not been built yet
   # but it would be included on the link line in the version check below
@@ -1321,7 +1321,7 @@
   gmplibs='-L$$r/$(HOST_SUBDIR)/gmp/.libs -L$$r/$(HOST_SUBDIR)/gmp/_libs
'"$gmplibs"
   gmpinc='-I$$r/$(HOST_SUBDIR)/gmp -I$$s/gmp '"$gmpinc"
   extra_mpfr_configure_flags='--with-gmp-build=$$r/$(HOST_SUBDIR)/gmp'
-  extra_mpc_gmp_configure_flags='--with-gmp-include=$$r/$(HOST_SUBDIR)/gmp'
+  extra_mpc_gmp_configure_flags='--with-gmp-include=$$r/$(HOST_SUBDIR)/gmp
--with-gmp-lib=$$r/$(HOST_SUBDIR)/gmp/.libs'
   # Do not test the gmp version.  Assume that it is sufficient, since
   # it is in the source tree, and the library has not been built yet
   # but it would be included on the link line in the version check below



Except that on some targets, ".libs" is actually called "_libs". I don't know
how to deal with that.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-02 19:53:42
   date||


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

[Bug middle-end/38808] another warning from system headers.

2010-01-02 Thread rguenth at gcc dot gnu dot org



--- Comment #4 from rguenth at gcc dot gnu dot org  2010-01-02 19:42 ---
Fixed in 4.5.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to fail||4.4.2
  Known to work||4.5.0
 Resolution||FIXED
   Target Milestone|--- |4.5.0


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

[Bug c++/38625] Segmentation fault when dereferencing valid pointer, probably REGRESSION

2010-01-02 Thread rguenth at gcc dot gnu dot org



--- Comment #12 from rguenth at gcc dot gnu dot org  2010-01-02 19:40 
---
Looks like invalid code in the first place.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


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

[Bug middle-end/37921] __builtin_constant_p seems to be giving false positives

2010-01-02 Thread rguenth at gcc dot gnu dot org



--- Comment #8 from rguenth at gcc dot gnu dot org  2010-01-02 19:35 ---
Re-confirmed.  The issue is that we fold __builtin_constant_p only after
VRP1 so the dead code remains and we warn about it.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|c   |middle-end
   Keywords||diagnostic
  Known to fail||4.5.0
   Last reconfirmed|2008-10-26 22:40:30 |2010-01-02 19:35:34
   date||


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

[Bug middle-end/37130] warning: array subscript is above array bounds.

2010-01-02 Thread rguenth at gcc dot gnu dot org



--- Comment #5 from rguenth at gcc dot gnu dot org  2010-01-02 19:30 ---
Works with 4.4 and 4.5.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to fail||4.3.4
  Known to work||4.4.2 4.5.0
 Resolution||FIXED
   Target Milestone|--- |4.4.2


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

[Bug c++/35966] array-subscript-above-bounds warning disappears when unrelated constructor definition is added

2010-01-02 Thread rguenth at gcc dot gnu dot org



--- Comment #2 from rguenth at gcc dot gnu dot org  2010-01-02 19:27 ---
Works for me with gcc 4.3.3.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Keywords||diagnostic
 Resolution||FIXED
   Target Milestone|--- |4.3.3


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

[Bug middle-end/35903] false uninitialized warning when passing quoted string to function strcmp(arg,"no");

2010-01-02 Thread rguenth at gcc dot gnu dot org



--- Comment #8 from rguenth at gcc dot gnu dot org  2010-01-02 19:24 ---
Similar to PR35392 this only happens with -funsigned-char, thus these may
as well be dups.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||35392
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-02 19:24:39
   date||


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

[Bug c/35392] Warning "array subscript is above array bounds" in inline fct

2010-01-02 Thread rguenth at gcc dot gnu dot org



--- Comment #4 from rguenth at gcc dot gnu dot org  2010-01-02 19:19 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail||4.5.0
   Last reconfirmed|-00-00 00:00:00 |2010-01-02 19:19:14
   date||


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

[Bug middle-end/42577] [4.4 Regression] array bounds false positive with -O3, goes away with -O2

2010-01-02 Thread rguenth at gcc dot gnu dot org



--- Comment #7 from rguenth at gcc dot gnu dot org  2010-01-02 19:15 ---
Fixed on the trunk sofar.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|rguenth at gcc dot gnu dot  |unassigned at gcc dot gnu
   |org |dot org
 Status|ASSIGNED|NEW
  Known to work||4.5.0
Summary|[4.4/4.5 Regression] array  |[4.4 Regression] array
   |bounds false positive with -|bounds false positive with -
   |O3, goes away with -O2  |O3, goes away with -O2


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

[Bug middle-end/42577] [4.4/4.5 Regression] array bounds false positive with -O3, goes away with -O2

2010-01-02 Thread rguenth at gcc dot gnu dot org



--- Comment #6 from rguenth at gcc dot gnu dot org  2010-01-02 19:15 ---
Subject: Bug 42577

Author: rguenth
Date: Sat Jan  2 19:14:52 2010
New Revision: 155577

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155577
Log:
2010-01-02  Richard Guenther  

PR middle-end/42577
* tree-vrp.c (check_all_array_refs): Skip non-excutable blocks.
(simplify_switch_using_ranges): Mark to be removed edges
as non-executable.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vrp.c


-- 


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

[Bug lto/42581] New: "gcc -v" doesn't work with lto

2010-01-02 Thread hjl dot tools at gmail dot com

[...@gnu-6 gcc]$ ./xgcc -B. -o t t1.o t2.o  -fwhopr -O -fdump-tree-optimized -v
Reading specs from ./specs
COLLECT_GCC=./xgcc
COLLECT_LTO_WRAPPER=./lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /export/gnu/import/git/gcc/configure --enable-languages=c,c++
--disable-bootstrap --prefix=/usr/gcc-4.5.0 --with-local-prefix=/usr/local
--with-plugin-ld=ld.gold --enable-gold
Thread model: posix
gcc version 4.5.0 20100102 (experimental) (GCC) 
COMPILER_PATH=./
LIBRARY_PATH=./:/lib/../lib64/:/usr/lib/../lib64/:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-B.' '-o' 't' '-fwhopr' '-O' '-fdump-tree-optimized' '-v'
'-mtune=generic'
 ./collect2 -fwhopr --eh-frame-hdr -m elf_x86_64 -dynamic-linker
/lib64/ld-linux-x86-64.so.2 -o t /usr/lib/../lib64/crt1.o
/usr/lib/../lib64/crti.o ./crtbegin.o -L. -L/lib/../lib64 -L/usr/lib/../lib64
t1.o t2.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed
-lgcc_s --no-as-needed ./crtend.o /usr/lib/../lib64/crtn.o
Reading specs from ./specs
COLLECT_GCC=././xgcc
COLLECT_LTO_WRAPPER=./lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /export/gnu/import/git/gcc/configure --enable-languages=c,c++
--disable-bootstrap --prefix=/usr/gcc-4.5.0 --with-local-prefix=/usr/local
--with-plugin-ld=ld.gold --enable-gold
Thread model: posix
gcc version 4.5.0 20100102 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-combine' '-c'
'-fltrans-output-list=/tmp/ccFzFDK6.ltrans.out' '-fwpa' '-B.' '-dumpbase' 't'
'-dumpdir' './' '-O' '-fdump-tree-optimized' '-v' '-mtune=generic'
 ./lto1 -quiet -dumpbase t1.o -dumpbase t -dumpdir ./ -mtune=generic -auxbase
t1 -O -version -fltrans-output-list=/tmp/ccFzFDK6.ltrans.out -fwpa
-fdump-tree-optimized @/tmp/cc1mIiH6
GNU GIMPLE (GCC) version 4.5.0 20100102 (experimental)
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.4.2 20091222 (Red Hat 4.4.2-20), GMP
version 4.3.1, MPFR version 2.4.2, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU GIMPLE (GCC) version 4.5.0 20100102 (experimental)
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.4.2 20091222 (Red Hat 4.4.2-20), GMP
version 4.3.1, MPFR version 2.4.2, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Reading specs from ./specs
COLLECT_GCC=././xgcc
COLLECT_LTO_WRAPPER=./lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /export/gnu/import/git/gcc/configure --enable-languages=c,c++
--disable-bootstrap --prefix=/usr/gcc-4.5.0 --with-local-prefix=/usr/local
--with-plugin-ld=ld.gold --enable-gold
Thread model: posix
gcc version 4.5.0 20100102 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-combine' '-c' '-B.' '-dumpbase' 't' '-dumpdir' './' '-O'
'-fdump-tree-optimized' '-v' '-mtune=generic' '-fltrans' '-o' 't2.wpa.ltrans.o'
 ./lto1 -quiet -dumpbase t2.wpa.o -dumpbase t -dumpdir ./ -mtune=generic
-auxbase-strip t2.wpa.ltrans.o -O -version -fdump-tree-optimized -fltrans
t2.wpa.o -o /tmp/ccMCxira.s
GNU GIMPLE (GCC) version 4.5.0 20100102 (experimental)
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.4.2 20091222 (Red Hat 4.4.2-20), GMP
version 4.3.1, MPFR version 2.4.2, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU GIMPLE (GCC) version 4.5.0 20100102 (experimental)
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.4.2 20091222 (Red Hat 4.4.2-20), GMP
version 4.3.1, MPFR version 2.4.2, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
COLLECT_GCC_OPTIONS='-combine' '-c' '-B.' '-dumpbase' 't' '-dumpdir' './' '-O'
'-fdump-tree-optimized' '-v' '-mtune=generic' '-fltrans' '-o' 't2.wpa.ltrans.o'
 ./as -V -Qy -o t2.wpa.ltrans.o /tmp/ccMCxira.s
GNU assembler version 2.20.51.0.5 (x86_64-unknown-linux-gnu) using BFD version
(Linux/GNU Binutils) 2.20.51.0.5.20091221
COMPILER_PATH=./:./
LIBRARY_PATH=./:/lib/../lib64/../lib64/:/usr/lib/../lib64/../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/lib/../lib64/:/usr/lib/../lib64/:./:/lib/../lib64/:/usr/lib/../lib64/:/lib/:/usr/lib/:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-combine' '-c' '-B.' '-dumpbase' 't' '-dumpdir' './' '-O'
'-fdump-tree-optimized' '-v' '-mtune=generic' '-fltrans' '-o' 't2.wpa.ltrans.o'
Reading specs from ./specs
COLLECT_GCC=././xgcc
COLLECT_LTO_WRAPPER=./lto-wrapper
Target: x86_64-unknown-linux-gnu
Confi

[Bug lto/42580] Missing command line option file causes ICE

2010-01-02 Thread hjl dot tools at gmail dot com



--- Comment #3 from hjl dot tools at gmail dot com  2010-01-02 17:39 ---
Fixed.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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

[Bug target/42564] ICE on sparc - unrecognizable insn

2010-01-02 Thread ebotcazou at gcc dot gnu dot org



--- Comment #6 from ebotcazou at gcc dot gnu dot org  2010-01-02 17:33 
---
I can reproduce on native (and with a cross by stealing the native
auto-host.h).


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ebotcazou at gcc dot gnu dot
   |dot org |org
 Status|WAITING |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-01-02 17:33:26
   date||


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

[Bug lto/42580] Missing command line option file causes ICE

2010-01-02 Thread hjl at gcc dot gnu dot org



--- Comment #2 from hjl at gcc dot gnu dot org  2010-01-02 17:30 ---
Subject: Bug 42580

Author: hjl
Date: Sat Jan  2 17:30:12 2010
New Revision: 155575

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155575
Log:
Stop if the command line option file is missing

2010-01-02  H.J. Lu  

PR lto/42580
* lto-elf.c (lto_elf_file_open): Stop if the command line
option file is missing.

Modified:
trunk/gcc/lto/ChangeLog
trunk/gcc/lto/lto-elf.c


-- 


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

[Bug tree-optimization/42337] [4.4 Regression] GCC ICE in compute_antic, at tree-ssa-pre.c:2534

2010-01-02 Thread rguenth at gcc dot gnu dot org



--- Comment #8 from rguenth at gcc dot gnu dot org  2010-01-02 17:12 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to fail|4.4.3   |4.4.2
  Known to work|4.3.4 4.5.0 |4.3.4 4.4.3 4.5.0
 Resolution||FIXED


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

[Bug tree-optimization/42337] [4.4 Regression] GCC ICE in compute_antic, at tree-ssa-pre.c:2534

2010-01-02 Thread rguenth at gcc dot gnu dot org



--- Comment #7 from rguenth at gcc dot gnu dot org  2010-01-02 17:12 ---
Subject: Bug 42337

Author: rguenth
Date: Sat Jan  2 17:12:15 2010
New Revision: 155573

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155573
Log:
2010-01-02  Richard Guenther  

Backport from mainline
2009-12-10  Richard Guenther  

PR tree-optimization/42337
* tree-ssa-pre.c (seen_during_translate): Remove.
(phi_translate_1): Collapse into ...
(phi_translate): ... this.  Remove seen parameter and
adjust recursive calls.

Backport from mainline
2009-12-09  Xinliang David Li  

PR tree-optimization/42337
* g++.dg/tree-ssa/pr42337.C: New test.

Added:
branches/gcc-4_4-branch/gcc/testsuite/g++.dg/tree-ssa/pr42337.C
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/gcc/tree-ssa-pre.c


-- 


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

[Bug driver/41564] -fdump-tree-all for lto does not work as expected

2010-01-02 Thread hjl dot tools at gmail dot com



--- Comment #18 from hjl dot tools at gmail dot com  2010-01-02 17:09 
---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00065.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2010-
   ||01/msg00065.html


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

[Bug lto/42580] Missing command line option file causes ICE

2010-01-02 Thread hjl dot tools at gmail dot com



--- Comment #1 from hjl dot tools at gmail dot com  2010-01-02 17:06 ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00064.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2010-
   ||01/msg00064.html


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

[Bug lto/42580] New: Missing command line option file causes ICE

2010-01-02 Thread hjl dot tools at gmail dot com

When I debug lto1, the missing command line option file generates
a misleading error message and causes ICE:


[...@gnu-34 gcc]$ touch x.s
[...@gnu-34 gcc]$ gcc -c x.s
[...@gnu-34 gcc]$ /export/build/gnu/gcc/build-x86_64-linux/gcc/lto1 -quiet
-dumpbase x.o -mtune=generic -auxbase-strip /tmp/cc0mkdyt.lto.o -O2 -version 
@/tmp/ccsQ6Ult -o y.s
GNU GIMPLE (GCC) version 4.5.0 20091229 (experimental)
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.5.0 20091229 (experimental), GMP version
4.3.1, MPFR version 2.4.2, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
lto1: internal compiler error: could not parse hex number
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[...@gnu-34 gcc]$


-- 
   Summary: Missing command line option file causes ICE
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug target/42536] [4.4/4.5 regression] ICE in spill_failure, at reload1.c:2141

2010-01-02 Thread jakub at gcc dot gnu dot org



--- Comment #3 from jakub at gcc dot gnu dot org  2010-01-02 16:44 ---
Reduced testcase:
/* { dg-do compile { target { { i?86-*-* x86_64-*-* } && ilp32 } } } */
/* { dg-options "-O2 -fno-gcse" } */

struct C;
struct B { struct C *b; };
struct C { void (*baz) (struct B *, void *, int); };
typedef union { int f; void *e; } D;
struct E { struct B *e; };
struct A { struct E *a1; D *a2; D *a3; };

void
foo (long *x, long y)
{
  *(long long *) x = y;
}

extern long fn1 (D);
extern void fn2 (void);

void
_bar (struct A *x)
{
  register int a asm ("esi");
  register D *volatile b asm ("edi");
  register int c asm ("ebx");
  void *d;
  asm volatile ("" : "=r" (a), "=r" (b), "=r" (c) : : "memory");
  if ((d = b[-2].e) != 0 && b [-2].e < d)
{
  foo (&(((long *) d) + 1) [b[0].f], fn1 (b[-1]));
  x->a2 = (D *) c;
  x->a3 = b;
  fn2 ();
}
  x->a1->e->b->baz (x->a1->e, (void *) (long) a, 1);
}

Wonder why RA doesn't try to force the memory address into register, that would
free up one register from the 4 otherwise needed (2 for the address, 2 for
DImode value being stored into the memory). 


-- 


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

[Bug middle-end/42577] [4.4/4.5 Regression] array bounds false positive with -O3, goes away with -O2

2010-01-02 Thread rguenth at gcc dot gnu dot org



-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.3


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

[Bug bootstrap/42424] in-tree GMP/MPFR/MPC bootstrap fails

2010-01-02 Thread developer at sandoe-acoustics dot co dot uk



--- Comment #2 from developer at sandoe-acoustics dot co dot uk  2010-01-02 
16:41 ---
(In reply to comment #1)
> I was able to do a C-only bootstrap of mainline with all three libraries
> in-tree on x86_64-unknown-linux-gnu.  I used mpc-0.8, mpfr-2.4.2, gmp-4.3.1 
> and
... 
> 1.  Is this a recent regression or has it always failed?
since the introduction of mpc - prior to that I had been using in-tree mpc/mpfr
with no issues.
[however the first version of mpc I've used is 0.8.1].
> 2.  What versions of the various libraries did you use?
gmp-4-3-1, mpfr-2-4-1 source trees.
mpc-0.8.1 source tree
> 3.  Does it fail with all versions of the libs or just some?
I haven't built with mpc prior to 0.8.1 - but these same gmp/mpfr versions
*were* OK prior to the introduction of mpc.
> 4.  The targets listed include darwin9 and i686-linux, do they both fail for
> the same reason?
yes - configure fail for mpc.
> 5.  Do you have other versions of gmp/mpfr installed somewhere that conflict
> with the bootstrap?
no, I don't install any of these libs on darwin.  
I have installed on i686-linux *since*, but the fault occurred on a fresh
ubuntu 9.10 install.

> 6.  Is there more info or investigation you can provide?
make check (mpc part) also fails when the mpc is built in tree - even when the
gm/mpfr libs are supplied using --with-{gmp,mpfr}= ... this perhaps points at
an mpc config change between 0.8 and 0.8.1 - since 0.8 works for you.


-- 


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

[Bug middle-end/42577] [4.4/4.5 Regression] array bounds false positive with -O3, goes away with -O2

2010-01-02 Thread rguenth at gcc dot gnu dot org



--- Comment #5 from rguenth at gcc dot gnu dot org  2010-01-02 16:41 ---
It's at least a regression towards where we didn't have array bound warnings.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||diagnostic
Summary|array bounds false positive |[4.4/4.5 Regression] array
   |with -O3, goes away with -O2|bounds false positive with -
   ||O3, goes away with -O2


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

[Bug libffi/42289] [4.3 only] libffi fails to build with binutils-2.20 on ARM

2010-01-02 Thread rguenth at gcc dot gnu dot org



-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.3.5   |---


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

[Bug rtl-optimization/41917] [4.3 Regression] Strange athrithmetic result with -O3

2010-01-02 Thread rguenth at gcc dot gnu dot org



-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail|4.3.4   |4.3.4 4.4.2
   Priority|P3  |P2


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

[Bug rtl-optimization/41646] [4.3 Regression] Reload ICE due to combiner extending life time of a hard register

2010-01-02 Thread rguenth at gcc dot gnu dot org



-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  Known to fail||4.3.4 4.4.1
  Known to work||4.4.2 4.5.0
   Priority|P3  |P2
   Last reconfirmed|-00-00 00:00:00 |2010-01-02 16:29:44
   date||


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

[Bug middle-end/41623] [4.3 Regression] ICE: emit_move_insn at expr.c 3162 when compiling template code.

2010-01-02 Thread rguenth at gcc dot gnu dot org



-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail|4.3.4   |4.3.4 4.4.0
   Priority|P3  |P2


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

[Bug c++/41131] [4.3 Regression] non-lvalue in unary `&' wrongly accepted

2010-01-02 Thread rguenth at gcc dot gnu dot org



--- Comment #12 from rguenth at gcc dot gnu dot org  2010-01-02 16:25 
---
Wontfix on the 4.3 branch, we usually do not backport accepts-invalid fixes.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to fail|4.3.0 4.4.0 |4.3.4 4.4.1
 Resolution||FIXED
   Target Milestone|4.3.5   |4.4.2


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

[Bug bootstrap/42424] in-tree GMP/MPFR/MPC bootstrap fails

2010-01-02 Thread ghazi at gcc dot gnu dot org



--- Comment #1 from ghazi at gcc dot gnu dot org  2010-01-02 16:24 ---
I was able to do a C-only bootstrap of mainline with all three libraries
in-tree on x86_64-unknown-linux-gnu.  I used mpc-0.8, mpfr-2.4.2, gmp-4.3.1 and
bootstrapped with gcc-4.3.2.  I cannot reproduce this problem, so we need more
info, e.g.

1.  Is this a recent regression or has it always failed?
2.  What versions of the various libraries did you use?
3.  Does it fail with all versions of the libs or just some?
4.  The targets listed include darwin9 and i686-linux, do they both fail for
the same reason?
5.  Do you have other versions of gmp/mpfr installed somewhere that conflict
with the bootstrap?
6.  Is there more info or investigation you can provide?


-- 


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

[Bug c++/40561] [4.3 Regression] code does not compile -- compiles fine when replacing != with !(==)

2010-01-02 Thread rguenth at gcc dot gnu dot org



--- Comment #9 from rguenth at gcc dot gnu dot org  2010-01-02 16:23 ---
Fascinating indeed.  If someone can bisect where during 4.4 development we
fixed this again or where during 4.3 development we broke it that would be
nice.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||rejects-valid
  Known to fail|4.3.3   |4.3.0 4.3.4
  Known to work|4.2.1 4.4.1 4.5.0   |4.2.4 4.4.0 4.5.0
   Priority|P3  |P2
   Last reconfirmed|2009-08-26 22:01:37 |2010-01-02 16:23:06
   date||
Summary|[4.3 regression] code does  |[4.3 Regression] code does
   |not compile -- compiles fine|not compile -- compiles fine
   |when replacing != with !(==)|when replacing != with !(==)


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

[Bug middle-end/42574] [4.3/4.4/4.5 Regression] Address of global variable is calculated multiple times (missed CSE)

2010-01-02 Thread rguenth at gcc dot gnu dot org



-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug tree-optimization/42558] [4.5 Regression] miscompilation related to -floop-block

2010-01-02 Thread rguenth at gcc dot gnu dot org



-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|middle-end  |tree-optimization
   Priority|P3  |P1


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

[Bug tree-optimization/42521] [4.5 Regression] ICE: in graphite_loop_normal_form, at graphite-sese-to-poly.c:2844

2010-01-02 Thread rguenth at gcc dot gnu dot org



-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug tree-optimization/42508] [4.5 Regression] wrong code with "-O1 -fipa-sra"

2010-01-02 Thread rguenth at gcc dot gnu dot org



--- Comment #3 from rguenth at gcc dot gnu dot org  2010-01-02 16:13 ---
Confirmed.  Doesn't happen on i?86-linux or with -m32.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug driver/42485] [4.4/4.5 Regression] -V switch broken

2010-01-02 Thread rguenth at gcc dot gnu dot org



-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug middle-end/42482] [4.5 Regression] Many graphite test failures

2010-01-02 Thread rguenth at gcc dot gnu dot org



-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug tree-optimization/42462] [4.5 Regression] wrong-code with computed-goto

2010-01-02 Thread rguenth at gcc dot gnu dot org



-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug rtl-optimization/42461] [4.5 Regression] Missed optimisation for pure functions with __builtin_unreachable

2010-01-02 Thread rguenth at gcc dot gnu dot org



-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug middle-end/42450] [4.5 Regression] another GCC 4.5 ICE on C++ templated code

2010-01-02 Thread rguenth at gcc dot gnu dot org



-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug target/42431] [4.5 Regression] wrong code for 200.sixtrack with vectorization and -fdata-sections

2010-01-02 Thread rguenth at gcc dot gnu dot org



--- Comment #2 from rguenth at gcc dot gnu dot org  2010-01-02 16:06 ---
Testcaese?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug target/42427] [4.5 Regression] invalid assembly code for 301.apsi for -fnon-call-exceptions

2010-01-02 Thread rguenth at gcc dot gnu dot org



--- Comment #1 from rguenth at gcc dot gnu dot org  2010-01-02 16:05 ---
Huh, but this looks like a target problem if we generate invalid assembly.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

1 2 >

1 - 100 of 150 matches

Mail list logo