--- Comment #5 from fw at deneb dot enyo dot de 2010-01-31 09:38 ---
Isn't this a wrong-code bug? Or is the information used for the diagnostic not
used by the optimizers?
--
fw at deneb dot enyo dot de changed:
What|Removed |Added
---
I just tried to compile the package kile-2.1beta2-3.19 with the GNU
C++ compiler version 4.5 snapshot 20100128 and the compiler seemed
to take a long time over the compilation.
It ran for over 20 minutes on an idle 2.7 GHz AMD Athlon without
finishing.
Preprocessed source code attached. Flags -g
--- Comment #1 from dcb314 at hotmail dot com 2010-01-31 10:56 ---
Created an attachment (id=19762)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19762&action=view)
gzipped C++ source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42911
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-01-31 11:17 ---
(In reply to comment #5)
> Isn't this a wrong-code bug? Or is the information used for the diagnostic
> not
> used by the optimizers?
The diagnostics are independent on the optimizers, the one diagnostic that
isn'
C1278 A local variable of a pure subprogram, or of a BLOCK construct within a
pure subprogram, shall not have the SAVE attribute.
However, the following is accepted:
pure subroutine foo()
block
integer, save :: i
integer :: j = 5
end block
end subroutine foo
Expected:
integer,
--- Comment #11 from cyberleo at cyberleo dot net 2010-01-31 11:21 ---
Created an attachment (id=19763)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19763&action=view)
Preprocessed source
Seems to exist on 8.0-RELEASE-p2, but only when -Os and certain -march are
used.
cc (GCC) 4
--- Comment #12 from steven at gcc dot gnu dot org 2010-01-31 11:31 ---
GCC 4.2 is no longer maintained, and the code that ICEs had been almost
completely rewritten. Does this also fail with newer compilers?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39193
--- Comment #5 from pault at gcc dot gnu dot org 2010-01-31 12:05 ---
Subject: Bug 38324
Author: pault
Date: Sun Jan 31 12:05:22 2010
New Revision: 156399
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156399
Log:
2010-01-31 Paul Thomas
PR fortran/38324
* exp
--- Comment #1 from domob at gcc dot gnu dot org 2010-01-31 12:21 ---
Mine.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-31 13:51 ---
I think it is related.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDep
--- Comment #6 from pault at gcc dot gnu dot org 2010-01-31 14:57 ---
Subject: Bug 38324
Author: pault
Date: Sun Jan 31 14:57:13 2010
New Revision: 156401
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156401
Log:
2010-01-31 Paul Thomas
PR fortran/38324
* exp
--- Comment #7 from pault at gcc dot gnu dot org 2010-01-31 15:00 ---
Fixed on trunk and 4.4
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from danglin at gcc dot gnu dot org 2010-01-31 16:32 ---
The failure was introduced by my change to the libgcc_s so version. With
the change, the array dwarf_reg_size_table is no longer initialized. It
appears that glibc has an implicit dependence on libgcc_s:
Breakpoin
See the TODO in trans-expr.c(gfc_trans_alloc_subarray_assign):
Quite a lot of correction has to be done to the bounds of array descriptors
produced by gfc_conv_expr_descriptor. These concern full array references of
variables and array references where conversion is applied implicitly. The fix
to
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirm
--- Comment #4 from carlos at systemhalted dot org 2010-01-31 16:54 ---
That is correct, all glibc targets must provide the current version if
libgcc_s.so. The NPTL implementation of pthread_cancel_init will dlopen that
current version of libgcc_s.so and use the unwinder implementation f
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-01-31 17:01 ---
Subject: Bug 42898
Author: rguenth
Date: Sun Jan 31 17:01:38 2010
New Revision: 156404
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156404
Log:
2010-01-31 Richard Guenther
PR middle-end/42898
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-01-31 17:04 ---
Subject: Bug 42898
Author: rguenth
Date: Sun Jan 31 17:04:29 2010
New Revision: 156405
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156405
Log:
2010-01-31 Richard Guenther
PR middle-end/42898
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-01-31 17:05 ---
(In reply to comment #3)
> The failure was introduced by my change to the libgcc_s so version.
I always wondered why we have to do this all the time for hppa... every
other target seems to get along fine without do
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-01-31 17:07
---
Subject: Bug 42898
Author: rguenth
Date: Sun Jan 31 17:07:16 2010
New Revision: 156407
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156407
Log:
2010-01-31 Richard Guenther
PR middle-end/42898
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-01-31 17:08
---
Fixed on the branches. Trunk is still broken because of SRA, reassigning to
Martin for that.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2010-01-31
17:23 ---
Subject: Re: [4.5 Regression] FAIL: g++.dg/abi/forced.C execution test
> (In reply to comment #3)
> > The failure was introduced by my change to the libgcc_s so version.
>
> I always wondered why we have
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2010-01-31
17:26 ---
Subject: Re: [4.5 Regression] FAIL: g++.dg/abi/forced.C execution test
> That is correct, all glibc targets must provide the current version if
> libgcc_s.so. The NPTL implementation of pthread_cancel_init
int find_sad_16x16(int *intra_mode)
{
int current_intra_sad_2,best_intra_sad2;
int M1[16][16],M0[4][4][4][4],M3[4],M4[4][4];
int i,j,k;
int ii,jj;
for (jj=0;jj<4;jj++)
for (ii=0;ii<4;ii++)
for (j=0;j<4;j++)
for (j=0;j<4;j++)
current_intra_sad_2 += abs(M0[i][ii
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42914
--- Comment #2 from zsojka at seznam dot cz 2010-01-31 18:08 ---
Created an attachment (id=19764)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19764&action=view)
different testcase
Fails at least with r155363, r155966, r156367
Command line:
gcc -O1 -fgraphite-identity -fcompare-
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P1 |P3
Target Milestone|--- |4.5.0
http://gcc
Command line:
gcc -c testcase.cpp
Tested revisions:
r156392 - crash
r156367 - crash
r156293 - OK
r156260 - OK
r154975 - OK (4.4)
Output:
$ /mnt/svn/gcc-trunk/binary-156367-lto/bin/gcc testcase.cpp -c
testcase.cpp:9:28: internal compiler error: same canonical type node for
different types A::B and
--- Comment #1 from zsojka at seznam dot cz 2010-01-31 19:16 ---
Created an attachment (id=19765)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19765&action=view)
reduced testcase
Command line:
g++ -c pr42915.cpp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42915
--- Comment #8 from danglin at gcc dot gnu dot org 2010-01-31 19:38 ---
Subject: Bug 42850
Author: danglin
Date: Sun Jan 31 19:37:52 2010
New Revision: 156410
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156410
Log:
PR target/42850
Revert:
2010-01-02 J
--- Comment #9 from danglin at gcc dot gnu dot org 2010-01-31 19:40 ---
Fixed.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|ICE: same canonical type|[4.5 Regression] ICE: same
|node for different type
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2010-01-31 20:01
---
Subject: Bug 42898
Author: ebotcazou
Date: Sun Jan 31 20:00:54 2010
New Revision: 156414
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156414
Log:
PR middle-end/42898
* gcc.dg/torture/pr
Command line:
gcc -O1 -funroll-loops -ftree-vectorize -fcompare-debug -m32 -c testcase.c
(-m32 is needed for x86_64)
Tested revisions:
r156367 - crash
r155363 - crash
r153685 - crash
Output:
$ /mnt/svn/gcc-trunk/binary-156367-lto/bin/gcc -O1 -funroll-loops
-ftree-vectorize -fcompare-debug -m32 -c
--- Comment #1 from zsojka at seznam dot cz 2010-01-31 20:32 ---
Created an attachment (id=19766)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19766&action=view)
reduced testcase
Command line:
gcc -O1 -funroll-loops -ftree-vectorize -fcompare-debug -m32 -c pr42916.c
--
http:
--- Comment #28 from matz at gcc dot gnu dot org 2010-01-31 20:34 ---
fejj: To see how your initial code is broken, I've transformed it a bit to
show you how it already is "miscompiled" with earlier compilers. I've manually
unrolled the loop, and hoisted the two malloc calls to the fron
--- Comment #2 from dodji at gcc dot gnu dot org 2010-01-31 20:35 ---
Confirmed on trunk.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|
--- Comment #2 from pault at gcc dot gnu dot org 2010-01-31 20:40 ---
I think that I know how to fix this one, so am assigning myself. I would
regard this as a "serious" bug.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
-
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|"-fcompare-debug failure" |[4.5 Regression] "-fcompare-
|with "-O1 -funroll-lo
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2010-01-31 21:06
---
Subject: Bug 42898
Author: ebotcazou
Date: Sun Jan 31 21:06:20 2010
New Revision: 156415
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156415
Log:
PR middle-end/42898
Backport from mainl
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2010-01-31 21:08
---
Subject: Bug 42898
Author: ebotcazou
Date: Sun Jan 31 21:08:15 2010
New Revision: 156416
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156416
Log:
2010-01-31 Eric Botcazou
PR middle-end/4289
Command line:
gcc -O1 -ftree-loop-linear -fcompare-debug -c testcase.c
(fails at all -O1, -O2 and -O3 levels)
Tested revisions:
r156367 - crash
r155833 - crash
r154830 - crash
r153685 - crash
Output:
$ /mnt/svn/gcc-trunk/binary-156367-lto/bin/gcc -O1 -ftree-loop-linear
testcase.c -fcompare-debug
--- Comment #1 from zsojka at seznam dot cz 2010-01-31 21:41 ---
Created an attachment (id=19767)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19767&action=view)
reduced testcase
Command line:
gcc -O1 -ftree-loop-linear -fcompare-debug -c pr42917.c
--
http://gcc.gnu.org/bugz
--- Comment #21 from janus at gcc dot gnu dot org 2010-01-31 21:56 ---
Subject: Bug 42888
Author: janus
Date: Sun Jan 31 21:56:02 2010
New Revision: 156418
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156418
Log:
gcc/fortran/
2010-01-31 Janus Weil
PR fortran/42888
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42917
--- Comment #22 from janus at gcc dot gnu dot org 2010-01-31 22:01 ---
Fixed with r156418. Thanks for the report!
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
-
Command line:
gcc -O2 -ftracer -fcompare-debug -c testcase.c
Tested revisions:
r156367 - crash
r155609 - crash
r154830 - crash
r153685 - crash
Output:
$ /mnt/svn/gcc-trunk/binary-156367-lto/bin/gcc -O2 -ftracer -fcompare-debug -c
testcase.c
gcc: testcase.c: -fcompare-debug failure (length)
--
--- Comment #1 from zsojka at seznam dot cz 2010-01-31 22:53 ---
Created an attachment (id=19768)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19768&action=view)
reduced testcase
Command line:
gcc -O2 -ftracer -fcompare-debug -c pr42918.c
--
http://gcc.gnu.org/bugzilla/show_
void foo(unsigned long long *x);
void testfunc2(unsigned long long a) { foo (&a); }
generates
testfunc2:
pushl %ebp
movl%esp, %ebp
subl$40, %esp
movl8(%ebp), %eax
movl%eax, -16(%ebp)
movl12(%ebp), %eax
movl%eax, -12
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-31 22:56 ---
It also causes us to use more stack.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-01-31 22:57 ---
Weird that 3.3 fails but 3.4 works ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from simon at pushface dot org 2010-01-31 22:58 ---
(In reply to comment #3)
> I'm not sure that deleting ../$(RTSDIR)/*.o before building common-tools will
> be OK in all circumstances, but it certainly works for a native Darwin build.
> The point is that by this stage a
In the following short program (preprocessed files will be attached), the
output is incorrect when compiled with
ppu-g++ -o bug -O3 bug.cpp -maltivec
I get the output:
0.00 1.00 2.00 3.00
0.00 0.00 0.00 7.00
0.00 0.00 0.00 30.00
0.00 0.00 0
--- Comment #1 from ryan dot sammartino at gmail dot com 2010-01-31 23:00
---
Created an attachment (id=19769)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19769&action=view)
Preprocessor output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42920
--- Comment #2 from ryan dot sammartino at gmail dot com 2010-01-31 23:01
---
Created an attachment (id=19770)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19770&action=view)
Assembler output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42920
--- Comment #3 from ryan dot sammartino at gmail dot com 2010-01-31 23:02
---
Gah... sorry for the incorrect summary, I got distracted while typing it. :(
It should say "... correct vec_or instructions".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42920
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-01-31 23:18 ---
Actually can you paste the output of ppu-g++? I think this has been fixed on
the trunk already. Also can you try 4.4 which has Cell support in it, though I
cannot remember when I submitted the Cell Altivec support.
--- Comment #5 from ryan dot sammartino at gmail dot com 2010-02-01 00:12
---
(In reply to comment #4)
> Actually can you paste the output of ppu-g++?
You mean -v, I hope:
$ ppu-g++ --v
Using built-in specs.
Target: ppu
Configured with: ../toolchain/gcc/configure --prefix=/usr/lib/c
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-02-01 00:15 ---
No I have fixed a couple of these bugs before, trust me. I will double check
the PS3 toolchain sources and see what happens in the PS3 toolchain. Note I am
leaving sony friday so I will make sure that I finish it b
--- Comment #3 from matz at gcc dot gnu dot org 2010-02-01 00:21 ---
3.4 had this as initial RTL:
(insn 3 2 4 (set (reg:DI 60)
(mem/f:DI (reg/f:SI 53 virtual-incoming-args) [2 a+0 S8 A32])) -1 (nil)
(expr_list:REG_EQUIV (mem/f:DI (reg/f:SI 53 virtual-incoming-args)
[2 a
--- Comment #2 from zsojka at seznam dot cz 2010-02-01 00:46 ---
Created an attachment (id=19771)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19771&action=view)
reduced testcase, better yet longer
This one doesn't need -m32, and fails with both -O1 and -O2
Command line:
gcc -O1
--- Comment #13 from cyberleo at cyberleo dot net 2010-02-01 01:39 ---
Alas, it would seem that, due to licensing issues, newer GCC versions are
unsupported for building the FreeBSD base system.
For note, I managed to get this section to compile with my chosen optimization
flags (-Os -m
--- Comment #15 from howarth at nitro dot med dot uc dot edu 2010-02-01
01:47 ---
The new gcc.dg/torture/pr42898.c fails on x86_64-apple-darwin10...
FAIL: gcc.dg/torture/pr42898.c -O1 scan-tree-dump-times optimized "\*ptr" 1
FAIL: gcc.dg/torture/pr42898.c -O2 scan-tree-dump-times o
d/gcc45-4.4.999-20100131/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc45-4.4.999-20100131/darwin_objdir/gcc/
/sw/src/fink.build/gcc45-4.4.999-20100131/gcc-4.5-20100131/gcc/testsuite/gcc.dg/torture/pr42898.c
-O1 -fdump-tree-optimized -S -o pr42898.s
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42898
--- Comment #17 from howarth at nitro dot med dot uc dot edu 2010-02-01
01:54 ---
Created an attachment (id=19773)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19773&action=view)
.optimized for gcc.dg/torture/pr42898.c -O1 on x86_64-apple-darwin10
--
http://gcc.gnu.org/bugz
--- Comment #4 from matz at gcc dot gnu dot org 2010-02-01 02:41 ---
Well, actually it depends. The code generated by 3.4 might theoretically
be slower, because it potentially uses a misaligned stack slot (incoming
stack with -m32 only 4 byte aligned). With -mpreferred-stack-boundary=2
--- Comment #5 from matz at gcc dot gnu dot org 2010-02-01 02:53 ---
He, Alan already conjectured this problem:
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01182.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42919
--- Comment #18 from matz at gcc dot gnu dot org 2010-02-01 03:13 ---
See comment #11
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42898
--- Comment #14 from kargl at gcc dot gnu dot org 2010-02-01 03:31 ---
(In reply to comment #13)
> Alas, it would seem that, due to licensing issues, newer GCC versions are
> unsupported for building the FreeBSD base system.
The above isn't exactly true. No one has stepped forward to i
ild/install --enable-languages=c
Thread model: posix
gcc version 4.5.0 20100131 (experimental) [trunk revision 156418] (GCC)
And in 4.4.1 from Ubuntu Karmic:
$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.1-4ubuntu9
Hi i want to analyze gcc source code for my project. any body can give em the
source code. If possible documentation for the code. Please give me the code
and doc pleasee
Regards
Dileep
--
View this message in context:
http://old.nabble.com/gcc-source-code-tp27399511p27399511.html
Sent f
71 matches
Mail list logo
