--- Comment #20 from spark at gcc dot gnu dot org 2007-07-02 06:56 ---
We already put stack pointer in the exit block use set always.
However, after epilogue is generated, we see the sp restoration code:
1 NOTE_INSN_DELETED
4 NOTE_INSN_BASIC_BLOCK
22 [--sp:SI]=bp:SI
23 bp
--- Comment #1 from astrange at ithinksw dot com 2007-07-02 06:18 ---
This is a regression from Apple gcc 4.0:
Considering void image::set(size_t, size_t, f_pixel, f_real) with 29 insns
Estimated growth is -21 insns.
Inlined into void set_test(image*, int, int, f_pixel&, double) which
--- Comment #5 from patchapp at dberlin dot org 2007-07-02 06:12 ---
Subject: Bug number PR30940
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg02128.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #3 from dberlin at gcc dot gnu dot org 2007-07-02 04:35 ---
Subject: Bug 32571
Author: dberlin
Date: Mon Jul 2 04:35:37 2007
New Revision: 126186
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126186
Log:
2007-07-01 Daniel Berlin <[EMAIL PROTECTED]>
Fix P
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2007-07-02 04:11
---
Fixed on 4.3, will backport to 4.2 in about a week.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
---
When I use static inline attribute without any optimization as follows, stack
space is stacked. As a result, a stack overflow is caused. This problem came
from using gcc-4.2.0 for linux kernel which uses many inlines.
-compile options-
sh4-linux-gcc -S test.c
-testcase #1-
--- Comment #19 from ian at airs dot com 2007-07-02 02:50 ---
I don't see an inconsistency in my answers. If you mark local variables as
having a reference to the stack pointer before combine, then you should handle
log_links as appropriate.
I am explicitly not telling you what to do.
--- Comment #18 from zadeck at naturalbridge dot com 2007-07-02 02:45
---
Subject: Re: [4.3 Regression] function with asm()
does not setup stack frame
ian at airs dot com wrote:
> --- Comment #17 from ian at airs dot com 2007-07-02 01:45 ---
> Before I tackle the specific qu
--- Comment #17 from ian at airs dot com 2007-07-02 01:45 ---
Before I tackle the specific questions, let me try to explain the issue that I
see. The issue is that during a function the value of the stack pointer
register must always be at or below the local variables. An interrupt can
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-02 00:52 ---
Here is a more reduced testcase (without the inline-asm):
struct list_head {
struct list_head *next, *prev;
};
struct ib_fmr {
int *device;
struct list_head list;
};
static inline
struct mthca_fmr *to_mfmr(struct
--- Comment #16 from zadeck at naturalbridge dot com 2007-07-02 00:19
---
Subject: Re: [4.3 Regression] function with asm()
does not setup stack frame
Ian Lance Taylor wrote:
>> Adding the stack pointer for asms is certainly the easiest thing to do.
>>
>
> I don't know if that
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #2 from jojelino at gmail dot com 2007-07-01 23:06 ---
Created an attachment (id=13821)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13821&action=view)
preprocessed file #2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32576
--- Comment #1 from jojelino at gmail dot com 2007-07-01 23:04 ---
Created an attachment (id=13820)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13820&action=view)
preprocessed file #1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32576
svn revision: 126178
$ gcc adpcm.i -c -O1
In file included from adpcm.c:22:
avcodec.h:2252: warning: 'ImgReSampleContext' is deprecated
avcodec.h:2258: warning: 'ImgReSampleContext' is deprecated
adpcm.c: In function 'adpcm_decode_frame':
adpcm.c:854: internal compiler error: in set_ssa_val_to, at
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #2 from drh at sqlite dot org 2007-07-01 22:52 ---
(In reply to comment #1)
> Can you at least provide the preprocessed source of vdbe.c ?
>
Certainly. But before I do, I just noticed that I gave the
wrong GCC version number in the bug report. The error is
in GCC 4.2.0,
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||dberlin at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-01 22:16 ---
Can you at least provide the preprocessed source of vdbe.c ?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
A bug reported against SQLite appears to be a case of GCC 4.3.0
miscompiling a single line of code within SQLite. The problem only
appears with -O2 or -Os. The problem goes away if we add the
-fno-tree-vrp option. The original bug report can be found at
http://www.sqlite.org/cvstrac/tktview?
--- Comment #1 from marcus at jet dot franken dot de 2007-07-01 21:28
---
Created an attachment (id=13819)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13819&action=view)
storage.i
gcc -m32 -O2 -c storage.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32574
following .i files run the compiler out of memory during compile.
appeared in the last 2 days.
gcc -m32 -O2 -c storage.i
(note the -m32 on amd64 seems necessary strangely)
--
Summary: running out of memory during compiling
Product: gcc
Version: 4.3.0
--- Comment #1 from dcb314 at hotmail dot com 2007-07-01 21:07 ---
Created an attachment (id=13818)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13818&action=view)
C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32573
I just tried to compile Suse Linux package physfs-1.0.1 with the
GNU C compiler version 4.3 snapshot 20070629
The compiler said
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -O3 -g -fmessage-length=0
-D_FORTIFY_SOURCE=2 -D_REENTRANT -D_THREAD_SAFE -MT zip.lo -MD -MP -MF
.deps/zip.Tpo -c zip.c -fPIC -DP
--- Comment #10 from vmpn at hitechman dot com 2007-07-01 19:52 ---
Created an attachment (id=13817)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13817&action=view)
Test case that calls MyData visit_each without forward declaration
If the MydData visit_each is moved into the bugs
--- Comment #13 from rask at sygehus dot dk 2007-07-01 19:52 ---
This has regressed quite badly. Here's what we get with
-O2 -fomit-frame-pointer -m32 -march=pentium4:
fl:
movzbl %al, %eax # 21*zero_extendqisi2_movzbw[length
= 3]
movlx, %edx # 8
--- Comment #9 from vmpn at hitechman dot com 2007-07-01 19:44 ---
Created an attachment (id=13816)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13816&action=view)
Test case that does not call MyData visit_each (as expected)
Attaching a test case without forward declarations, tha
--- Comment #8 from vmpn at hitechman dot com 2007-07-01 19:38 ---
Created an attachment (id=13815)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13815&action=view)
Test case fixed using forward declarations
Thank you for your help. I think I now have a better understanding of wha
ltilib
--with-arch=pentium-m --with-tune=nocona --enable-target-optspace
--disable-bootstrap --with-gmp=/sw --with-system-zlib
--enable-languages=c,c++,objc,obj-c++
Thread model: posix
gcc version 4.3.0 20070701 (experimental)
> /usr/local/gcc43/bin/g++ -O3 -c -fdump-ipa-all -fdump-tree-final_clea
--- Comment #8 from patchapp at dberlin dot org 2007-07-01 17:56 ---
Subject: Bug number PR32014
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00031.html
--
http://gcc.gnu.org/bugzilla/sh
I usually download and build each week's snapshot of GCC 4.2 on Mac
OS X (10.4.10). I unpack just gcc-core-4.2, configure, and it builds
perfectly. This process has worked fine for months up until the
5/30/2007 snapshot.
Starting in June sometime this broke. It dies early on in libiberty
--- Comment #5 from jb at gcc dot gnu dot org 2007-07-01 16:24 ---
Subject: Bug 32239
Author: jb
Date: Sun Jul 1 16:24:38 2007
New Revision: 126175
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126175
Log:
gcc/fortran:
2007-07-01 Janne Blomqvist <[EMAIL PROTECTED]>
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2007-07-01 15:49
---
Subject: Bug 32554
Author: jvdelisle
Date: Sun Jul 1 15:49:37 2007
New Revision: 126174
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126174
Log:
2007-06-29 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2007-07-01 15:46
---
Subject: Bug 32554
Author: jvdelisle
Date: Sun Jul 1 15:46:33 2007
New Revision: 126173
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126173
Log:
2007-07-01 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #7 from ubizjak at gmail dot com 2007-07-01 15:46 ---
Well, the problem is, that we "forgot" to take into account false branch from
bb4 to bb6. In notation form the Comment #6, this branch has the condition !C4,
so the total condition for branch from bb4 leading to bb6 would
--- Comment #24 from zadeck at naturalbridge dot com 2007-07-01 14:45
---
Subject: Re: [4.3 Regression] MIPS: FAIL in gcc.dg/cleanup-[8|9|10|11].c
ian at airs dot com wrote:
> --- Comment #23 from ian at airs dot com 2007-06-30 17:57 ---
> The patch in comment #19 of PR 32437
--- Comment #6 from ubizjak at gmail dot com 2007-07-01 14:20 ---
In the tree-if-conv.c, there is a comment with the reference to PR23115, where
similar problems were addressed:
4) If pred B is dominated by pred A then use pred B's condition.
See PR23115. */
For attached
--- Comment #11 from ubizjak at gmail dot com 2007-07-01 13:40 ---
(In reply to comment #9)
>PR tree-optimization/23115
>* tree-if-conv.c (find_phi_replacement_condition): Check domninated_by
>relation.
This fix is not enough to solve problems described in Comme
--- Comment #2 from rakdver at gcc dot gnu dot org 2007-07-01 13:28 ---
(In reply to comment #1)
> On the mainline, we have ivtmp.33 going from 1 to 101 so it does not equal the
> same as what i is.
... and ivopts do this transformation because of my favourite hack -- md of
i386 claims
--- Comment #3 from irar at il dot ibm dot com 2007-07-01 13:21 ---
A fix to PR 32230 http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00018.html fixes
this one too.
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32477
--- Comment #4 from dorit at gcc dot gnu dot org 2007-07-01 12:48 ---
Looks like the data-dependence analysis is doing it's job (it figures out that
the dependence distance is 1), but the vectorizer is still not willing to
vectorize. Need to look into this.
--
http://gcc.gnu.org/bu
--- Comment #3 from dorit at gcc dot gnu dot org 2007-07-01 12:46 ---
Looks like a similar problem to PR32378:
(compute_affine_dependence
(stmt_a =
D.1398_74 = (*aa_73(D))[D.1397_72])
(stmt_b =
(*aa_73(D))[D.1393_68] = D.1408_88)
(subscript_dependence_tester
(analyze_overlapping_ite
--- Comment #2 from mstein at phenix dot rootshell dot be 2007-07-01 12:45
---
Created an attachment (id=13814)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13814&action=view)
preprocessed source file from linux-2.6.20, delta-reduced
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #5 from dorit at gcc dot gnu dot org 2007-07-01 12:43 ---
Dependence analysis now fails with a different message:
(compute_affine_dependence
(stmt_a =
D.1373_43 = (*a_42(D))[D.1372_41])
(stmt_b =
(*a_42(D))[D.1370_44] = D.1375_47)
(subscript_dependence_tester
(analyze_ov
--- Comment #1 from mstein at phenix dot rootshell dot be 2007-07-01 11:34
---
Created an attachment (id=13813)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13813&action=view)
preprocessed source file from linux-2.6.20, delta-reduced
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #3 from tbm at cyrius dot com 2007-07-01 11:33 ---
Created an attachment (id=13812)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13812&action=view)
dump file of -fdump-tree-vect-details
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32218
--- Comment #2 from tbm at cyrius dot com 2007-07-01 11:32 ---
(In reply to comment #1)
> Can someone with access to ia64 provide more detail? gdb backtrace? vectorizer
> dump file (with -fdump-tree-vect-details)? (can't reproduce it on powerpc and
> i386)
I'm afraid I still don't have
--- Comment #1 from dorit at gcc dot gnu dot org 2007-07-01 11:23 ---
(In reply to comment #0)
> I'm getting the following segfault on IA-64 with current 4.2 and 4.3.
> This goes back at least to 20060721 - I don't have anything older to
> test here at the moment. I don't see this segfa
Hello,
there seems to be a problem compiling the attached source file with
i686-pc-linux-gnu-gcc:
gcc -m32 -Wp,-MD,drivers/infiniband/hw/mthca/.mthca_provider.o.d -nostdinc
-isystem
/home/mstein/host-gcc/trunk-2007-07-01/bin/../lib/gcc/i686-pc-linux-gnu/4.3.0/include
-D__KERNEL__ -Iinclude -in
--- Comment #11 from patchapp at dberlin dot org 2007-07-01 11:15 ---
Subject: Bug number PR 32230
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00018.html
--
http://gcc.gnu.org/bugzilla/
--- Comment #3 from ubizjak at gmail dot com 2007-07-01 10:44 ---
This works for me on x86_64 host, producing correct code (with the flags above,
also with and without -m32, for all optimization levels. Also, this testcase
doesn't fail for x86 targets for a long time...
--
ubizjak at
--- Comment #3 from ubizjak at gmail dot com 2007-07-01 10:40 ---
Fixed in mainline SVN.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIG
--- Comment #2 from uros at gcc dot gnu dot org 2007-07-01 10:38 ---
Subject: Bug 32559
Author: uros
Date: Sun Jul 1 10:38:03 2007
New Revision: 126164
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126164
Log:
PR middle-end/32559
* fold-const.c (fold-binary) [P
--- Comment #7 from cavedon at sssup dot it 2007-07-01 10:37 ---
Created an attachment (id=13811)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13811&action=view)
Patch to test.cpp, working with gcc 4.1
Adding the declaration of "our template function" before the "default template
--- Comment #16 from ubizjak at gmail dot com 2007-07-01 10:32 ---
Closed, not marked as a regression.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #15 from uros at gcc dot gnu dot org 2007-07-01 10:30 ---
Subject: Bug 25371
Author: uros
Date: Sun Jul 1 10:30:31 2007
New Revision: 126163
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126163
Log:
PR tree-optimization/25371
* gcc.dg/vect/pr25371.c:
--- Comment #4 from dorit at gcc dot gnu dot org 2007-07-01 10:16 ---
Can anyone still see this failure, or can this PR be closed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27659
--- Comment #14 from dorit at gcc dot gnu dot org 2007-07-01 10:12 ---
> > So now that Zdenek's patch went in, can someone confirm if this problem
> > doesn't
> > occur anymore on x86_64?
> Compiles OK for original and reduced testcase (-O2 -ftree-vectorize) with:
> Target: x86_64-unkno
--- Comment #4 from dorit at gcc dot gnu dot org 2007-07-01 10:05 ---
Closed based on Ira's comment.
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rask at sygehus dot dk 2007-07-01 10:01 ---
Created an attachment (id=13810)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13810&action=view)
First attempt at a patch
The attached patch makes the v850 build on x86_64. There are a few regressions
(when run on i6
--- Comment #7 from dorit at gcc dot gnu dot org 2007-07-01 09:59 ---
I'm testing the following patch (seems to fix the two testcases in this PR on
Pentium4. still need to bootstrap etc, and check the powerpc bits)
Index: gcc/targhooks.c
=
--- Comment #13 from ubizjak at gmail dot com 2007-07-01 09:52 ---
(In reply to comment #12)
> > Subject: Re: -ftree-vectorize results in internal compiler error on AMD64
> > Zdenek's patch for cleaning the dataref analysis is also fixing this bug.
> > http://gcc.gnu.org/ml/gcc-patches/
--- Comment #8 from ubizjak at gmail dot com 2007-07-01 09:40 ---
(In reply to comment #6)
> Hm, in the dump (gcc-4.1.3), preceeding ifcvt, we have:
> Isn't marked statement unreachable?
The problem is in ifcvt pass, as confirmed by a c testcase in PR31966. This
problem is also present
--- Comment #1 from rask at sygehus dot dk 2007-07-01 09:37 ---
Additionally, the asm output has problems around the edges (seen in _pack_df):
mov 9218868437227405312,r14 # 395 *movdi_internal/1 [length
= 4]
mov 0,r15
--
rask at sygehus dot dk changed:
--- Comment #5 from ubizjak at gmail dot com 2007-07-01 09:33 ---
Confirmed. This is the same bug as PR32533, but this one comes with the c
testcase. The problem is in ifcvt pass.
In -march=nocona case (-march=nocona -O2 -ftree-vectorize), we have following
code before ifcvt pass:
if
--- Comment #12 from dorit at il dot ibm dot com 2007-07-01 09:30 ---
> Subject: Re: -ftree-vectorize results in internal compiler error on AMD64
> Zdenek's patch for cleaning the dataref analysis is also fixing this bug.
> http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00634.html
So now
--- Comment #4 from trog24 at comcast dot net 2007-07-01 09:22 ---
Subject: Re: [4.3 Regression] internal compiler error: in vn_lookup, at
tree-vn.c:290
Thank you.
Frank
On Jul 1, 2007, at 2:21 AM, pinskia at gcc dot gnu dot org wrote:
>
>
> --- Comment #3 from pinskia at gcc dot
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-07-01 09:21 ---
>I did the svn this morning (PDT). Do I need to do another svn?
Yes, it was modified at "2007-06-30 19:20:06 -0700". So 7:20 pm PDT :).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32568
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-07-01 09:13 ---
>The test runs differently when compiled with g++-3.4.6 (GCC) 3.4.6 (Gentoo
>3.4.6-r2, ssp-3.4.6-1.0,
> pie-8.7.10) and g++-4.1.2 (GCC) 4.1.2 (Gentoo 4.1.2) versions of the GCC
Yes and 4.1.x result is the correct
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-01 08:52 ---
>/root/downloads/gcc-4_3-trunk/gcc/toplev.c:558: Error: There is a definition
already for floor_log2
This is because floor_log2 uses the GNU C "extern inline".
>/gcc-4_3-trunk/gcc/config/i386/i386.c:4121: warning:
--- Comment #4 from dorit at gcc dot gnu dot org 2007-07-01 08:52 ---
This may be related to PR32533 (also wrong-code due to tree-if-conversion).
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from dorit at gcc dot gnu dot org 2007-07-01 08:51 ---
PR31966 is also wrong code which seems to be a result of the tree-level
if-conversion (nothing gets vectorized these, and if tree-if-conversion is
disabled everything works ok).
--
http://gcc.gnu.org/bugzilla/show
--- Comment #3 from dorit at gcc dot gnu dot org 2007-07-01 08:47 ---
I was able to reproduce the behavior on a Pentinum4 with a recent 4.3 snapshot.
It doesn't look like it's the vectorizer's fault - nothing gets vectorized.
However, if I disable the tree-level if-conversion (which is a
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-01 08:43 ---
This is not how you are supposed to compare testsuite log files.
Use contrib/compare_tests to compare the .sum files.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |
--- Comment #2 from dorit at gcc dot gnu dot org 2007-07-01 08:42 ---
(oops - wrong keyword)
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
Keywor
--- Comment #5 from dorit at gcc dot gnu dot org 2007-07-01 08:38 ---
This fix was committed with the wrong PR number (sorry about that):
2007-02-19 Dorit Nuzman <[EMAIL PROTECTED]>
PR tree-optimization/30975
* tree-vect-trasnform.c (vect_get_vec_def_for_stmt_copy): R
--- Comment #12 from dorit at gcc dot gnu dot org 2007-07-01 08:35 ---
A fix was committed, looks like the patch can be closed.
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #13 from dorit at gcc dot gnu dot org 2007-07-01 08:32 ---
Fix committed, PR can be closed.
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
78 matches
Mail list logo
