--- Comment #12 from bangerth at dealii dot org 2008-02-12 08:17 ---
The following variant of the testcase in comment #8 is definitely
valid but produces an ICE:
-
template struct policy {
typedef int unnecessary;
};
template struct A {
typedef
--- Comment #30 from eyal at geomage dot com 2008-02-12 08:43 ---
Hi,
Thanks a lot for the input about a potential memory bottle-neck. I indeed was
under the impression that once I got the loop vectorized, I'd immidiatly see a
performance boost.
I would appriciate, however, a further
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2008-02-12 08:45
---
The failure mode is as follows: IVOPTS decices to turn the iteration on the
value of A (variable in the code) to an iteration on its address. But there
is a cast in the middle
a.0_4 = (system__aux_dec__TsaB) a
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2008-02-12 08:25
---
Investigating.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Assigne
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2008-02-12 09:08
---
> But maybe the problem is the discrepancy between force_gimple_operand and
> force_gimple_operand_bsi: why does the latter preserve the SSA form and not
> the former?
This would fix the problem:
Index: gimplify
--- Comment #10 from manu at gcc dot gnu dot org 2008-02-12 09:28 ---
Old unsupported GCC version, three years since last confirmed, sco... close?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from jakub at gcc dot gnu dot org 2008-02-12 09:46 ---
I suspect a reload bug, what asmcons is just unnecessary, not wrong.
Reload shouldn't ever reload different asm output registers into the same
hard registers.
That said, following patch serves as a workaround as well a
--- Comment #2 from manu at gcc dot gnu dot org 2008-02-12 10:09 ---
Confirmed.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #31 from victork at gcc dot gnu dot org 2008-02-12 10:51
---
> I would appriciate, however, a further explaination about this issue.
The explanation has to deal with CPU architecture and is not related to
compilers. In case of cache miss the memory load and store take tens
--- Comment #13 from dominiq at lps dot ens dot fr 2008-02-12 10:54 ---
The problem of conversion shows up even without -fdefault-integer-8 along with
bound problems as shown by the following code:
integer, parameter :: ik=4
type :: struct
integer(4), allocatable :: ib(:)
end type st
--- Comment #21 from Rudolf dot Leitgeb at gmx dot at 2008-02-12 18:27
---
This bug has come to surface again ... again I have to use --disable-libssp
when compiling gcc for the avr target, this time with gcc 4.2.3. Is ssp
essential for avr that it keeps creeping in ?
BTW: I use a sepa
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2008-02-12 20:50
---
Subject: Bug 35136
Author: ebotcazou
Date: Tue Feb 12 20:49:21 2008
New Revision: 132267
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132267
Log:
PR middle-end/35136
* gimplify.c (force
--- Comment #3 from skunk at iskunk dot org 2008-02-12 20:46 ---
(In reply to comment #2)
>
> I think it's a bug in makeinfo that it does this, and should be fixed
> there.
That was my first thought as well, but consider that the conversion from "--"
to "-" (and "---" to "--") makes s
--- Comment #3 from debian-gcc at lists dot debian dot org 2008-02-12
21:31 ---
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3-20080202-1'
--with-bugurl=file:///usr/share/doc/gcj-4.3/README.Bugs
--enable-languages=c,c++,java --prefix=/usr --enable-shared --with-syste
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-02-12 21:30 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-02-12 21:30 ---
Subject: Bug 35171
Author: rguenth
Date: Tue Feb 12 21:29:39 2008
New Revision: 132270
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132270
Log:
2008-02-12 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-02-12 21:30 ---
Fixed on the trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to w
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-02-12 21:27 ---
Subject: Bug 35163
Author: rguenth
Date: Tue Feb 12 21:26:49 2008
New Revision: 132269
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132269
Log:
2008-02-12 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #13 from geoffk at geoffk dot org 2008-02-12 22:43 ---
Subject: Re: [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal
compiler error: in expand_call, at calls.c:2785
On 12/02/2008, at 7:46 AM, hjl dot tools at gmail dot com wrote:
> --- Comment #10 from
--- Comment #4 from joseph at codesourcery dot com 2008-02-12 22:56 ---
Subject: Re: makeinfo drops hyphens from srcdir path
On Tue, 12 Feb 2008, skunk at iskunk dot org wrote:
> That was my first thought as well, but consider that the conversion from "--"
> to "-" (and "---" to "--")
--- Comment #10 from lennox at cs dot columbia dot edu 2008-02-12 22:46
---
The right answer is probably to declare the system header functions "inline"
when __GNUC_STDC_INLINE__, otherwise "extern inline"; or equivalently to
declare them "extern inline __attribute__((__gnu_inline__))".
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-02-12 22:45 ---
Reduced testcase without include:
typedef unsigned int size_t;
template class __normal_iterator {
public:
const _Iterator& base() const;
};
template inline
void copy_backward(_BI1 __first, _BI1 __last, _BI2 __resu
--- Comment #14 from hjl dot tools at gmail dot com 2008-02-12 23:45
---
(In reply to comment #13)
> > I think it is wrong to set STACK_BOUNDARY to 128 for 32bit since it is
> > hardware related, not ABI related. They should set
> > PREFERRED_STACK_BOUNDARY
> > instead, which is set
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-02-13 00:28 ---
(In reply to comment #0)
> This could be a dupe. Please add me on and close this one if it is.
When a bug is marked as a dup, it will add you automatically to the CC.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
This could be a dupe. Please add me on and close this one if it is.
powerpc-rtems4.9-gcc (GCC) 4.3.0 20080209 (experimental) [trunk revision
132202]
XFAIL: gcc.dg/vect/vect-63.c scan-tree-dump-times vect "vectorized 1 loops" 1
Executing on host: /home/joel/work-gnat/svn/b-gcc2-powerpc/gcc/xgcc
-
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-02-13 00:27 ---
*** Bug 35175 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
Executing on host: /home/joel/work-gnat/svn/b-gcc2-powerpc/gcc/xgcc
-B/home/joel/work-gnat/svn/b-gcc2-powerpc/gcc/
/home/joel/work-gnat/svn/gcc/gcc/testsuite/gcc.c-torture/execute/bf64-1.c
gcc_tg.o -w -O1 -DSTACK_SIZE=2048 -fno-show-column
-B/home/joel/work-gnat/svn/bsp-install/powerpc-rtems4.9/
--- Comment #4 from joel at gcc dot gnu dot org 2008-02-13 00:20 ---
Also fails on powerpc-rtems
powerpc-rtems4.9-gcc (GCC) 4.3.0 20080209 (experimental) [trunk revision
132202]
--
joel at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-13 03:15 ---
getrlimit and setrlimit are outside of standard C/C++, they are part of POSIX.
So it might be best to ask the POSIX guys.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35176
--- Comment #12 from lennox at cs dot columbia dot edu 2008-02-13 04:35
---
Created an attachment (id=15134)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15134&action=view)
test program using pointers to functions from emmintrin.h
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #9 from jason at gcc dot gnu dot org 2008-02-13 04:06 ---
Subject: Bug 34824
Author: jason
Date: Wed Feb 13 04:06:03 2008
New Revision: 132282
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132282
Log:
PR c++/34824
* call.c (convert_like_real): Pass L
--- Comment #13 from lennox at cs dot columbia dot edu 2008-02-13 04:38
---
Linking when the functions can't be inlined would be the only gotcha, but that
would mean that the new attachment (func-pointer-sse.c) would regress.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34000
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #10 from jason at gcc dot gnu dot org 2008-02-13 05:00 ---
Fixed for 4.3.0. Bugs on invalid code don't seem worth backporting.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from rakdver at kam dot mff dot cuni dot cz 2008-02-13
04:05 ---
Subject: Re: [4.3 regression] Unable to coalesce ab SSA_NAMEs
> Actually it is the call to rewrite_into_loop_closed_ssa inserting these
> PHIs. I don't know if it actually makes sense to speak of loop-clo
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #11 from mrs at apple dot com 2008-02-13 02:59 ---
Ok, how about:
#ifdef __GNUC_STDC_INLINE__
#define __EXTERN_INLINE __inline __attribute__((always_inline))
#else
#define __EXTERN_INLINE extern __inline __attribute__((always_inline))
#endif
__EXTERN_INLINE void foo() ;
__EX
When compiled with gcc 4.1.2 the program below dies with SIGXFSZ on Linux.
I don't think the standard allows filebuf to report errors using signals
(since it describes file I/O in terms of C stdio), nor does a signal seem
desirable in C++.
$ cat u.cpp && g++ u.cpp && ./a.out || echo $?
#include
#
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
Severity|blocker |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25035
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-02-12 23:13
---
Ok, so based on comment #12 this is ice-on-valid-code, and that testcase
"works" for me with 4.0 and 4.1 which produce:
g++-4.1 -S t.ii
t.ii: In instantiation of A:
t.ii:12: instantiated from S
t.ii:19: in
--- Comment #2 from manu at gcc dot gnu dot org 2008-02-12 22:38 ---
Please, try with the new -Wconversion (http://gcc.gnu.org/wiki/NewWconversion),
it shouldn't warn for values that fit (without changing sign) into the target
type.
Nevertheless, perhaps it may be interesting to make Wc
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-02-13 05:41
---
I have tried FX fix and it does the trick. I am regression testing. FX if you
can't get to it for 4.4, let me know and i will commit for you.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35009
--- Comment #7 from ghazi at gcc dot gnu dot org 2008-02-12 21:44 ---
Subject: Bug 34193
Author: ghazi
Date: Tue Feb 12 21:44:15 2008
New Revision: 132273
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132273
Log:
PR objc++/34193
* obj-c++.dg/gnu-runtime-2.mm: Fi
--- Comment #8 from lennox at cs dot columbia dot edu 2008-02-12 21:37
---
The attachment (inline-test-sse.c) on this PR is the gnu89 version of the
problem.
On MacOS X 10.5.2 (Apple gcc 5465), which has the same code as mainline FSF
GCC, it prints:
inline-test-sse.c: In function 'vec
--- Comment #9 from mrs at apple dot com 2008-02-12 22:04 ---
Ah, I see now, you're right, that doesn't work. :-(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34000
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-02-12 22:03 ---
Actually it is the call to rewrite_into_loop_closed_ssa inserting these
PHIs. I don't know if it actually makes sense to speak of loop-closed SSA form
if we deal with abnormal SSA names - Zdenek?
--
rguenth at g
--- Comment #6 from ghazi at gcc dot gnu dot org 2008-02-12 21:32 ---
Subject: Bug 34193
Author: ghazi
Date: Tue Feb 12 21:31:21 2008
New Revision: 132271
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132271
Log:
PR objc++/34193
* obj-c++.dg/gnu-runtime-2.mm: Fi
--- Comment #5 from ubizjak at gmail dot com 2008-02-12 21:11 ---
(In reply to comment #4)
> I see the same problem at any level of optimization I have tried on
> i686-apple-darwin9 for the test case gcc.target/i386/asm-3.c:
>
> [ibook-dhum] f90/bug% /opt/gcc/gcc4.3w/bin/gcc -O0
> /opt/
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-02-13 05:48
---
Thomas, I am going to work on this a bit. Let me know if you have already done
so.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from dominiq at lps dot ens dot fr 2008-02-12 20:18 ---
Fixed in OSX 10.5.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34141
--- Comment #9 from joseph at codesourcery dot com 2008-02-12 20:15 ---
Subject: Re: make pdf has missing file in 4.3-20080208
On Sun, 10 Feb 2008, Ralf dot Wildenhues at gmx dot de wrote:
> Thanks. Please note that I don't have write access yet (so if you want
> to make sure it gets
--- Comment #2 from joseph at codesourcery dot com 2008-02-12 20:11 ---
Subject: Re: makeinfo drops hyphens from srcdir path
I think it's a bug in makeinfo that it does this, and should be fixed
there.
In any case, patches to this code need testing with dvi or pdf output
(which need
--- Comment #1 from dfranke at gcc dot gnu dot org 2008-02-12 20:05 ---
*** Bug 35172 has been marked as a duplicate of this bug. ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-12 19:59 ---
I think -Wshorten-64-to-32 is bogus here. The values don't lose any
information, please fix your warning. Also you might want to try -Wconversion
in 4.3.0 and try again.
--
pinskia at gcc dot gnu dot org chang
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-02-12 19:59 ---
get_unwidened behaves as documented:
If FOR_TYPE is nonzero, we return a value which, if converted to
type FOR_TYPE, would be equivalent to converting OP to type FOR_TYPE.
thus indeed, (signed char)(int)(unsi
--- Comment #1 from skunk at iskunk dot org 2008-02-12 19:57 ---
Created an attachment (id=15133)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15133&action=view)
Patch against 4.2.3
Proposed fix. Set the srcdir variable using @verb{}, to prevent interpretation
of special characte
We have a warning -Wshorten-64-to-32 to catch porting to 64-bit machines which
warning when a 64 bit value is converted implicitly to a 32 bit value.
It causes:
/tmp/libstdcxx.roots/libstdcxx~dst/usr/include/c++/4.2.1/limits:379: warning:
implicit conversion shortens 64-bit value into a 32-bit va
--- Comment #15 from geoffk at geoffk dot org 2008-02-13 05:54 ---
Subject: Re: [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal
compiler error: in expand_call, at calls.c:2785
STACK_BOUNDARY
>>
> is more or less "natural" hardware stack boundary, which should be
> the s
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-12 19:41 ---
I don't know but I think the error is correct thing to do here. Someone will
have to look into the Fortran 2003 standard to make sure this is the correct
thing to do.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #6 from jason at gcc dot gnu dot org 2008-02-12 19:26 ---
Subject: Bug 29048
Author: jason
Date: Tue Feb 12 19:25:28 2008
New Revision: 132265
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132265
Log:
PR c++/29048
* semantics.c (finish_qualified_id_e
--- Comment #7 from jason at gcc dot gnu dot org 2008-02-12 19:28 ---
Fixed for 4.3.0, not worth fixing on earlier release branches.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #22 from eric dot weddington at atmel dot com 2008-02-12 19:38
---
Created an attachment (id=15132)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15132&action=view)
Patch to disable libssp for AVR target.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25035
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Known to fail||3.3.6
Problem mentioned by A. Markus with a valid interface corresponding to several
different FORTRAN signatures for a single C routine.
Unfortunately, gfortran reports an error. I think that this behavior is too
strong : a warning would be enough to point out a possible programming mistake.
Here this
--- Comment #12 from hjl dot tools at gmail dot com 2008-02-12 18:52
---
(In reply to comment #11)
> (In reply to comment #10)
>
> > I think it is wrong to set STACK_BOUNDARY to 128 for 32bit since it is
> > hardware related, not ABI related. They should set PREFERRED_STACK_BOUNDARY
>
--- Comment #11 from ubizjak at gmail dot com 2008-02-12 18:46 ---
(In reply to comment #10)
> I think it is wrong to set STACK_BOUNDARY to 128 for 32bit since it is
> hardware related, not ABI related. They should set PREFERRED_STACK_BOUNDARY
> instead, which is set to 128 already. On
--- Comment #6 from jakub at gcc dot gnu dot org 2008-02-12 18:38 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #9 from jakub at gcc dot gnu dot org 2008-02-12 18:38 ---
Workaround applied, though there is still some, pressumably local-alloc.c, bug
lurking around. Downgrading to P2, as this is no longer critical.
To reproduce revert the r132263 commit.
--
jakub at gcc dot gnu dot
--- Comment #5 from jakub at gcc dot gnu dot org 2008-02-12 18:35 ---
Subject: Bug 35144
Author: jakub
Date: Tue Feb 12 18:35:05 2008
New Revision: 132264
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132264
Log:
PR c++/35144
* tree-sra.c (sra_build_assignment):
--- Comment #8 from jakub at gcc dot gnu dot org 2008-02-12 18:32 ---
Subject: Bug 35160
Author: jakub
Date: Tue Feb 12 18:31:53 2008
New Revision: 132263
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132263
Log:
PR inline-asm/35160
* function.c (match_asm_const
--- Comment #7 from mrs at apple dot com 2008-02-12 18:01 ---
Testcase for comment #6? I believe we tested every case and it works fine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34000
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-13 00:27 ---
*** This bug has been marked as a duplicate of 34930 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from jakub at gcc dot gnu dot org 2008-02-12 20:14 ---
Posted 3 alternative patches:
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00410.html
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00418.html
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00422.html
--
jakub at gcc
--- Comment #2 from dfranke at gcc dot gnu dot org 2008-02-12 20:05 ---
*** This bug has been marked as a duplicate of 35161 ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from jakub at gcc dot gnu dot org 2008-02-12 17:27 ---
That's still twice as many global regs as register starved i386 can
realistically handle.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35135
--- Comment #5 from jason at gcc dot gnu dot org 2008-02-12 17:27 ---
Subject: Bug 29048
Author: jason
Date: Tue Feb 12 17:26:34 2008
New Revision: 132261
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132261
Log:
PR c++/29048
* semantics.c (finish_qualified_id_e
--- Comment #4 from mueller at gcc dot gnu dot org 2008-02-12 17:18 ---
new testcase:
-O2 -fno-gcse -fomit-frame-pointer
=== Cut ===
__extension__ typedef unsigned long long int uint64_t;
typedef unsigned int target_ulong;
register struct CPUX86State *env asm ("ebp");
register target_u
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-02-12 17:07 ---
I'll have a look.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedT
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-02-12 17:06 ---
I'll have a look.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedT
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-12 17:05 ---
Confirmed.
250 stmt_vinfo = vinfo_for_stmt (stmt);
251 gcc_assert (stmt_vinfo);
(gdb) call debug_generic_expr (stmt)
(void) 0
we run into a default def here. 4.2 works because we don't enable the
vect
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-02-13 06:09
---
The patch causes several regressions. hollerith.f90 for example.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35009
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net
|dot org
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2008-02-13 03:48
---
Can this be closed then?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34141
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2008-02-12 20:53
---
Thanks for reporting the problem.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-02-12 18:48 ---
The new testcase works for me with older releases (-O2 is enough), but 2.95.4
fails as well. The difference from 4.2 to 4.3 is that 4.2 uses two induction
variables, while 4.3 uses one. After lreg 4.2 has
(insn 21
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #3 from mueller at gcc dot gnu dot org 2008-02-12 16:31 ---
the original code uses -fomit-frame-pointer -fno-gcse -O2. I can verify that
-O3 fixes the issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35135
--- Comment #16 from hjl dot tools at gmail dot com 2008-02-13 06:41
---
(In reply to comment #15)
> Subject: Re: [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal
> compiler error: in expand_call, at calls.c:2785
>
> STACK_BOUNDARY
> >>
> > is more or less "natural" har
--- Comment #13 from jakub at gcc dot gnu dot org 2008-02-12 16:26 ---
Subject: Bug 34862
Author: jakub
Date: Tue Feb 12 16:25:47 2008
New Revision: 132257
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132257
Log:
PR c++/34862
* init.c (build_new_1): Don't creat
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2008-02-13 06:43
---
Something is wrong.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from hjl dot tools at gmail dot com 2008-02-12 15:46
---
(In reply to comment #3)
> Reproducible even with x86_64-linux -> i686-darwin9 cross, at -Os as well as
> -O2 -mno-accumulate-outgoing-args. The difference between i686-linux and
> i686-darwin9 that matters here i
--- Comment #9 from ubizjak at gmail dot com 2008-02-12 15:11 ---
By disabling asserts, we can compare -O2 call frame for va-arg-25.c test
vs. what would -Os call frame look like:
gcc -O2 -fomit-frame-pointer:
main:
subl$76, %esp
movdqa .LC0, %xmm0
movl
--- Comment #6 from rguenther at suse dot de 2008-02-12 15:03 ---
Subject: Re: [4.3 Regression] infinite loop while compiling
VLC media player in vt_find_locations
On Tue, 12 Feb 2008, zadeck at naturalbridge dot com wrote:
>
>
> --- Comment #5 from zadeck at naturalbridge dot
test.c:
...
int f(int a, int b, short c, int d, short e) {
int i;
for (i = 1; i <= 2 ; i++) {
c -= 4;
a = c;
d = d + (b?b:e);
}
return a + d;
}
...
...
$ cc1 -O3 test.c
...
test.c: In function 'f':
test.c:1: internal compiler error: in vect_recog_dot_prod_pattern, at
tree-vect-
--- Comment #23 from eric dot weddington at atmel dot com 2008-02-12 19:43
---
Since 4.x, libssp has had to be disabled for the AVR. Libssp is not required
for building the AVR. I've been meaning to reopen this bug report for a while.
Patch for disabling libssp for the AVR target is att
--- Comment #14 from jakub at gcc dot gnu dot org 2008-02-12 16:27 ---
Fixed. For 4.4 we should nuke CHANGE_DYNAMIC_TYPE_EXPR.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from matz at gcc dot gnu dot org 2008-02-12 16:06 ---
Actually the code in var-tracking.c does handle the situation that a reg
contains multiple decls. Or better it tries to. If there weren't an
obvious bug in clobber_variable_part(). With that fixed the looping doesn't
--- Comment #6 from lennox at cs dot columbia dot edu 2008-02-12 15:49
---
(In reply to comment #4)
The problem occurs equally with gnu89 "extern inline" functions as with c99
"inline" functions (as seen in the initial bug report), so using static inline
when !__GNUC_STDC_INLINE__ stil
--- Comment #7 from matz at gcc dot gnu dot org 2008-02-12 15:36 ---
The immediate problem is that the solution iterates between two orders.
On my machine (i686) it all happen around basic block 231. The even
iterations (after 128 iterations) the var-track info for bb 231 starts with:
--- Comment #5 from zadeck at naturalbridge dot com 2008-02-12 14:56
---
Richi,
I looked at this code once but I really do not know this code at all and really
do not want to learn it. It will take a fair amount of time to try to figure
out what the underlying dataflow problem is and
1 - 100 of 110 matches
Mail list logo
