Andreas Jaeger writes:
Andreas I'm not a build machinery expert - if anybody has a patch, I'll
happily test it,
Andreas I'm building on Linux/Powerpc64.
Andreas Adding the above line to rs6000/x-linux64 did not help me. Btw.
Andreas we would need it for other files - like gnat1 - as well,
Hello,
I am working on a research project in which I want to export a whole
syntax/semantic tree of a c++ program from the compiler. My current
solution is to use the -fdump-tree-all option and take the *.t00.tu
files (translation unit dump). I've hacked the gcc/tree-dump.c so the
exported graph
Hi Ho!
--- On Mon, 6/30/08, Mojmir Svoboda [EMAIL PROTECTED] wrote:
i have registered gcc mailing list as [EMAIL PROTECTED]
via web form,
but my client was sending the requests as
[EMAIL PROTECTED] when i fixed this
everything seems
to be working.
I am glad to hear that!
thanks for
Hello,
In following code, gcc (mainline version as well as previous versions)
produces wrong code without giving any warning regarding strict aliasing
violation.
~/work/trunk-x86/bin/gcc tst.c -O3 -o tst -Wstrict-aliasing=2
./tst
barrier1
Miscompilation
If I compile with
Bingfeng Mei wrote:
Hello,
In following code, gcc (mainline version as well as previous versions)
produces wrong code without giving any warning regarding strict aliasing
violation.
~/work/trunk-x86/bin/gcc tst.c -O3 -o tst -Wstrict-aliasing=2
./tst
barrier1
Miscompilation
If I
Bingfeng Mei wrote:
Sorry, I made a mistake. My local copy of mainline version (still 4.3.0
20080213) doesn't gave warning. I just updated my mainline GCC and it
does give warning now.
I think that you'll find the release 4.3 version does too.
While we try to ensure that gcc warns whenever
David Edelsohn [EMAIL PROTECTED] writes:
Andreas Jaeger writes:
Andreas I'm not a build machinery expert - if anybody has a patch, I'll
happily test it,
Andreas I'm building on Linux/Powerpc64.
Andreas Adding the above line to rs6000/x-linux64 did not help me. Btw.
Andreas we would need
Selon Andreas Jaeger [EMAIL PROTECTED]:
This gets me a bit further but I do get later a build failure in
configure:
checking for powerpc64-suse-linux-gnu-strip... strip
checking whether ln -s works... yes
checking for powerpc64-suse-linux-gnu-gcc... /abuild/aj/gcc-tst/./gcc/xgcc
[EMAIL PROTECTED] writes:
Selon Andreas Jaeger [EMAIL PROTECTED]:
This gets me a bit further but I do get later a build failure in
configure:
checking for powerpc64-suse-linux-gnu-strip... strip
checking whether ln -s works... yes
checking for powerpc64-suse-linux-gnu-gcc...
checking for suffix of object files... configure: error: in
`/abuild/aj/gcc-tst/powerpc64-suse-linux-gnu/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
This is the friendly way the GCC build process reports that the
David Edelsohn [EMAIL PROTECTED] writes:
checking for suffix of object files... configure: error: in
`/abuild/aj/gcc-tst/powerpc64-suse-linux-gnu/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
This is the friendly
Andreas Jaeger writes:
Andreas So, it means that --relax is not the right solution for the problem.
Andreas I'll continue with the STAGE1_CFLAG flag but if anybody else wants me
to
Andreas test something, please tell me,
Maybe Alan will have some insight about --relax not working.
Hi.
This mornings bootstrap failed on my Solaris machine due to the recent
introduction of the various C++ compatibility warnings. Here's the
snippet from the build log where things failed:
/export/home/arth/gnu/gcc-0630/./prev-gcc/xgcc
-B/export/home/arth/gnu/gcc-0630/./prev-gcc/
Hi,
When I encounter a FUNCTION_DECL, I want to access the node BIND_EXPR
where I can find the artificial declarations of the current functions
that the compiler adds. Following what the documentation says, I use the
macro DECL_SAVED_TREE which should point to the node BIND_EXPR (used as
Art Haas wrote:
The build also failed on my sparc-sun-solaris2.10 system.
The mmap()/munmap() calls in these functions are the cause of the
problem.
I have a fix in the queue. There are some more failures.
Stay tuned.
Andreas
Hello all,
in the MELT branch (I just committed rev 137290)
http://gcc.gnu.org/wiki/MiddleEndLispTranslator
I have the attached melt.texi file in gcc/doc/
and my gcc/doc/gccint.texi file contains
@include c-tree.texi
@include tree-ssa.texi
@include melt.texi
@include loop.texi
@include
On Mon, Jun 30, 2008 at 11:09:28PM +0200, Basile STARYNKEVITCH wrote:
/usr/src/Lang/basile-melt-gcc/gcc/doc//melt.texi:146: `Reference on MELT'
has no Up field (perhaps incorrect sectioning?).
You have to add it to the menu manually. Look at any of the other
included files for an example; the
On Mon, Jun 30, 2008 at 01:59:19PM -0700, David VomLehn wrote:
This sounds like really good stuff and, on first reading, it all seems to
make sense to me. My only real concern is documentation of these changes.
FWIW, I'll be posting our version of this project shortly, and it
includes an ABI
Snapshot gcc-4.1-20080630 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20080630/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Mon, Jun 30, 2008 at 11:04:43AM -0400, David Edelsohn wrote:
Andreas Jaeger writes:
Andreas So, it means that --relax is not the right solution for the problem.
Andreas I'll continue with the STAGE1_CFLAG flag but if anybody else wants
me to
Andreas test something, please tell me,
On Fri, Jun 27, 2008 at 03:52:22PM +0530, Mohamed Shafi wrote:
Hello all,
For the 16-bit target that i porting now to gcc 4.1.2 doesn't have any
branch instructions. It only has jump instructions. For comparison
operation it has this instruction:
if cond Rx Ry
execute this insn
So
I would like to see that GCC define a macro in the case it is being used to
compile a program. Currently there is a __GNUC__ macro defined by the GNU C
preprocessor CPP. That does not suit the need. As the CPP Manual says:
__GNUC__ is defined by all GNU compilers that use the C preprocessor.
--- Comment #1 from ubizjak at gmail dot com 2008-06-30 06:01 ---
These are aliases to real functions, but I guess they should also be listed in
gcc-4.3.0 section. Please send a patch to gcc-patches@ for discussion.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36669
--- Comment #2 from hjl dot tools at gmail dot com 2008-06-30 06:14 ---
(In reply to comment #1)
These are aliases to real functions, but I guess they should also be listed in
gcc-4.3.0 section. Please send a patch to gcc-patches@ for discussion.
I doubt anyone is using __float128
--- Comment #8 from jv244 at cam dot ac dot uk 2008-06-30 06:22 ---
(In reply to comment #6)
It looks like you run out of stack space during GC walk. You can check if so
by raising the stack limit with 'ulimit -s unlimited'.
current trunk (actually a few days old) doesn't fail
--- Comment #2 from aldot at gcc dot gnu dot org 2008-06-30 08:23 ---
CC'ing Vladimir.
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #3 from joseph at codesourcery dot com 2008-06-30 09:40 ---
Subject: Re: Wrong versioning for __float128
On Mon, 30 Jun 2008, hjl dot tools at gmail dot com wrote:
BTW, it turns out that gcc 4.3 has those __float128 functions in libgcc.a.
That means all __float128
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-06-30 09:51 ---
The problem is that the function x has the MALLOC flag. Why is this so? This
causes the use of the argument memory to be missed.
I see in generic trans-decl.c code
/* Get a basic decl for an external function.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-06-30 11:34 ---
HJ, why do you think they should be @@GCC_4.3.0? They got introduced with
2001-05-25 Richard Henderson [EMAIL PROTECTED]
* libgcc-std.ver: Export XFmode and TFmode versions of symbols.
--
rguenth at
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-06-30 11:36 ---
I guess this was honza. I see this as well on x86_64.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-06-30 11:40 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-06-30 11:40 ---
Subject: Bug 36671
Author: rguenth
Date: Mon Jun 30 11:39:53 2008
New Revision: 137271
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137271
Log:
2008-06-30 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #6 from irar at gcc dot gnu dot org 2008-06-30 11:44 ---
Subject: Bug 36648
Author: irar
Date: Mon Jun 30 11:43:55 2008
New Revision: 137272
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137272
Log:
PR tree-optimization/36648
* tree-vect-transform.c
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |irar at gcc dot gnu dot org
|dot org
--- Comment #5 from hjl dot tools at gmail dot com 2008-06-30 13:29 ---
(In reply to comment #4)
HJ, why do you think they should be @@GCC_4.3.0? They got introduced with
2001-05-25 Richard Henderson [EMAIL PROTECTED]
* libgcc-std.ver: Export XFmode and TFmode versions
--- Comment #6 from hjl dot tools at gmail dot com 2008-06-30 13:34 ---
(In reply to comment #3)
Subject: Re: Wrong versioning for __float128
On Mon, 30 Jun 2008, hjl dot tools at gmail dot com wrote:
BTW, it turns out that gcc 4.3 has those __float128 functions in libgcc.a.
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-06-30 13:35 ---
Ok, so if we already shipped the broken version we cannot do anything here
(WONTFIX), otherwise we can fix it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36669
--- Comment #8 from hjl dot tools at gmail dot com 2008-06-30 13:38 ---
(In reply to comment #7)
Ok, so if we already shipped the broken version we cannot do anything here
(WONTFIX), otherwise we can fix it.
That is my opinion.
BTW, I consider __float128 as experimental until we
--- Comment #9 from joseph at codesourcery dot com 2008-06-30 13:39 ---
Subject: Re: Wrong versioning for __float128
On Mon, 30 Jun 2008, hjl dot tools at gmail dot com wrote:
BTW, it turns out that gcc 4.3 has those __float128 functions in libgcc.a.
That means all __float128
If it's not a bug (the code run correctly), I suggest that the first warning
below should say can never be inlined because it uses va_list argument. But I
do not understand why an argument of type va_list forbid inlining (not observed
in previous version AFAIK) while I understand why ellipsis can
--- Comment #8 from dfranke at gcc dot gnu dot org 2008-06-30 14:17 ---
In PR35248, Richard wrote:
libgcc_s goes into slibdir which is set as
AC_ARG_WITH(slibdir,
[ --with-slibdir=DIR shared libraries in DIR [[LIBDIR]]],
slibdir=$with_slibdir,
if test
I'm having a failure on reading in a namelist in gfortran. The version
information is below:
bash-3.2$ gfortran -v
Using built-in specs.
Target: powerpc-apple-darwin9.3.0
Configured with: /var/tmp/gfortran-20080530/ibin/../gcc/configure
--prefix=/usr/local/gfortran --enable-languages=c,fortran
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-06-30 15:46 ---
The inlining is prohibited by the use of va_start, va_next and va_end, not
by merely passing around va_list.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from laurent dot deniau at cern dot ch 2008-06-30 16:01
---
Subject: Re: va_list argument breaks inlining (ambiguous warning).
rguenth at gcc dot gnu dot org wrote:
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-06-30 15:46
---
The inlining is
--- Comment #4 from jason dot hoos at syclo dot com 2008-06-30 16:32
---
(In reply to comment #1)
Fix:
Do not overload a function before and after a template class
using it.
Another workaround (if rearranging the definitions isn't feasible): before any
of the function
$ gcc -c p-c.adb
+===GNAT BUG DETECTED==+
| 4.4.0 20080630 (experimental) (x86_64-unknown-linux-gnu) Storage_Error heap
exhausted|
| Error detected at p-c.adb:1:1|
| Please submit a bug report; see http
--- Comment #10 from hjl dot tools at gmail dot com 2008-06-30 17:08
---
Joseph, my current patch:
http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01942.html
changes it to @@GCC_4.3.0 and adds
+%inherit GCC_4.4.0 GCC_4.3.0
+GCC_4.4.0 {
+}
to cc/libgcc-std.ver. I can also close it as
The GCC optimizer generates code that cause a segmentation violation in
snprintf if the lnstat command from iproute2 utilities is build with -O1 or
-O2.
System: Intel Core Duo (64 bit)
Version: gcc (GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu7)
Backtrace:
]$ gdb ./lnstat
GNU gdb 6.8-debian
Copyright (C)
--- Comment #1 from shemminger at vyatta dot com 2008-06-30 17:16 ---
Created an attachment (id=15834)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15834action=view)
Compiler tree for lnstat compile
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36679
--- Comment #11 from joseph at codesourcery dot com 2008-06-30 17:22
---
Subject: Re: Wrong versioning for __float128
On Mon, 30 Jun 2008, hjl dot tools at gmail dot com wrote:
Joseph, my current patch:
http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01942.html
changes it to
--- Comment #11 from dseketel at redhat dot com 2008-06-30 17:51 ---
Created an attachment (id=15835)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15835action=view)
better column number in error patch [1/2]
This is a rebase of the patch [1/2] against trunk from 2008-06-30.
--
--- Comment #12 from dseketel at redhat dot com 2008-06-30 17:52 ---
Created an attachment (id=15836)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15836action=view)
better column number in error patch [2/2]
This is a rebase of the patch [2/2] against trunk of 2008-06-30.
It has
--- Comment #2 from shemminger at vyatta dot com 2008-06-30 17:53 ---
The problem turned out to be an out of bounds array reference.
The number of fields (fps-num) was 71, and on 64 were allocated.
This caused out of bounds reference to corrupt stack variables. Since
stack variables
The code snippet below compiles on FCFLAGS=-O1 and FCFLAGS=-O2, but gives
an ICE on FCFLAGS=-O1 -fschedule-insns. The additional option is supposed to
be part of -O2, according to [1].
The problem seems to be target-related as I could not reproduce it on
i686-pc-linux-gnu.
Code is reduced, but
--- Comment #13 from dseketel at redhat dot com 2008-06-30 17:54 ---
@Jon Grant: thanks for cheering ! :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31754
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-06-30 17:56
---
This may have been fixed with a recent patch. I will check and report back
this evening.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-30 17:59 ---
No -fschedule-insns is not included for x86 because of register pressure.
See PR 27001 also. There are many others due to the RA being dumb.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #12 from hjl dot tools at gmail dot com 2008-06-30 18:30
---
Since config/i386/libgcc-x86_64-glibc.ver will be removed in
gcc 4.4 when __float128 is enabled for ia32, gcc 4.3 branch
will need a different patch if we want to fix it. Otherwise,
we can leave those symbols
--- Comment #13 from ian at airs dot com 2008-06-30 19:12 ---
The three symbols __gttf2, __lttf2, and __netf2 are part of the standard libgcc
interface at version GCC_3.0. The fact that they are not supported by all
instances of libgcc on all platforms seems to me to be irrelevant.
--- Comment #14 from joseph at codesourcery dot com 2008-06-30 19:30
---
Subject: Re: Wrong versioning for __float128
On Mon, 30 Jun 2008, ian at airs dot com wrote:
The three symbols __gttf2, __lttf2, and __netf2 are part of the standard
libgcc
interface at version GCC_3.0.
--- Comment #2 from mariah dot lenox at gmail dot com 2008-06-30 19:32
---
Fixed in gcc-4.4-20080627
--
mariah dot lenox at gmail dot com changed:
What|Removed |Added
--- Comment #15 from hjl dot tools at gmail dot com 2008-06-30 19:50
---
(In reply to comment #13)
The three symbols __gttf2, __lttf2, and __netf2 are part of the standard
libgcc
interface at version GCC_3.0. The fact that they are not supported by all
instances of libgcc on all
--- Comment #2 from jakub at gcc dot gnu dot org 2008-06-30 20:42 ---
Subject: Bug 36662
Author: jakub
Date: Mon Jun 30 20:41:29 2008
New Revision: 137287
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137287
Log:
PR c++/36662
* decl2.c
--- Comment #3 from jakub at gcc dot gnu dot org 2008-06-30 20:50 ---
Subject: Bug 36662
Author: jakub
Date: Mon Jun 30 20:49:51 2008
New Revision: 137289
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137289
Log:
PR c++/36662
* decl2.c
--- Comment #4 from jakub at gcc dot gnu dot org 2008-06-30 20:52 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
program test
logical(kind=1),parameter :: t=.true.,f=.false.
logical(kind=1),dimension(9) :: hexa,hexb
data hexa/f,f,t,t,f,f,f,t,f/,hexb/f,t,f,f,f,t,t,f,f/
isum=count(hexa(1:9).eqv.hexb(1:9))
print*, isum
end program
with gfortran from gcc 4.3.1 above code produces:
--- Comment #5 from hutchinsonandy at gcc dot gnu dot org 2008-06-30 22:39
---
Subject: Bug 36598
Author: hutchinsonandy
Date: Mon Jun 30 22:38:34 2008
New Revision: 137298
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137298
Log:
PR target/36598
* gcc.dg/memcpy-1.c: Mark test
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-06-30 23:50
---
Bug confirmed on trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36676
With r137251, this test passed. From r137253 onwards, this test fails as
follows:
Running /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gfortran.dg/dg.exp ...
FAIL: gfortran.dg/associated_1.f90 -O1 execution test
with gfortran.log saying:
PASS: gfortran.dg/associated_1.f90 -O1 (test for excess
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-07-01 00:51
---
Confirmed.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from hp at gcc dot gnu dot org 2008-07-01 01:34 ---
Created an attachment (id=15837)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15837action=view)
somewhat shrunk test-case, the last abort in the program being called, use -O1.
It's the if (.not.associated(a,
--- Comment #2 from hp at gcc dot gnu dot org 2008-07-01 01:36 ---
(In reply to comment #1)
mentioned line makes it fail.
Doh: makes it pass, of course.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36682
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-07-01 01:54 ---
*** This bug has been marked as a duplicate of 36671 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-07-01 01:54 ---
*** Bug 36682 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from ian at airs dot com 2008-07-01 03:31 ---
So the question is whether we should break programs compiled by 4.3.0 and 4.3.1
(acknowledging that there may not be any actual programs that break) in order
to use consistent version numbers?
1. What version should x86-64
--- Comment #17 from hjl dot tools at gmail dot com 2008-07-01 04:07
---
(In reply to comment #16)
So the question is whether we should break programs compiled by 4.3.0 and
4.3.1
(acknowledging that there may not be any actual programs that break) in order
to use consistent
Hello,
I do not have a login to submit a bug via bugzilla, so I use the
second method in http://gcc.gnu.org/bugs.html#where and attach all the
required info.
In short, compiling w/ g++-4.3
==
template class Comparable Comparable max (Comparable
Unconformable array operations are not being picked up in the following:
[EMAIL PROTECTED] Stoopid]$ cat badness.f90
program fred
implicit none
real,dimension(:,:),allocatable::A
real,dimension(5)::v
allocate(A(5,5))
A=5
v=5
A=A/spread(v,2,3)
write(*,*)A(1,:)
write(*,*)A(2,:)
write(*,*)A(3,:)
--- Comment #7 from irar at gcc dot gnu dot org 2008-07-01 05:32 ---
Subject: Bug 36648
Author: irar
Date: Tue Jul 1 05:31:55 2008
New Revision: 137308
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137308
Log:
PR tree-optimization/36648
* tree-vect-transform.c
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-07-01 05:43
---
Patch:
Index: list_read.c
===
--- list_read.c (revision 137236)
+++ list_read.c (working copy)
@@ -2922,8 +2922,8 @@ find_nml_name:
goto
82 matches
Mail list logo
