--- Comment #17 from geoffk at geoffk dot org 2008-02-13 07:50 ---
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 10:41 PM, hjl dot tools at gmail dot com wrote:
> --- Comment #16 from
--- Comment #16 from reichelt at gcc dot gnu dot org 2008-02-13 07:31
---
The ICE disappeared on the 4.2 branch. Probably due to
2008-02-12 Jason Merrill <[EMAIL PROTECTED]>
PR c++/33916
* Revert:
2006-10-17 Mark Mitchell <[EMAIL PROTECTED]>
PR c++/
--- Comment #9 from dominiq at lps dot ens dot fr 2008-02-13 07:10 ---
Subject: Re:
gfortran.fortran-torture/execute/intrinsic_set_exponent.f90 fails on Intel
Darwin9
> Can this be closed then?
I think so.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34141
--- Comment #17 from jason at gcc dot gnu dot org 2008-02-13 07:08 ---
Subject: Bug 34774
Author: jason
Date: Wed Feb 13 07:08:11 2008
New Revision: 132283
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132283
Log:
PR c++/34774
* pt.c (value_dependent_expression_
--- 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 #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
--
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 #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
--
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 #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 #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 #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 #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 #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
--- 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
--
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 #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 #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 #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 #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
#
--- 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
--- 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
---
--- 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
--
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
-
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 #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
--
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 #14 from rguenth at gcc dot gnu dot org 2008-02-12 23:19
---
It looks like simply deleting from dependent_type_p:
/* If there are no template parameters in scope, then there can't be
any dependent types. */
if (!processing_template_decl)
{
/* If we are n
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 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 #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 #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 #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 #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 #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 #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 #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 #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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
--- 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
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 #4 from manu at gcc dot gnu dot org 2008-02-12 14:25 ---
This bug is confirmed.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
CC
--- Comment #4 from jakub at gcc dot gnu dot org 2008-02-12 13:27 ---
Not doing SRA seems harder than just handling it, because the decision whether
SRA should be done and whether to use block copy is done on vars, which both
are scalarizable.
Testing following patch:
2008-02-12 Jakub J
--- Comment #36 from alexandre dot nunes at gmail dot com 2008-02-12 13:13
---
I think it's worth to note here the implications of the fix to PR31849.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
--- Comment #1 from jakub at gcc dot gnu dot org 2008-02-12 12:00 ---
But this one doesn't seem to be inlining related. Until vrp1 pass the var in
question (D.20903) has just one SSA_NAME (D.20903_14) in the whole function,
non-ab, initialized at the beginning of the loop and nothing be
--- Comment #32 from eyal at geomage dot com 2008-02-12 11:28 ---
(In reply to comment #31)
> > 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 l
1 - 100 of 110 matches
Mail list logo