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
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
--- 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
--- 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 #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 #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 #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
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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
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 #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
--- 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 #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
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 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_
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 #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
-
--
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 #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
--- 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
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 #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
--- 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
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|"-fcompare-debug failure" |[4.5 Regression] "-fcompare-
|with "-O1 -funroll-lo
--- 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
-
--- 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 #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 #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:
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 #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
--
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 #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
--- 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 #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
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
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P1 |P3
Target Milestone|--- |4.5.0
http://gcc
--- 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-
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42914
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
--- 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
--- 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 #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 #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 #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 #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 #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 #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
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirm
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
--- 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
--- 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 #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 #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 #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 #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 #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 #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
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 #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'
--- 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
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 #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
---
71 matches
Mail list logo
