[Bug rtl-optimization/42592] New: really bad register allocation for x86
From http://embed.cs.utah.edu/embarrassing/dec_09/harvest/gcc-head_icc-11.1/
typedef unsigned int size_t;
typedef __builtin_va_list __gnuc_va_list;
typedef __gnuc_va_list va_list;
typedef size_t STRLEN;
struct sv;
typedef struct sv SV;
typedef int I32;
typedef unsigned int U32;
struct sv
{
void *sv_any;
U32 sv_refcnt;
U32 sv_flags;
};
void Perl_sv_setpvn (SV * sv, char const *ptr, STRLEN len);
void Perl_sv_vcatpvfn (SV * sv, char const *pat, STRLEN patlen,
va_list * args, SV ** svargs, I32 svmax,
char *maybe_tainted);
void Perl_sv_vsetpvfn (SV * sv, char const *pat, STRLEN patlen,
va_list * args, SV ** svargs, I32 svmax,
char *maybe_tainted);
void Perl_sv_vcatpvfn (SV * sv, char const *pat, STRLEN patlen,
va_list * args, SV ** svargs, I32 svmax,
char *maybe_tainted);
void Perl_sv_vcatpvfn (SV * sv, char const *pat, STRLEN patlen,
va_list * args, SV ** svargs, I32 svmax,
char *maybe_tainted);
void Perl_sv_setpvn (SV * sv, char const *ptr, STRLEN len);
void
Perl_sv_vsetpvfn (SV * sv, char const *pat, STRLEN patlen, va_list * args,
SV ** svargs, I32 svmax, char *maybe_tainted)
{
{
Perl_sv_setpvn (sv, , 0U);
Perl_sv_vcatpvfn (sv, pat, patlen, args, svargs, svmax, maybe_tainted);
return;
}
}
/* Checksum = 9EEF59B7 */
with icc this gives a neat
0: 57 push %edi
1: 8b 7c 24 08 mov0x8(%esp),%edi
5: 6a 00 push $0x0
7: 68 00 00 00 00 push $0x0
c: 57 push %edi
d: e8 fc ff ff ff call e Perl_sv_vsetpvfn+0xe
12: ff 74 24 2c pushl 0x2c(%esp)
16: ff 74 24 2c pushl 0x2c(%esp)
1a: ff 74 24 2c pushl 0x2c(%esp)
1e: ff 74 24 2c pushl 0x2c(%esp)
22: ff 74 24 2c pushl 0x2c(%esp)
26: ff 74 24 2c pushl 0x2c(%esp)
2a: 57 push %edi
2b: e8 fc ff ff ff call 2c Perl_sv_vsetpvfn+0x2c
30: 83 c4 28add$0x28,%esp
33: 5f pop%edi
34: c3 ret
but gcc produces terrible register allocation (-m32 -O2 4.5.0 20091219)
in comparison (like first loading arguments into registers, just to spill
them again on a function call):
pushl %ebp
movl%esp, %ebp
pushl %edi
pushl %esi
pushl %ebx
subl$32, %esp
movl12(%ebp), %eax
movl8(%ebp), %ebx
movl28(%ebp), %edx
movl32(%ebp), %ecx
movl%eax, -28(%ebp)
movl24(%ebp), %eax
pushl $0
movl16(%ebp), %esi
pushl $.LC0
movl20(%ebp), %edi
pushl %ebx
movl%eax, -32(%ebp)
movl%edx, -36(%ebp)
movl%ecx, -40(%ebp)
callPerl_sv_setpvn
movl-32(%ebp), %eax
addl$16, %esp
movl-40(%ebp), %ecx
movl-36(%ebp), %edx
movl%edi, 20(%ebp)
movl%eax, 24(%ebp)
movl-28(%ebp), %eax
movl%esi, 16(%ebp)
movl%ebx, 8(%ebp)
movl%ecx, 32(%ebp)
movl%edx, 28(%ebp)
movl%eax, 12(%ebp)
leal-12(%ebp), %esp
popl%ebx
popl%esi
popl%edi
popl%ebp
jmp Perl_sv_vcatpvfn
--
Summary: really bad register allocation for x86
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42592
[Bug tree-optimization/42586] New: load-modify-store on x86 should be \ single instruction
--- Comment #17 from andi-gcc at firstfloor dot org 2010-01-03 08:12 --- Nope, the examples all disable frame pointer (the first version of the tester had this problem, but that was fixed) It's all not frame pointer set up anyways, but sub $...,%esp ... ; add $...,%esp with no use of the stack frame (or often even nothing at all) inbetween -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42586
[Bug tree-optimization/42587] bswap not recognized for memory
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-03 10:58 --- Confirmed. The bswap detection does not work on memory at all but only detects it on registers. -- rguenth 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 10:58:04 date|| Summary|bswap not recognized for|bswap not recognized for |union |memory http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42587
[Bug tree-optimization/42586] load-modify-store on x86 should be a single instruction
--- Comment #18 from rguenth at gcc dot gnu dot org 2010-01-03 11:11
---
Confirmed. This is indeed showing two cases of SRA behaving oddly. First
early SRA produces
bb 2:
_T2 = *sptr_1(D);
_ans = _T2;
_ans$curr_12 = _T2.curr;
D.1965_6 = _ans$curr_12;
D.1966_7 = D.1965_6 + -1;
_ans$curr_2 = D.1966_7;
*sptr_1(D) = _ans;
sptr_1(D)-curr = _ans$curr_2;
from
bb 2:
_T2 = *sptr_1(D);
_ans = _T2;
D.1965_6 = _ans.curr;
D.1966_7 = D.1965_6 + -1;
_ans.curr = D.1966_7;
*sptr_1(D) = _ans;
then late SRA continues to obfuscate things by producing
bb 2:
_T2 = *sptr_1(D);
_T2$curr_14 = sptr_1(D)-curr;
_ans = _T2;
_ans.curr = _T2$curr_14;
_ans$curr_12 = _T2$curr_14;
D.1966_7 = _ans$curr_12 + -1;
*sptr_1(D) = _ans;
sptr_1(D)-curr = D.1966_7;
note how both times it increases the amount of variables and their lifetime
(I think it's bad we run SRA twice anyway). The first SRA pass should
have produced
_T2$curr_10 = sptr_1(D)-curr;
D.1965_6 = _T2$curr_10;
D.1966_7 = D.1965_6 + -1;
_T2$curr_11 = D.1966_7;
sptr_1(D)-curr = _T2$curr_11;
The old ESRA implementation decomposed all structure copies completely
and thus left to produce the above by further scalar optimizations:
bb 2:
_T2$last_plus_one_2 = sptr_1(D)-last_plus_one;
_T2$base_3 = sptr_1(D)-base;
_T2$curr_4 = sptr_1(D)-curr;
_ans$last_plus_one_5 = _T2$last_plus_one_2;
_ans$base_8 = _T2$base_3;
_ans$curr_9 = _T2$curr_4;
D.1262_6 = _ans$curr_9;
D.1263_7 = D.1262_6 + -1;
_ans$curr_10 = D.1263_7;
sptr_1(D)-last_plus_one ={v} _ans$last_plus_one_5;
sptr_1(D)-base ={v} _ans$base_8;
sptr_1(D)-curr ={v} _ans$curr_10;
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-01-03 11:11:22
date||
Summary|New: load-modify-store on |load-modify-store on x86
|x86 should be \ single |should be a single
|instruction |instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42586
[Bug bootstrap/42584] GCC 4.5 doesn't come close to bootstrapping on MinGW/MSYS
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-03 11:15 --- *** This bug has been marked as a duplicate of 42424 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42584
[Bug bootstrap/42424] in-tree GMP/MPFR/MPC bootstrap fails
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-03 11:15 --- *** Bug 42584 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||lxndrmxwll at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42424
[Bug bootstrap/42424] [4.5 Regression] in-tree GMP/MPFR/MPC bootstrap fails
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-01-03 11:16 --- I think we want to make this work for 4.5 again, it works for 4.4 - of course w/o mpc which causes the problems here. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org Priority|P3 |P1 Summary|in-tree GMP/MPFR/MPC|[4.5 Regression] in-tree |bootstrap fails |GMP/MPFR/MPC bootstrap fails Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42424
[Bug rtl-optimization/42592] really bad register allocation for x86
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-03 11:27 --- Confirmed. Well, GCC produces exactly the same code as ICC when using -O2 -mno-accumulate-outgoing-args -fno-optimize-sibling-calls -fomit-frame-pointer Thus the sibcall comes in the way as obviously does -maccumulate-outgoing-args. w/o -maccumulate-outgoing-args but the rest of the options we produce Perl_sv_vsetpvfn: pushl %ebx subl$40, %esp movl48(%esp), %ebx movl$0, 8(%esp) movl$.LC0, 4(%esp) movl%ebx, (%esp) callPerl_sv_setpvn movl72(%esp), %eax movl%ebx, (%esp) movl%eax, 24(%esp) movl68(%esp), %eax movl%eax, 20(%esp) movl64(%esp), %eax movl%eax, 16(%esp) movl60(%esp), %eax movl%eax, 12(%esp) movl56(%esp), %eax movl%eax, 8(%esp) movl52(%esp), %eax movl%eax, 4(%esp) callPerl_sv_vcatpvfn addl$40, %esp popl%ebx ret which looks like we cannot do better with that constraint. The sibcall variant isn't too bad either. Of course with sibcalling and -mno-accumulate-outgoing-args we fail to re-order argument setup for optimal size, even with -fschedule-insns. So that part of the bug would be valid. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||vmakarov at redhat dot com Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization, ra Last reconfirmed|-00-00 00:00:00 |2010-01-03 11:27:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42592
[Bug rtl-optimization/42589] bswap optimization does not work for 32bit (but for 64bit) on 64bit registers
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-03 11:34 --- Because with 32bit we do not have a 64bit bswap instruction and tmp is 64bit. What would you expect here? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Keywords||missed-optimization Summary|bswap optimization does not |bswap optimization does not |work for 32bit (but for |work for 32bit (but for |64bit) |64bit) on 64bit registers http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42589
[Bug middle-end/42582] fortify with optimisation above -O0 cause abort in realpath()
--- Comment #3 from jakub at gcc dot gnu dot org 2010-01-03 11:38 --- The testcase is indeed invalid, if the second argument to realpath is not NULL, it must be a buffer at least PATH_MAX bytes long. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42582
[Bug rtl-optimization/42589] bswap optimization does not work for 32bit (but for 64bit) on 64bit registers
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-03 11:45 --- With Index: tree-ssa-math-opts.c === --- tree-ssa-math-opts.c(revision 155576) +++ tree-ssa-math-opts.c(working copy) @@ -,8 +,9 @@ execute_optimize_bswap (void) optab_handler (bswap_optab, SImode)-insn_code != CODE_FOR_nothing); bswap64_p = (built_in_decls[BUILT_IN_BSWAP64] - optab_handler (bswap_optab, DImode)-insn_code != - CODE_FOR_nothing); + (optab_handler (bswap_optab, DImode)-insn_code != + CODE_FOR_nothing + || bswap32_p)); if (!bswap32_p !bswap64_p) return 0; and thus generic expansion for 64bit bswap we produce - movl%edx, %edi - movl%ecx, %esi - andl$-16711936, %edi - andl$-16711936, %esi - movl%edi, -36(%ebp) - movl%esi, -40(%ebp) - movl-36(%ebp), %edi - movl-40(%ebp), %esi - andl$16711935, %ecx - shrdl $8, %edi, %esi - movl%ecx, -48(%ebp) - movl%esi, -32(%ebp) - shrl$8, %edi - movl-48(%ebp), %esi - movl%edi, -28(%ebp) - andl$16711935, %edx - movl-28(%ebp), %ecx - movl%edx, -44(%ebp) - movl-32(%ebp), %edx - movl-44(%ebp), %edi - shldl $8, %esi, %edi - sall$8, %esi - orl %edi, %ecx - orl %esi, %edx - movzwl %cx, %esi - movzwl %dx, %edi - movl%esi, -52(%ebp) - movl%edi, -56(%ebp) - xorw%dx, %dx - movl-56(%ebp), %esi - movl%edx, -64(%ebp) - movl-52(%ebp), %edi - xorw%cx, %cx - shldl $16, %esi, %edi - movl%ecx, -60(%ebp) - movl%edi, -28(%ebp) - sall$16, %esi - movl-60(%ebp), %edi - movl%esi, -32(%ebp) - movl-28(%ebp), %ecx - movl-64(%ebp), %esi - movl-32(%ebp), %edx - shrdl $16, %edi, %esi - shrl$16, %edi - orl %esi, %edx - orl %edi, %ecx - movl%edx, (%ebx,%eax,8) - movl%ecx, 4(%ebx,%eax,8) - movl8(%ebp), %edi - movl%edx, (%edi,%eax,8) - movl%ecx, 4(%edi,%eax,8) + bswap %edx + bswap %ecx + movl%edx, 4(%ebx,%eax,8) + movl%ecx, (%ebx,%eax,8) + movl%ecx, (%esi,%eax,8) + movl%edx, 4(%esi,%eax,8) No idea if it is generally a good idea to do this on all targets though. At least we'd go through expand_doubleword_bswap which should be pretty much optimal. -- 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|WAITING |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-01-03 11:45:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42589
[Bug tree-optimization/42438] [4.4/4.5 Regression] Fix for PR38819 is too conservative
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-01-03 12:06 --- Subject: Bug 42438 Author: rguenth Date: Sun Jan 3 12:06:02 2010 New Revision: 155584 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155584 Log: 2010-01-03 Richard Guenther rguent...@suse.de PR tree-optimization/42438 * tree-ssa-pre.c (struct bb_bitmap_sets): Add contains_may_not_return_call flag. (BB_MAY_NOTRETURN): New. (valid_in_sets): Trapping nary operations are not valid in blocks that may not return. (insert_into_preds_of_block): Remove check for trapping expressions. (compute_avail): Compute also BB_MAY_NOTRETURN. * gcc.dg/tree-ssa/ssa-pre-27.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-27.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-pre.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42438
[Bug tree-optimization/42438] [4.4 Regression] Fix for PR38819 is too conservative
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-01-03 12:10 --- Fixed for 4.5 as good as we can. -- 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] Fix for|[4.4 Regression] Fix for |PR38819 is too conservative |PR38819 is too conservative http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42438
[Bug rtl-optimization/42589] bswap optimization does not work for 32bit (but for 64bit) on 64bit registers
--- Comment #3 from jakub at gcc dot gnu dot org 2010-01-03 12:19 --- Shouldn't that be || (bswap32_p word_mode == SImode) ? expand_unop will only call expand_doubleword_bswap in that case... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42589
[Bug rtl-optimization/42589] bswap optimization does not work for 32bit (but for 64bit) on 64bit registers
--- Comment #4 from rguenther at suse dot de 2010-01-03 12:28 ---
Subject: Re: bswap optimization does not work
for 32bit (but for 64bit) on 64bit registers
On Sun, 3 Jan 2010, jakub at gcc dot gnu dot org wrote:
--- Comment #3 from jakub at gcc dot gnu dot org 2010-01-03 12:19 ---
Shouldn't that be || (bswap32_p word_mode == SImode) ? expand_unop
will only call expand_doubleword_bswap in that case...
Hm, yeah. I wonder why it doesn't try
half_mode = smallest_mode_for_size (GET_MODE_PRECISION (mode) / 2, MODE_INT);
if (GET_MODE_SIZE (mode) == 2 * GET_MODE_SIZE
(half_mode)
optab_handler (unoptab, half_mode)-insn_code !=
CODE_FOR_nothing)
{
temp = expand_doubleword_bswap (mode, op0, target);
if (temp)
return temp;
}
or similar. Though in practice it might not matter...
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42589
[Bug libstdc++/42593] New: [c++0x] std::bind not assignable to std::function
The following code compiles fine with GCC 4.3.3 and 4.4.2, but fails to compile
with 4.5 (snapshot from 2009-12-31):
#include functional
void f( int ) {}
int main() { std::function void( int ) pf = std::bind( f,
std::placeholders::_1 ); }
with the following error:
In file included from t.cc:1:0:
/home/frey/work/install/gcc-4.5-snapshot/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/functional:
In static member function #130;Äòstatic void
std::_Function_handlervoid(_ArgTypes ...), _Functor::_M_invoke(const
std::_Any_data, _ArgTypes ...) [with _Functor = std::_Bindvoid
(*(std::_Placeholder1))(int), _ArgTypes = {int}]#130;Äô:
/home/frey/work/install/gcc-4.5-snapshot/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/functional:2127:6:
instantiated from #130;Äòstd::function_Res(_ArgTypes
...)::function(_Functor, typename __gnu_cxx::__enable_if(!
std::is_integral_Functor::value), std::function_Res(_ArgTypes
...)::_Useless::__type) [with _Functor = std::_Bindvoid
(*(std::_Placeholder1))(int), _Res = void, _ArgTypes = {int}, typename
__gnu_cxx::__enable_if(! std::is_integral_Functor::value),
std::function_Res(_ArgTypes ...)::_Useless::__type =
std::functionvoid(int)::_Useless]#130;Äô
t.cc:3:85: instantiated from here
/home/frey/work/install/gcc-4.5-snapshot/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/functional:1748:9:
error: no match for call to #130;Äò(std::_Bindvoid
(*(std::_Placeholder1))(int)) (int)#130;Äô
/home/frey/work/install/gcc-4.5-snapshot/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/functional:1219:9:
note: candidates are: typename std::result_of_Functor(typename
std::result_ofstd::_Mu_Bound_args(_Bound_args, std::tuple_UElements
...)::type ...)::type std::_Bind_Functor(_Bound_args
...)::operator()(_Args ...) [with _Args = {int}, _Functor = void (*)(int),
_Bound_args = {std::_Placeholder1}, typename std::result_of_Functor(typename
std::result_ofstd::_Mu_Bound_args(_Bound_args, std::tuple_UElements
...)::type ...)::type = void]
/home/frey/work/install/gcc-4.5-snapshot/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/functional:1230:9:
note:typename std::result_ofconst _Functor(typename
std::result_ofstd::_Mu_Bound_args(_Bound_args, std::tuple_UElements
...)::type ...)::type std::_Bind_Functor(_Bound_args
...)::operator()(_Args ...) const [with _Args = {int}, _Functor = void
(*)(int), _Bound_args = {std::_Placeholder1}, typename std::result_ofconst
_Functor(typename std::result_ofstd::_Mu_Bound_args(_Bound_args,
std::tuple_UElements ...)::type ...)::type = void]
/home/frey/work/install/gcc-4.5-snapshot/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/functional:1242:9:
note:typename std::result_ofvolatile _Functor(typename
std::result_ofstd::_Mu_Bound_args(_Bound_args, std::tuple_UElements
...)::type ...)::type std::_Bind_Functor(_Bound_args
...)::operator()(_Args ...) volatile [with _Args = {int}, _Functor = void
(*)(int), _Bound_args = {std::_Placeholder1}, typename
std::result_ofvolatile _Functor(typename
std::result_ofstd::_Mu_Bound_args(_Bound_args, std::tuple_UElements
...)::type ...)::type = void]
/home/frey/work/install/gcc-4.5-snapshot/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/functional:1255:9:
note:typename std::result_ofconst volatile _Functor(typename
std::result_ofstd::_Mu_Bound_args(_Bound_args, std::tuple_UElements
...)::type ...)::type std::_Bind_Functor(_Bound_args
...)::operator()(_Args ...) const volatile [with _Args = {int}, _Functor =
void (*)(int), _Bound_args = {std::_Placeholder1}, typename
std::result_ofconst volatile _Functor(typename
std::result_ofstd::_Mu_Bound_args(_Bound_args, std::tuple_UElements
...)::type ...)::type = void]
--
Summary: [c++0x] std::bind not assignable to std::function
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: d dot frey at gmx dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42593
[Bug libstdc++/42593] [c++0x] [4.5 Regression] std::bind not assignable to std::function
--- Comment #1 from paolo dot carlini at oracle dot com 2010-01-03 12:47 --- Thanks Daniel. Jon, can you have a look? I verified that the tr1 code we were using in 4.4.x and before is fine, thus should be either the std::function changes vs rvalue references or, less likely I believe, the void special case changes. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-01-03 12:47:29 date|| Summary|[c++0x] std::bind not |[c++0x] [4.5 Regression] |assignable to std::function |std::bind not assignable to ||std::function http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42593
[Bug rtl-optimization/42594] New: no store merging for structure stores
Extracted from
http://embed.cs.utah.edu/embarrassing/dec_09/harvest/gcc-head_llvm-gcc-head/
I've seen this in multiple examples both compared to llvm and icc.
The other compilers merge adjacent stores to structures in memory,
gcc doesn't.
Simple toy example:
struct foo {
short a;
char c;
char d;
int x;
};
void f(struct foo *f)
{
f-a = 1;
f-c = 0;
f-d = 1;
f-x = 0;
}
generates with -O2 -S -mtune=generic 4.5.0 20091219
movw$1, (%rdi)
movb$0, 2(%rdi)
movb$1, 3(%rdi)
movl$0, 4(%rdi)
but since everything is aligned it could be just (from icc)
movl $16777217, (%rdi) #11.2
movl $0, 4(%rdi) #14.2
(possibly even a single movq, exploiting CPUs with very fast misalignment
support like Nehalem)
--
Summary: no store merging for structure stores
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=42594
[Bug java/41745] Segmentation fault when ecj.jar is run as a binary compiled by gcj
--- Comment #6 from gerald at pfeifer dot com 2010-01-03 13:10 --- Would you mind trying again with the latest snapshot/SVN version of GCC (or the current version of lang/gcc45, if you prefer)? There have been some improvements recently to libffi which may make a difference. (It does look like a threading issue, but who knows...) Greg, this may be similar/related to what you have been seeing? -- gerald at pfeifer dot com changed: What|Removed |Added GCC build triplet||glar...@freebsd.org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41745
[Bug rtl-optimization/42589] bswap optimization does not work for 32bit (but for 64bit) on 64bit registers
--- Comment #5 from andi-gcc at firstfloor dot org 2010-01-03 13:11 --- I would expect two bswaps yes, like llvm generates I also can't see how this should be a bad idea for any target with a bswap like operation (unless it's 64bit) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42589
[Bug tree-optimization/42586] load-modify-store on x86 should be a single instruction
--- Comment #19 from andi-gcc at firstfloor dot org 2010-01-03 13:18
---
Here's another example with the bogus stack frame problem with a tail call
(the embarassing website has quite a lot of similar cases, normally
near the tail of the tables with 16 vs 22 bytes e.g. against sun cc
which also does tail optimization):
typedef long __clock_t;
typedef __clock_t clock_t;
struct lprofS_sSTACK_RECORD;
typedef struct lprofS_sSTACK_RECORD lprofS_STACK_RECORD;
struct lprofS_sSTACK_RECORD
{
clock_t time_marker_function_local_time;
clock_t time_marker_function_total_time;
char *file_defined;
char *function_name;
char *source_code;
long line_defined;
long current_line;
float local_time;
float total_time;
lprofS_STACK_RECORD *next;
};
typedef lprofS_STACK_RECORD *lprofS_STACK;
struct lprofP_sSTATE;
typedef struct lprofP_sSTATE lprofP_STATE;
struct lprofP_sSTATE
{
int stack_level;
lprofS_STACK stack_top;
};
extern void lprofC_start_timer (clock_t * time_marker);
void lprofM_resume_local_time (lprofP_STATE * S);
void
lprofM_resume_local_time (lprofP_STATE * S)
{
{
lprofC_start_timer ((S-stack_top)-time_marker_function_local_time);
return;
}
}
gives with -m32 -fomit-frame-pointer -O2 and 4.5.0 20091219
subl$12, %esp
movl16(%esp), %eax
movl4(%eax), %eax
movl%eax, 16(%esp)
addl$12, %esp
jmp lprofC_start_timer
The subl/addl are completely unnecessary
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42586
[Bug rtl-optimization/42594] no store merging for structure stores
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-03 13:20 --- Old problem - there's a duplicate report even somewhere with a patch from Jakub. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42594
[Bug rtl-optimization/42594] no store merging for structure stores
--- Comment #2 from steven at gcc dot gnu dot org 2010-01-03 13:22 --- Not sure, but looks like a dup of bug 22141. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42594
[Bug rtl-optimization/42594] no store merging for structure stores
-- steven 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-03 13:22:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42594
[Bug rtl-optimization/42594] no store merging for structure stores
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-03 13:30 --- It is. *** This bug has been marked as a duplicate of 22141 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42594
[Bug middle-end/22141] [4.3/4.4/4.5 Regression] Missing optimization when storing structures
--- Comment #20 from rguenth at gcc dot gnu dot org 2010-01-03 13:30 --- *** Bug 42594 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||andi-gcc at firstfloor dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22141
[Bug target/41311] [4.5 regression] m68k - FFmpeg crashes when converting mpg to avi
--- Comment #13 from nospamname at web dot de 2010-01-03 13:57 ---
Can this report reopen please and target change to m68k-* ?
Bug happen also in m68k-elf.See here the two fjlt .L319 to diffrent labels.I
remove lots compiler options
to make it more simple.But ffmpeg error is same.
I try also a simple testprog, but this produce diffrent and working Code.maybe
somebody with better optimizer knowledge can modify the testprog to produce
same code and use ftst.s d0
$ make
/bernd/ffmpeg/version.sh /bernd/ffmpeg version.h
m68k-elf-gcc -V4.5.0 -DHAVE_AV_CONFIG_H -I. -I/bernd/ffmpeg -D_ISOC99_SOURCE
-
D_POSIX_C_SOURCE=200112 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -S -m68020
-m
68881 -I/usr/local/amiga/m68k-amigaos/include -Wundef -O1-MMD -MF
libavc
odec/ratecontrol.d -MT libavcodec/ratecontrol.o -c -o libavcodec/ratecontrol.o
libavcodec/ratecontrol.c
thats the snippet from the asm file create with -S.
.LVL554:
fmove.s %d4,%fp1
fmul.x %fp1,%fp0
fmove.d %fp0,-(%sp)
move.l %a3,-(%sp)
move.l %a2,-(%sp)
.LCFI139:
jsr get_qscale
.LM656:
fmove.s %fp0,%d0
.LVL555:
.LM657:
lea (20,%sp),%sp
ftst.s %d0
fjlt .L319
.LM658:
fjlt .L310
fslt %d0
.LVL556:
here is snippet(amistuff upload) of m68k-amigaos with GCC 4.5.0 24. december
2009 and wrong code too
jsr _get_qscale
move.l d1,-(sp)
move.l d0,-(sp)
fmove.d (sp)+,fp0
fmove.s fp0,d0
lea (20,sp),sp
ftst.s d0
fjlt L315
fjlt L306
fslt d0
extb.l d0
neg.l d0
move.l d0,-(sp)
-
here is snippet(ami_stuff upload) with correct Code of m68k-amigaos GCC 4.5.0
24.december 2009
jsr _get_qscale
move.l d1,-(sp)
move.l d0,-(sp)
fmove.d (sp)+,fp0
fmove.s fp0,d0
lea (20,sp),sp
ftst.s d0
fjnlt L342
fmove.s #0xbf80,fp2
jra L307
L342:
ftst.s d0
fjgt L331
fslt d0
I now write a testprogram to reproduce the Bug.But GCC generate diffrent code
that work ok with both compilers
maybe somebody can tell how fake the optimizer to produce same code and do a
ftst.s d0 as in above Situation ?
#define assert(expression) \
((void) ((expression) ? 0 : __assert (expression, __FILE__, __LINE__)))
#define __assert(expression, file, line) \
(printf (%s:%u: failed assertion `%s'\n, file, line,expression),
\
abort(), 0)
double get_qscale(long *s, long *rce, double rate_factor, int frame_num)
{
return rate_factor*frame_num;
}
double get_diff_limited_q(long *s, long *rce, double q);
float ff_rate_estimate_qscale(double rate_factor, int picture_number)
{
long *s;
long *rce;
float q;
q= get_qscale(s, rce, rate_factor, picture_number);
if (q 0)
return -1;
assert(q0.0);
q = get_diff_limited_q(s, rce, q);
assert(q0.0);
}
int main(int argc, char **argv)
{
printf(%ld\n,ff_rate_estimate_qscale((float)argc,argc*4));
}
link.w %fp,#0
move.l 16(%fp),-(%sp)
move.l 12(%fp),-(%sp)
move.l 8(%fp),-(%sp)
clr.l -(%sp)
clr.l -(%sp)
jsr get_qscale
lea (20,%sp),%sp
fsmove.x %fp0,%fp0
fjnlt .L11
fmove.s #0xbf80,%fp0
jra .L2
.L11:
ftst.x %fp0
fjgt .L5
--
nospamname at web dot de changed:
What|Removed |Added
CC||nospamname at web dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41311
[Bug c/42595] New: Integer/Floating point casts between vector types generate
-- Summary: Integer/Floating point casts between vector types generate Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: adam at consulting dot net dot nz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42595
[Bug libstdc++/42593] [c++0x] [4.5 Regression] std::bind not assignable to std::function
-- redi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |redi at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-01-03 12:47:29 |2010-01-03 14:12:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42593
[Bug c/42596] New: Integer/Floating point vector casts generate XMM register moves from and to the same register
/*
GCC does not permit a vector of a union type.
To dynamically store both integer and float data in an XMM register define an
integer vector and cast to a float vector whenever a floating point operation
is required upon the data (or use a union to perform the type conversion).
Instead of treating these casts as a no-op GCC copies the register using a
floating point XMM move instruction, performs the calculation, then copies
the register back using an integer XMM move instruction.
*/
typedef double xmm_2f64_t __attribute__((vector_size (16)));
typedef long long xmm_2i64_t __attribute__((vector_size (16)));
register xmm_2f64_t xmm_a __asm__(xmm4);
register xmm_2f64_t xmm_b __asm__(xmm5);
register xmm_2i64_t xmm_c __asm__(xmm6);
register xmm_2i64_t xmm_d __asm__(xmm7);
typedef union {
xmm_2f64_t xmm_2f64;
xmm_2i64_t xmm_2i64;
} xmm_u;
//data type of xmm_e isnt suitable for a register
//register xmm_u xmm_e __asm__(xmm8);
typedef union {
long long i64;
double f64;
} r64_u;
//Note that the union above is suitable for a 64-bit register
register r64_u r64 __asm__(r15);
void test_fp_vectors_containing_fp_data() {
xmm_a+=xmm_b;
}
void test_int_vectors_containing_fp_data() {
xmm_c=(xmm_2i64_t) ((xmm_2f64_t) xmm_c + (xmm_2f64_t) xmm_d);
}
void test_int_vectors_containing_fp_data_using_a_union() {
xmm_u u_c, u_d;
u_c.xmm_2i64=xmm_c;
u_d.xmm_2i64=xmm_d;
u_c.xmm_2f64+=u_d.xmm_2f64;
xmm_c=u_c.xmm_2i64;
}
int main() {
}
Relevant code generation:
$ gcc -O3 dynamic_vectors.c objdump -d -m i386:x86-64:intel a.out |less
004004a0 test_fp_vectors_containing_fp_data:
4004a0: 66 0f 58 e5 addpd xmm4,xmm5
4004a4: c3 ret
4004a5: 66 66 2e 0f 1f 84 00nopWORD PTR cs:[rax+rax*1+0x0]
4004ac: 00 00 00 00
004004b0 test_int_vectors_containing_fp_data:
4004b0: 66 0f 28 c6 movapd xmm0,xmm6
4004b4: 66 0f 58 c7 addpd xmm0,xmm7
4004b8: 66 0f 6f f0 movdqa xmm6,xmm0
4004bc: c3 ret
4004bd: 0f 1f 00nopDWORD PTR [rax]
004004c0 test_int_vectors_containing_fp_data_using_a_union:
4004c0: 66 0f 28 c6 movapd xmm0,xmm6
4004c4: 66 0f 58 c7 addpd xmm0,xmm7
4004c8: 66 0f 6f f0 movdqa xmm6,xmm0
4004cc: c3 ret
4004cd: 0f 1f 00nopDWORD PTR [rax]
The last two functions should generate addpd xmm6,xmm7 instead of first copying
xmm6 to xmm0, performing the calculation, and then copying xmm6 back to xmm0.
--
Summary: Integer/Floating point vector casts generate XMM
register moves from and to the same register
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: adam at consulting dot net dot nz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42596
[Bug libstdc++/42593] [c++0x] [4.5 Regression] std::bind not assignable to std::function
--- Comment #2 from paolo dot carlini at oracle dot com 2010-01-03 14:26 --- Thanks. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC|jwakely dot gcc at gmail dot| |com | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42593
[Bug lto/42528] ICE with -flto and -fsigned-char
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-03 14:33 --- This is because va_list_type_node is char * on some targets and so pointer-to char types get globbed into it. But va_list_type_node is re-constructed as char * at IL read time and thus we read back unsigned char * as signed char *. Oops. I guess va_list_type_node better should be _not_ dependent on -f[un]signed-char. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42528
[Bug c/42595] Integer/Floating point casts between vector types generate
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-03 14:46 --- *** This bug has been marked as a duplicate of 42596 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE Summary|Integer/Floating point casts|Integer/Floating point casts |between vector types|between vector types |generate|generate http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42595
[Bug c/42596] Integer/Floating point vector casts generate XMM register moves from and to the same register
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-03 14:46 --- *** Bug 42595 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42596
[Bug c/42596] Integer/Floating point vector casts generate XMM register moves from and to the same register
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-03 14:50 --- Likely because you are using hardregs. Re-do the testcase with intrinsics please. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42596
[Bug libstdc++/42593] [c++0x] [4.5 Regression] std::bind not assignable to std::function
--- Comment #3 from redi at gcc dot gnu dot org 2010-01-03 15:07 --- From a quick look, I think the problem is that std::function now uses perfect forwarding, but std::bind doesn't yet. So invoking the function passes an rvalue to _Bind::operator() which fails to bind to _Args Previously, std::function took its arguments by value, and _Bind::operator()(_Args...) bound an lvalue reference to that by-value parameter: return _M_invoker(_M_functor, __args...); Now it does this: return _M_invoker(_M_functor, std::forward_ArgTypes(__args)...); and so the rvalue cannot bind to _Args This will be fixed when std::bind supports rvalue references. I was going to finish those changes after updating future, but I have been delayed by some unexpected events and am away from my home PC which contains my work in progress. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42593
[Bug libstdc++/42593] [c++0x] [4.5 Regression] std::bind not assignable to std::function
--- Comment #4 from paolo dot carlini at oracle dot com 2010-01-03 15:10 --- Ok, Jon, thanks. At some point, however, *soon* I'm afraid given the gcc4.5 schedule, we'll have to make a tough choice: if updating only std::function leads to bad regressions in common usages of std::bind, and the latter isn't ready in time for gcc4.5 for whatever reason, we can't ship something half halfway through, I think... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42593
[Bug rtl-optimization/42589] bswap optimization does not work for 32bit (but for 64bit) on 64bit registers
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-01-03 15:23 --- Subject: Bug 42589 Author: rguenth Date: Sun Jan 3 15:23:29 2010 New Revision: 155588 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155588 Log: 2010-01-03 Richard Guenther rguent...@suse.de PR tree-optimization/42589 * tree-ssa-math-opts.c (execute_optimize_bswap): Allow double-word expansion of bswap32. * gcc.target/i386/pr42589.c: New testcase. Added: trunk/gcc/testsuite/gcc.target/i386/pr42589.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-math-opts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42589
[Bug rtl-optimization/42589] bswap optimization does not work for 32bit (but for 64bit) on 64bit registers
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-01-03 15:24 --- 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=42589
[Bug bootstrap/42424] [4.5 Regression] in-tree GMP/MPFR/MPC bootstrap fails
--- Comment #6 from ghazi at gcc dot gnu dot org 2010-01-03 15:31 --- (In reply to comment #3) OK, I can reproduce the issue. The problem is that mpc isn't told where to find the gmp and mpfr libraries. [...] Except that on some targets, .libs is actually called _libs. I don't know how to deal with that. Ah, I think you're on the right track. I can't yet figure out why it won't reproduce for me. There must be some libgmp in my lib path but I can't find it ATM. Anyway, I have an idea for _libs and will try to fix it. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ghazi at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-01-02 19:53:42 |2010-01-03 15:31:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42424
[Bug rtl-optimization/42592] really bad register allocation for x86
--- Comment #2 from andi-gcc at firstfloor dot org 2010-01-03 15:40 --- An obvious improvement would be to use the non callee clobbered registers as temporal storage, instead of putting into registers that just get spilled again. I think one of the other compilers in the comparison did that but I can't find the example right now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42592
[Bug tree-optimization/42587] bswap not recognized for memory
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-03 16:01 --- SRA here again does somthing stupid: from bb 2: acpi_ut_track_stack_ptr (); in.value = value_1(D); D.1966_2 = in.bytes[3]; out.bytes[0] = D.1966_2; D.1967_3 = in.bytes[2]; out.bytes[1] = D.1967_3; D.1968_4 = in.bytes[1]; out.bytes[2] = D.1968_4; D.1969_5 = in.bytes[0]; out.bytes[3] = D.1969_5; D.1970_6 = out.value; return D.1970_6; it generates bb 2: acpi_ut_track_stack_ptr (); in.value = value_1(D); in$bytes$0_14 = in.bytes[0]; in$bytes$1_15 = in.bytes[1]; in$bytes$2_16 = in.bytes[2]; in$bytes$3_17 = in.bytes[3]; D.1966_2 = in$bytes$3_17; out.bytes[0] = D.1966_2; D.1967_3 = in$bytes$2_16; out.bytes[1] = D.1967_3; D.1968_4 = in$bytes$1_15; out.bytes[2] = D.1968_4; D.1969_5 = in$bytes$0_14; out.bytes[3] = D.1969_5; D.1970_6 = out.value; return D.1970_6; which isn't an improvement and just creates extra temporary registers. -- rguenth 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=42587
[Bug libstdc++/42593] [c++0x] [4.5 Regression] std::bind not assignable to std::function
--- Comment #5 from paolo dot carlini at oracle dot com 2010-01-03 16:03 --- Jon, I'm raising Priority and Severity not because the isssue per se is that deadly serious (after all the whole C++0x is experimental, nothing should be really critical about it), but because we want to make sure we don't forget when (soon) we'll branch and will be in Stage 4, close to the release, and we'll have to make the final decisions about functional. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Severity|normal |blocker Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42593
[Bug tree-optimization/42587] bswap not recognized for memory
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-03 16:26 ---
Similar example not handled by bswap recognition:
typedef unsigned char u8;
typedef unsigned int u32;
union __anonunion
{
u32 value;
u8 bytes[4];
};
u32
acpi_ut_dword_byte_swap (u32 value)
{
union __anonunion in;
in.value = value;
return (in.bytes[0] 8) | in.bytes[1]) 8) | in.bytes[2]) 8) |
in.bytes[3];
}
here we also hit the recursion depth of the bswap recognition. Not so with
typedef unsigned char u8;
typedef unsigned int u32;
union __anonunion
{
u32 value;
u8 bytes[4];
};
u32
acpi_ut_dword_byte_swap (u32 value)
{
union __anonunion in;
in.value = value;
return (((in.bytes[0] 8) | in.bytes[1]) 16) | ((in.bytes[2] 8) |
in.bytes[3]);
}
but we do not handle
# VUSE .MEM_18
in$bytes$2_25 = in.bytes[2];
as bases (we probably could and it woudldn't be too hard - harder for
the case with pointer arithmetic though). We end up trying with
in$bytes$2_25 as base. Here:
case BIT_IOR_EXPR:
source_expr1 = find_bswap_1 (rhs1_stmt, n1, limit - 1);
if (!source_expr1)
return NULL_TREE;
source_expr2 = find_bswap_1 (rhs2_stmt, n2, limit - 1);
if (source_expr1 != source_expr2
|| n1.size != n2.size)
return NULL_TREE;
we'd have to detect the source exprs common memory and adjust the
piecewise symbolic numbers and create a common source expr. The
idea would be to combine in.bytes[2] and in.bytes[3] to
V_C_E int (in.bytes). As said it's going to me more complicated
for accesses via pointers, *p, *(p+1), ...
Note that once we extend this for memory we can as well do piecewise
memory copy analysis and do store/load merging on the tree level.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42587
[Bug libstdc++/42593] [c++0x] [4.5 Regression] std::bind not assignable to std::function
--- Comment #6 from redi at gcc dot gnu dot org 2010-01-03 16:28 --- ok, understood - I'm looking at finishing the bind changes at the moment -- redi at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal Priority|P1 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42593
[Bug libstdc++/42593] [c++0x] [4.5 Regression] std::bind not assignable to std::function
--- Comment #7 from paolo dot carlini at oracle dot com 2010-01-03 16:34 --- Let's keep a P1 for now, we really don't want to forget. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Severity|normal |blocker Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42593
[Bug c/42199] A problem with -maltivec
--- Comment #2 from galtgendo at o2 dot pl 2010-01-03 16:46 --- Created an attachment (id=19452) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19452action=view) preprocessed sources Finally I've got a response in the Gentoo bug. Info: Using built-in specs. Target: powerpc-unknown-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.4.2/work/gcc-4.4.2/configure --prefix=/usr --bindir=/usr/powerpc-unknown-linux-gnu/gcc-bin/4.4.2 --includedir=/usr/lib/gcc/powerpc-unknown-linux-gnu/4.4.2/include --datadir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/4.4.2 --mandir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/4.4.2/man --infodir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/4.4.2/info --with-gxx-include-dir=/usr/lib/gcc/powerpc-unknown-linux-gnu/4.4.2/include/g++-v4 --host=powerpc-unknown-linux-gnu --build=powerpc-unknown-linux-gnu --enable-altivec --disable-fixed-point --with-ppl --with-cloog --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --enable-cld --with-python-dir=/share/gcc-data/powerpc-unknown-linux-gnu/4.4.2/python --disable-libgcj --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.4.2 p1.0' Thread model: posix gcc version 4.4.2 (Gentoo 4.4.2 p1.0) Command line: powerpc-unknown-linux-gnu-gcc \ -std=gnu99 -E -Os -mcpu=G4 -mtune=G4 -maltivec -mabi=altivec -Wall \ conftest.c -o conftest.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42199
[Bug rtl-optimization/42175] Slow compile and much memory use at -O1
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-01-03 16:52 --- Maybe Zdenek has an idea why RTL LIM is so slow. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42175
[Bug rtl-optimization/42175] Slow compile and much memory use at -O1
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-01-03 17:03 ---
Well, obviously it is because
templatetypename T
gmic gmic::parse(...)
{
...
while (positioncommand_line.size() !is_quit) {
loop body with 4000 lines of code (well, including lots of lines
with a few thousand chars, control flow, loops and function calls)
}
...
}
and DF never was good scaling to this kind of code. Maybe not considering
this outermost loop in LIM will fix the slowness... the limit is currently
1 basic-blocks, maybe a little large when considering non-innermost
loops.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42175
[Bug driver/41564] -fdump-tree-all for lto does not work as expected
--- Comment #19 from hjl at gcc dot gnu dot org 2010-01-03 17:03 --- Subject: Bug 41564 Author: hjl Date: Sun Jan 3 17:03:38 2010 New Revision: 155591 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155591 Log: Pass -dumpbase and -dumpdir to gcc for LTO gcc/ 2010-01-03 H.J. Lu hongjiu...@intel.com PR lto/41564 * common.opt: Add dumpdir. * gcc.c (cc1_options): Add -dumpbase %B only if -dumpbase isn't specified. (option_map): Add --dumpdir. * gcc.h (DEFAULT_WORD_SWITCH_TAKES_ARG): Add dumpdir. * lto-wrapper.c (run_gcc): Add -dumpbase and -dumpdir for -o. * opts.c (decode_options): Try dump_dir_name first if dump_base_name isn't an absolute path. (common_handle_option): Handle OPT_dumpdir. * toplev.c (dump_dir_name): New. (print_switch_values): Also ignore -dumpdir. * toplev.h (dump_dir_name): New. gcc/lto/ 2010-01-03 H.J. Lu hongjiu...@intel.com PR lto/41564 * lto.c (DUMPBASE_SUFFIX): New. (lto_execute_ltrans): Append a sequence number to -dumpbase for LTRANS. Modified: trunk/gcc/ChangeLog trunk/gcc/common.opt trunk/gcc/gcc.c trunk/gcc/gcc.h trunk/gcc/lto-wrapper.c trunk/gcc/lto/ChangeLog trunk/gcc/lto/lto.c trunk/gcc/opts.c trunk/gcc/toplev.c trunk/gcc/toplev.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41564
[Bug rtl-optimization/41862] [4.5 Regression] -fgcse-sm causes bootstrap comparison failures
--- Comment #12 from steven at gcc dot gnu dot org 2010-01-03 17:15 --- Re. comment #11: If I configure with --without-build-config on ia64-unknown-linux-gnu, with -fgcse-sm enabled, then the bootstrap completes successfully (all languages except ada). If I configure without the extra option, the bootstrap fails. You say that it might be just a compare-debug failure -- what does that mean and what can/should I do about it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41862
[Bug rtl-optimization/41862] [4.5 Regression] -fgcse-sm causes bootstrap comparison failures
--- Comment #13 from steven at gcc dot gnu dot org 2010-01-03 17:22 --- For traceability: http://gcc.gnu.org/ml/gcc-patches/2009-12/msg01114.html I somehow forgot to add the PR number to the commit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41862
[Bug lto/42528] ICE with -flto and -fsigned-char
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-03 17:31 ---
The same problem exists for builtin functions that return or take arguments
of type char *. They change signature according to -f[un]signed-char which
causes for example
FAIL: gcc.c-torture/execute/builtins/strcpy-chk.c compilation, -O2 -flto
(internal compiler error)
when running with -funsigned-char on x86:
char p[32] = ;
int main ()
{
if (__builtin___strcpy_chk (p + 1, vwxyz,
__builtin_object_size (p + 1, 0)) != p + 1)
__builtin_abort ();
return 0;
}
$ /obj/trunk-g/gcc/xgcc -B/obj/trunk-g/gcc/ strcpy-chk.3.i -O -flto
-funsigned-char
In file included from :0:0:
strcpy-chk.3.i: In function 'main':
strcpy-chk.3.i:2:5: error: non-trivial conversion at assignment
unnamed-unsigned:8 *
unnamed-signed:8 *
D.2023_3 = D.2027_5;
strcpy-chk.3.i:2:5: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42528
[Bug driver/41564] -fdump-tree-all for lto does not work as expected
--- Comment #20 from hjl dot tools at gmail dot com 2010-01-03 17:37 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41564
[Bug fortran/42597] New: ICE with procedure pointer initialized to null()
The attached code (which seems fine to me) produces an internal compiler error. gfortran -c pp.f90 -o pp.o f951: internal compiler error: in gfc_build_null_descriptor, at fortran/trans-array.c:372 gfortran --version GNU Fortran (GCC) 4.5.0 20091229 (experimental) module mod_a implicit none public :: p_fun private abstract interface pure function intf(x) result(y) real, intent(in) :: x(:,:) real :: y(size(x,1),size(x,1),size(x,2)) end function intf end interface !procedure(intf), pointer :: p_fun ! this works procedure(intf), pointer :: p_fun = null() end module mod_a -- Summary: ICE with procedure pointer initialized to null() Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mrestelli at gmail dot com GCC build triplet: GNU Fortran (GCC) 4.5.0 20091229 (experimental) GCC host triplet: Linux 2.6.27-gentoo-r8 x86_64 AMD Turion(tm) 64 Mobile Technolog http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42597
[Bug libstdc++/42593] [c++0x] [4.5 Regression] std::bind not assignable to std::function
--- Comment #8 from redi at gcc dot gnu dot org 2010-01-03 17:57 ---
Created an attachment (id=19453)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19453action=view)
preliminary patch
I'm testing this, which is not ready for checkin, but updates std::bind to
handle rvalues and fixes this bug.
As well as fixing the affected testcases (done but not included in this patch)
and fixing the formatting, the decaying behaviour from the resolution to LWG
817 needs to be implemented:
http://home.roadrunner.com/~hinnant/issue_review/lwg-active.html#817
I *think* the patch is correct, but testsuite/30_threads/call_once/39909.cc
fails due to a front-end bug:
/home/redi/src/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/functional:1179:67:
sorry, unimplemented: unable to determine the declared type of expression
'declvalstd::reference_wrapperInc ()()'
A workaround for this is to change call_once to use bindvoid() instead of
bind() i.e.
Index: include/std/mutex
===
--- include/std/mutex (revision 155587)
+++ include/std/mutex (working copy)
@@ -722,12 +722,12 @@ namespace std
call_once(once_flag __once, _Callable __f, _Args... __args)
{
#ifdef _GLIBCXX_HAVE_TLS
- auto __bound_functor = std::bind(__f, __args...);
+ auto __bound_functor = std::bindvoid(__f, __args...),
__once_callable = __bound_functor;
__once_call = __once_call_impldecltype(__bound_functor);
#else
unique_lockmutex __functor_lock(__get_once_mutex());
- __once_functor = std::bind(__f, __args...);
+ __once_functor = std::bindvoid(__f, __args...);
__set_once_functor_lock_ptr(__functor_lock);
#endif
(the ability to use this workaround was the main reason I fixed std::bindvoid
recently)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42593
[Bug libstdc++/42593] [c++0x] [4.5 Regression] std::bind not assignable to std::function
--- Comment #9 from paolo dot carlini at oracle dot com 2010-01-03 18:05 --- Great. Let's go ahead this way, then! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42593
[Bug libstdc++/42593] [c++0x] [4.5 Regression] std::bind not assignable to std::function
--- Comment #10 from redi at gcc dot gnu dot org 2010-01-03 18:07 --- OK P.S. (In reply to comment #8) (the ability to use this workaround was the main reason I fixed std::bindvoid recently) I think I've mentioned to Paolo in private mail that we could use bindR (specifically, bindvoid) in several places because doing so should reduce compile time, as it avoids using result_of and decltype to determine the return type. I haven't done so yet, because deducing the return type provides better testcases for std::bind while I'm still working on it. Once the work is complete, we should consider using bindR in mutex and future -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42593
[Bug libfortran/42420] libgfortran fails to open large files on MINGW32
--- Comment #8 from jb at gcc dot gnu dot org 2010-01-03 18:09 --- Subject: Bug 42420 Author: jb Date: Sun Jan 3 18:09:37 2010 New Revision: 155593 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155593 Log: PR libfortran/42420 Large file capable stat for MingW Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/unix.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42420
[Bug lto/42528] ICE with -flto and -fsigned-char
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-03 18:12 --- Which seems to be because of CCP which folds D.2023_3 = __builtin___strcpy_chk (p[1], vwxyz[0], 31); with unsigned LHS to D.2023_3 = (unnamed-signed:8 *) __builtin_memcpy (p[1], vwxyz[0], 6); which requires a temporary and thus exposes the mismatched types to the verifier (we don't verify function assignments). Which is also because lto1 doesn't understand -f[un]signed-char and always has flag_signed_char set to the target default because 1044 /* Share char_type_node with whatever would be the default for the target. 1045 char_type_node will be used for internal types such as 1046 va_list_type_node but will not be present in the lto stream. */ 1047 char_type_node 1048= DEFAULT_SIGNED_CHAR ? signed_char_type_node : unsigned_char_type_node; the comment is true, but still units with different setting of flag_signed_char will have different va_list_type_node and different function signatures for builtin string functions. Now the above together with LTO1 not recognizing -f[un]signed-char even breaks consistent but non-standard flag_signed_char setting. Whatever is more important ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42528
[Bug lto/42580] Missing command line option file causes ICE
--- Comment #4 from hjl dot tools at gmail dot com 2010-01-03 18:14 --- Really fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42580
[Bug java/42409] org.eclipse.jdt.internal.compiler.batch.GCCMain not found
--- Comment #2 from jlpoole at pon dot net 2010-01-03 18:21 --- Created an attachment (id=19454) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19454action=view) output under normal circumstances In this output, the compiler incorrectly looks for the ecj.jar under /usr/share/java (on my machine, there was no java directory under /usr/share), when it should have used the path /usr/local/gcj/usr/share/java where the ecj.jar file and other jar files had been properly placed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42409
[Bug lto/42528] ICE with -flto and -fsigned-char
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-01-03 18:21 --- Created an attachment (id=19455) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19455action=view) patch Patch I am going to test. Further testing appreciated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42528
[Bug java/42409] org.eclipse.jdt.internal.compiler.batch.GCCMain not found
--- Comment #3 from jlpoole at pon dot net 2010-01-03 18:23 --- Created an attachment (id=19456) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19456action=view) work-around output To overcome the misdirected path, I created a java directory under /usr/share and copied the /usr/local/gcj/usr/share/java files to /usr/share/java. I then successfully ran my command and the output is attached hereto. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42409
[Bug rtl-optimization/41862] [4.5 Regression] -fgcse-sm causes bootstrap comparison failures
--- Comment #14 from rguenth at gcc dot gnu dot org 2010-01-03 18:25 --- It means that gcse-sm generates different code with -g vs. -g0 which likely means that it is confused by the extra DEBUG_INSNs that appear with -g or that its generated code depends on things like insn uids. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41862
[Bug java/42409] org.eclipse.jdt.internal.compiler.batch.GCCMain not found
--- Comment #4 from jlpoole at pon dot net 2010-01-03 18:30 --- I think I found the problem: the compiler is using an incorrect path, e.g. /usr/share/java, to find the ecj.jar file and the other jar files, libgcj-4.5.0.jar libgcj-tools-4.5.0.jar, when it should have used /usr/local/gcj/usr/share/java. See line 172 in the attachment gcj_fails-looking_for_ecj_in_wrong_path.txt Recall, I had installed using the DESTDIR parameter: make DESTDIR=/usr/local/gcj install in order not to trash my Gentoo GCC built for my ARMv5t platform. My work-around was to copy the three jar files under the /usr/local/gcj/usr/share/java directory (where make install had placed them) to /usr/share/java. My work-around run is attached (gcj_ecj_moved.txt) to this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42409
[Bug java/42409] org.eclipse.jdt.internal.compiler.batch.GCCMain not found
--- Comment #5 from jlpoole at pon dot net 2010-01-03 18:43 --- Here's my configuration log: plug build # pwd /mnt/seagate2/download/gnu/build plug build # head config.log This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by configure, which was generated by GNU Autoconf 2.64. Invocation command line was $ ../trunk/configure --enable-languages=java ## - ## ## Platform. ## plug build # -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42409
[Bug java/42409] org.eclipse.jdt.internal.compiler.batch.GCCMain not found
--- Comment #6 from jakub at gcc dot gnu dot org 2010-01-03 18:55 --- That's just a misunderstanding what DESTDIR is. DESTDIR just says a directory where the / dir of installed files starts. It is used when you e.g. want to install everything into a temporary directory to package it up later (e.g. using tar, cpio, rpm, ...). If /usr/local/gcj/usr/* is where you want gcc to finally reside, you shouldn't use DESTDIR, but instead configure with --prefix /usr/local/gcj/usr. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42409
[Bug lto/42581] gcc -v doesn't work with lto
--- Comment #2 from hjl dot tools at gmail dot com 2010-01-03 19:16 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00116.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2010- ||01/msg00116.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42581
[Bug rtl-optimization/42175] Slow compile and much memory use at -O1
--- Comment #8 from rakdver at kam dot mff dot cuni dot cz 2010-01-03
19:37 ---
Subject: Re: Slow compile and much memory use
at -O1
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-01-03 17:03
---
Well, obviously it is because
templatetypename T
gmic gmic::parse(...)
{
...
while (positioncommand_line.size() !is_quit) {
loop body with 4000 lines of code (well, including lots of lines
with a few thousand chars, control flow, loops and function calls)
}
...
}
and DF never was good scaling to this kind of code. Maybe not considering
this outermost loop in LIM will fix the slowness... the limit is currently
1 basic-blocks, maybe a little large when considering non-innermost
loops.
1 bbs seems way too large -- even for innermost loops.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42175
[Bug java/41745] Segmentation fault when ecj.jar is run as a binary compiled by gcj
--- Comment #7 from andreast at gcc dot gnu dot org 2010-01-03 19:38
---
[tc:~] andreast% /usr/local/bin/gcj45 -o ecj
--main=org.eclipse.jdt.internal.compiler.batch.Main ecj.jar
[tc:~] andreast% vi HelloWorld.java
public class HelloWorld {
public static void main(String args[]) {
System.out.println(Hello World!);
}
}
[tc:~] andreast% setenv LD_LIBRARY_PATH /usr/local/lib/gcc45
[tc:~] andreast% ./ecj HelloWorld.java
[tc:~] andreast% gij45 HelloWorld
Hello World!
[tc:~] andreast% uname -ra
FreeBSD tc.andreas.nets 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r201405M: Sat Jan 2
22:32:53 CET 2010
andre...@tc.andreas.nets:/usr/obj/export/devel/fbsd/head/src/sys/TC i386
[tc:~] andreast% gcj45 -v
Using built-in specs.
Reading specs from
/usr/local/lib/gcc45/gcc/i386-portbld-freebsd9.0/4.5.0/../../../libgcj.spec
rename spec startfile to startfileorig
rename spec lib to liborig
COLLECT_GCC=gcj45
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc45/gcc/i386-portbld-freebsd9.0/4.5.0/lto-wrapper
Target: i386-portbld-freebsd9.0
Configured with: ./../gcc-4.5-20091231/configure --disable-nls
--libdir=/usr/local/lib/gcc45 --libexecdir=/usr/local/libexec/gcc45
--program-suffix=45 --with-as=/usr/local/bin/as --with-gmp=/usr/local
--with-gxx-include-dir=/usr/local/lib/gcc45/include/c++/
--with-libiconv-prefix=/usr/local --with-system-zlib --disable-rpath
--prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/gcc45
--build=i386-portbld-freebsd9.0
Thread model: posix
gcc version 4.5.0 20091231 (experimental) (GCC)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41745
[Bug middle-end/42577] [4.4 Regression] array bounds false positive with -O3, goes away with -O2
--- Comment #8 from matt at use dot net 2010-01-03 19:57 --- can this be backported to 4.4 as well so I can integrate it into our 4.4-based toolchain? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42577
[Bug rtl-optimization/41862] [4.5 Regression] -fgcse-sm causes bootstrap-debug comparison failures
--- Comment #15 from steven at gcc dot gnu dot org 2010-01-03 20:02 --- Created an attachment (id=19457) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19457action=view) Ignore all DEBUG_INSNs in store-motion.c With this patch I can complete a bootstrap on ia64-unknown-linux-gnu with -fgcse-sm. Can't tell whether the patch makes sense, though :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41862
[Bug target/36043] gcc reads 8 bytes for a struct of size 6 which leads to sigsegv
--- Comment #14 from matt at use dot net 2010-01-03 20:30 --- Still happening on 4.5.0 20091228 (and gcc 4.4.1) on Ubuntu 9.10/amd64). I found that it goes away in 3 separate instances when turning on -finline-functions. The last 2 instances of memory corruption I am running into are functions in vtables, which can't be inlined (and therefore work around this bug) until de-virtualization is eliminated. This seems like a pretty serious and common problem; is there any chance it will be fixed in 4.5? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043
[Bug libstdc++/42593] [c++0x] [4.5 Regression] std::bind not assignable to std::function
--- Comment #11 from paolo dot carlini at oracle dot com 2010-01-03 20:57 --- By the way, Jon, I don't think we should delay committing this work only because of DR 817, after all isn't even Ready... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42593
[Bug libstdc++/42593] [c++0x] [4.5 Regression] std::bind not assignable to std::function
--- Comment #12 from paolo dot carlini at oracle dot com 2010-01-03 21:02 --- ... if we have something rather satisfactory wrt all the other isses / testcases we are aware of in this area the sooner we commit the code, the better: I'm sure that Daniel can help testing it further on his code base: worst case, if after the branch point things look really bad, we revert the whole package for the release, luckily we are not talking about tons of code intertwined with the rest of the library. Only, we have to keep the eyes open the next few weeks. We can make it ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42593
[Bug lto/42598] New: -v/-m* don't work with plugin
Plugin never passes -v -mtune=xxx to lto-wrapper. -- Summary: -v/-m* don't work with plugin 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=42598
[Bug lto/42598] -v/-m* don't work with plugin
--- Comment #1 from hjl dot tools at gmail dot com 2010-01-03 21:50 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00119.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2010- ||01/msg00119.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42598
[Bug libstdc++/42593] [c++0x] [4.5 Regression] std::bind not assignable to std::function
--- Comment #13 from redi at gcc dot gnu dot org 2010-01-03 22:10 --- Created an attachment (id=19458) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19458action=view) updated patch this fixes the formatting in the previous patch, includes the call_once workaround, and updates the testsuite. This patch disables the volatile-qualified _Bind::operator() overloads with '#if 0' because I'm not smart enough to figure out how to support that. If those overloads are enabled then you get errors when trying to pass reference_wrapper or _Bind as an argument to _Bind::operator(). IMHO we can live without volatile support for 4.5 because I don't think it's a widely-used feature. As well as this bug, it fixes bug 35569 and its dup I want to do some more tests to be sure this is ready -- redi at gcc dot gnu dot org changed: What|Removed |Added Attachment #19453|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42593
[Bug lto/42598] -v/-m* don't work with plugin
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-03 22:29 --- *** This bug has been marked as a duplicate of 42520 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42598
[Bug driver/42520] lto1 does not see -march and -mtune options with -fuse-linker-plugin
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-01-03 22:29 --- *** Bug 42598 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42520
[Bug target/36043] gcc reads 8 bytes for a struct of size 6 which leads to sigsegv
--- Comment #15 from rguenth at gcc dot gnu dot org 2010-01-03 22:32 --- The issue is in a very twisted piece of GCC where the chances to break sth are bigger that to fix sth ;) And it isn't a regression, so it's not on too many peoples radar (nor does it seem to happen in practice and thus affect those who may be able to fix it). But, let's CC some more people ;) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rth at gcc dot gnu dot org Known to fail|4.1.2 4.3.3 4.4.0 |4.1.2 4.3.3 4.4.0 4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043
[Bug rtl-optimization/41862] [4.5 Regression] -fgcse-sm causes bootstrap-debug comparison failures
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-01-03 22:33 --- If it also passes testing it is ok for trunk (it does make sense to me). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41862
[Bug middle-end/42577] [4.4 Regression] array bounds false positive with -O3, goes away with -O2
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-01-03 22:33 --- The patch should apply more-or-less literally to the 4.4 branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42577
[Bug rtl-optimization/41862] [4.5 Regression] -fgcse-sm causes bootstrap-debug comparison failures
--- Comment #17 from steven at gcc dot gnu dot org 2010-01-03 22:41 --- Subject: Bug 41862 Author: steven Date: Sun Jan 3 22:41:22 2010 New Revision: 155596 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155596 Log: PR rtl-optimization/41862 * store-motion.c (store_killed_in_insn, compute_store_table, remove_reachable_equiv_notes, replace_store_insn, build_store_vectors): Ignore all DEBUG_INSNs. Modified: trunk/gcc/ChangeLog trunk/gcc/store-motion.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41862
[Bug testsuite/42583] [4.5 Regression] FAIL: gfortran.dg/gomp/recursion1.f90: gfortran: libgomp.spec: No such file or directory
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-01-03 22:45 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED 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
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-01-03 22:45 --- Subject: Bug 42583 Author: rguenth Date: Sun Jan 3 22:44:56 2010 New Revision: 155597 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155597 Log: 2010-01-03 Richard Guenther rguent...@suse.de PR testsuite/42583 * gfortran.dg/gomp/recursion1.f90: Remove. libgomp/ * testsuite/libgomp.fortran/recursion1.f90: New testcase. Added: trunk/libgomp/testsuite/libgomp.fortran/recursion1.f90 - copied unchanged from r155591, trunk/gcc/testsuite/gfortran.dg/gomp/recursion1.f90 Removed: trunk/gcc/testsuite/gfortran.dg/gomp/recursion1.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgomp/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42583
[Bug target/41605] Static linking of libgcc/libgfortran/libstdc++ can cause inconsistent symbol resolution.
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-01-03 22:45 --- Is this bug now fixed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41605
[Bug rtl-optimization/41862] [4.5 Regression] -fgcse-sm causes bootstrap-debug comparison failures
--- Comment #18 from steven at gcc dot gnu dot org 2010-01-03 22:46 --- Works for me now. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41862
[Bug tree-optimization/18219] [4.3/4.4 Regression] bloats code by 31%
--- Comment #30 from steven at gcc dot gnu dot org 2010-01-03 22:57 --- With the following compiler: $ ./xgcc --version xgcc (GCC) 4.5.0 20091228 (experimental) [trunk revision 155486] Copyright (C) 2009 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I get the following size with -m32 for the test case of comment #0: $ ./xgcc -B. -c t.c -m32 -Os -fno-ivopts -o tOsi.o $ ./xgcc -B. -c t.c -m32 -Os -o tOs.o $ size tOs* textdata bss dec hex filename 45 0 0 45 2d tOsi.o 42 0 0 42 2a tOs.o $ And I get the following size with -m64: $ ./xgcc -B. -c t.c -Os -o tOs.o $ ./xgcc -B. -c t.c -Os -fno-ivopts -o tOsi.o $ size tOs* textdata bss dec hex filename 78 0 0 78 4e tOsi.o 89 0 0 89 59 tOs.o $ This is, therefore, fixed on the trunk for GCC 4.5. -- steven at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.5.0 Summary|[4.3/4.4/4.5 Regression]|[4.3/4.4 Regression] bloats |bloats code by 31% |code by 31% http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18219
[Bug target/39725] [4.5 Regression][cond-optab] MIPS pessimizations on floating-point
--- Comment #1 from steven at gcc dot gnu dot org 2010-01-03 23:06 --- This bug needs TLC from a MIPS person. At least a confirmation would be nice. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39725
[Bug c/39959] [4.5 Regression] IMA is broken
--- Comment #16 from steven at gcc dot gnu dot org 2010-01-03 23:08 --- Can we close this bug as WONTFIX, and remove IMA for GCC 4.5? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39959
[Bug tree-optimization/18219] [4.3/4.4 Regression] bloats code by 31%
--- Comment #31 from rguenth at gcc dot gnu dot org 2010-01-03 23:14 --- Heh. I wonder how we can reliably add testcases for code size issues ... can we either dump size estimates or extract object .text section sizes? Ian may know arm people who I suspect would be interested in contributing infrastructure for this. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||iant at google dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18219
[Bug c++/40561] [4.3 Regression] code does not compile -- compiles fine when replacing != with !(==)
--- Comment #10 from mikpe at it dot uu dot se 2010-01-03 23:15 --- (In reply to comment #9) 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. This test case was fixed for 4.4 by r142961, the fix for PR38564. This test case fails with a recent 4.3, but r142961 applies cleanly and fixes the test case. I haven't done any testsuite runs on that combo yet, however. -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40561
[Bug c/42596] Integer/Floating point vector casts generate XMM register moves from and to the same register
--- Comment #3 from adam at consulting dot net dot nz 2010-01-03 23:20 --- This is a demo of poor code generation with XMM global register variables (hardregs) and the vector extensions. Intrinsics are too low level. The vector extensions can continue to work on a platform without x86 intrinsics (just replace register variable definitions with, e.g., __thread variable definitions on a foreign architecture). test_fp_vectors_containing_fp_data() indicates that code generation can be optimal with XMM global register variables+vector extensions. But only if the register variables are defined as the same type as the calculation. This is not a reasonable restriction for an XMM global register variable that has to contain integer and/or floating point data over the lifetime of a program. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42596
[Bug c/42599] New: arm-elf-gcc 4.4.2 internal compiler error in expand_expr_addr_1 at expr.c:6835
Host System: OS/X 10.6.2 Target System: arm7tdmi Compiler Configuration Options: jconradw:~ conr2286$ arm-elf-gcc --v Using built-in specs. Target: arm-elf Configured with: ../gcc-4.4.2/configure --target=arm-elf --prefix=/Users/mfischer/Projekte/development/yagarto/install --disable-nls --disable-shared --disable-threads --with-gcc --with-gnu-ld --with-gnu-as --with-dwarf2 --enable-languages=c,c++ --enable-interwork --enable-multilib --with-newlib --with-headers=../newlib-1.18.0/newlib/libc/include --disable-libssp --disable-libstdcxx-pch --disable-libmudflap --disable-libgomp -v Thread model: single gcc version 4.4.2 (GCC) Failing Command Line: /users/conr2286/yagarto/yagarto-4.4.2/bin/arm-elf-gcc -c -Wall -Wextra -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-align -Wsign-compare -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wunused -D RUN_MODE=RUN_FROM_ROM -D GCC_ARM7 -I/Users/conr2286/projects/LPC2148Demo -I/Users/conr2286/projects/LPC2148Demo/FreeRTOS/include -mcpu=arm7tdmi -Tlpc2148-rom.ld -g -O3 -fomit-frame-pointer -D CFG_CONSOLE_USB -D CFG_USB -D CFG_USB_SER -D CFG_I2C -D CFG_SPI -D CFG_RTC -D CFG_IAP -D CFG_WDT -D CFG_FIQ -D CFG_SWI -D CFG_PWM -D CFG_ABORT -D CFG_RAM_INTS -D CFG_MD -D CFG_MEM -D CFG_BEEP -D CFG_MISC -D CFG_LED -D CFG_GPS -D CFG_SENSORS -D CFG_LCD -D CFG_KBD -D CFG_FATFS -D CFG_UIP -D CFG_TELNETD -D CFG_HTTPD -D CFG_SNTP -D CFG_DHCP -D CFG_AT24C1024 -D CFG_LM75 -D CFG_M25LC512 -D CFG_INTONLY -save-temps rtcISR.c -o rtcISR.o Preprocessed File: rtcISR.i (to be attached) -- Summary: arm-elf-gcc 4.4.2 internal compiler error in expand_expr_addr_1 at expr.c:6835 Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: conr2286 at vandals dot uidaho dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42599
[Bug c/42599] arm-elf-gcc 4.4.2 internal compiler error in expand_expr_addr_1 at expr.c:6835
--- Comment #1 from conr2286 at vandals dot uidaho dot edu 2010-01-04 00:26 --- Created an attachment (id=19459) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19459action=view) Preprocessed rtcISR.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42599
[Bug libstdc++/42600] New: istream.eof() returns wrong value after reading bool
The following code prints true with 4.3.3, but false with 4.4.2 and
4.5-20091231. I think printing true is correct or am I missing something?
#include iostream
#include iomanip
#include sstream
int main()
{
bool result;
std::istringstream is( true );
is std::boolalpha result;
std::cout std::boolalpha is.eof() std::endl;
}
--
Summary: istream.eof() returns wrong value after reading bool
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: d dot frey at gmx dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42600
[Bug driver/42520] lto1 does not see -march and -mtune options with -fuse-linker-plugin
--- Comment #7 from hjl at gcc dot gnu dot org 2010-01-04 00:53 --- Subject: Bug 42520 Author: hjl Date: Mon Jan 4 00:52:50 2010 New Revision: 155601 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155601 Log: Pass -m* and -v to -plugin-opt gcc/ 2010-01-03 H.J. Lu hongjiu...@intel.com PR lto/42520 * gcc.c (LINK_COMMAND_SPEC): Pass -m* and -v to -plugin-opt. lto-plugin/ 2010-01-03 H.J. Lu hongjiu...@intel.com PR lto/42520 * lto-plugin.c (exec_lto_wrapper): Output lto-wrapper command if -v is passed. Modified: trunk/gcc/ChangeLog trunk/gcc/gcc.c trunk/lto-plugin/ChangeLog trunk/lto-plugin/lto-plugin.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42520
[Bug middle-end/42577] [4.4 Regression] array bounds false positive with -O3, goes away with -O2
--- Comment #10 from matt at use dot net 2010-01-04 01:04 --- what I mean to ask is: can this fix be committed to the 4.4 branch? I'd prefer to minimize the number of local patches we apply to our custom build. Thanks for the quick fix, by the way! :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42577
