Jerry DeLisle wrote:
I tested the above on x86-64 Linux. OK to commit.
Thanks for the review. Committed:
Sendinggcc/fortran/ChangeLog
Sendinggcc/fortran/trans-decl.c
Transmitting file data ..
Committed revision 148035.
Tobias
Tobias Burnus wrote:
Jerry DeLisle wrote:
I tested the above on x86-64 Linux. OK to commit.
Thanks for the review. Committed:
Sendinggcc/fortran/ChangeLog
Sendinggcc/fortran/trans-decl.c
Transmitting file data ..
Committed revision 148035.
Tobias
Thank you both :)
Hi,
I'm seeing this error:
/Users/tobi/src/hggcc/build/./prev-gcc/xgcc
-B/Users/tobi/src/hggcc/build/./prev-gcc/
-B/usr/local/i386-apple-darwin8.11.1/bin/
-B/usr/local/i386-apple-darwin8.11.1/bin/
-B/usr/local/i386-apple-darwin8.11.1/lib/ -isystem
On Mon, 1 Jun 2009, Tobias Schlüter wrote:
The complaint is about:
ICONV_CONST char *inbuf = CONST_CAST (char *, ident);
[...snip...]
iconv_ret = iconv (cd, inbuf, inbytesleft,
outbuf, outbytesleft);
The types are exactly
Tobias Schlüter wrote:
cc1: warnings being treated as errors
../../gcc/pretty-print.c: In function 'identifier_to_locale':
../../gcc/pretty-print.c:1016: error: passing argument 2 of 'libiconv'
from incompatible pointer type
/sw/include/iconv.h:83: note: expected 'char **' but argument is of
Joseph S. Myers wrote:
On Mon, 1 Jun 2009, Tobias Schlüter wrote:
The complaint is about:
ICONV_CONST char *inbuf = CONST_CAST (char *, ident);
[...snip...]
iconv_ret = iconv (cd, inbuf, inbytesleft,
outbuf,
Ulrich Weigand schrieb:
Georg-Johann Lay wrote:
I'd like to support sibling calls for a target where function args can
be passed in call-saved registers, namely AVR.
The s390 back-end already has the very same issue. You may want to have
a look at
On Mon, Jun 01, 2009 at 12:07:56PM +0200, Tobias Schlüter wrote:
Hi,
I'm seeing this error:
/Users/tobi/src/hggcc/build/./prev-gcc/xgcc
-B/Users/tobi/src/hggcc/build/./prev-gcc/
-B/usr/local/i386-apple-darwin8.11.1/bin/
-B/usr/local/i386-apple-darwin8.11.1/bin/
Hi Jack,
Jack Howarth wrote:
You didn't show the configure options you used to build gcc trunk
against the fink libraries. You need at least...
--with-gmp=/sw --with-libiconv-prefix=/sw --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
Note that we don't set
I would conclude from the statistics that, right now, the cost of
including -fforward-propagate in -O1 overrides any performance benefit
that may result.
I'm still working on a patch to eliminate reaching definitions from fwprop.
Paolo
This is the beta release of binutils 2.19.51.0.7 for Linux, which is
based on binutils 2009 0601 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been
On i386-unknown-freebsd7.1 we see the following tests fail:
FAIL: libgomp.fortran/condinc2.f -O (test for excess errors)
WARNING: libgomp.fortran/condinc2.f -O compilation failed to produce
executable
FAIL: libgomp.fortran/condinc4.f90 -O (test for excess errors)
WARNING:
On Mon, Jun 01, 2009 at 07:59:15PM +0200, Gerald Pfeifer wrote:
Excess errors:
/pfeifer/OBJ-0531-2252/i386-unknown-freebsd7.1/./libgomp/.libs/libgomp.so:
undefined reference to `pthread_create'
And what all of these three testcases have in common is
{ dg-options -fno-openmp }
On Mon, 2009-06-01 at 11:14 -0700, Steve Kargl wrote:
On Mon, Jun 01, 2009 at 07:59:15PM +0200, Gerald Pfeifer wrote:
Excess errors:
/pfeifer/OBJ-0531-2252/i386-unknown-freebsd7.1/./libgomp/.libs/libgomp.so:
undefined reference to `pthread_create'
And what all of these three
On Mon, Jun 01, 2009 at 12:49:42PM -0700, Janis Johnson wrote:
On Mon, 2009-06-01 at 11:14 -0700, Steve Kargl wrote:
If someone uses -fno-openmp and still tries to link to libgomp,
then the -pthread option is missing and hence the test fail
because -lpthread is not included. On FreeBSD,
Nick, how is gcc --help supposed to work for options which are neither
warnings nor optimizations? For example, -fstack-protector. Is there a
--help option which will display it?
Ian
--- Comment #2 from ghazi at gcc dot gnu dot org 2009-06-01 06:02 ---
Remember to update the webpage:
http://gcc.gnu.org/gcc-4.5/changes.html
Add the MPC library dependency in the Caveats section, and add the benefits
of using MPC in the General Optimizer Improvements section.
--
Complex division by zero in gfortran returns NaN. This is expected for 0/0,
but other finite/zero should return Inf. This impacts the testcase
gfortran.dg/real_const_3.f90 in two values incorrectly computed:
complex :: z = (-0.1,-2.2)/(0.0,0.0)
complex :: z2 = (0.1,1)/0
See:
--- Comment #1 from kargl at gcc dot gnu dot org 2009-06-01 06:54 ---
(In reply to comment #0)
Complex division by zero in gfortran returns NaN. This is expected for 0/0,
but other finite/zero should return Inf. This impacts the testcase
gfortran.dg/real_const_3.f90 in two values
--- Comment #9 from burnus at gcc dot gnu dot org 2009-06-01 07:00 ---
Subject: Bug 40309
Author: burnus
Date: Mon Jun 1 07:00:35 2009
New Revision: 148035
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148035
Log:
2009-06-01 Tobias Burnus bur...@net-b.de
PR
--- Comment #10 from burnus at gcc dot gnu dot org 2009-06-01 07:34 ---
FIXED on the trunk (4.5).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from dave dot korn dot cygwin at gmail dot com 2009-06-01
08:05 ---
I checked the fix and it works. Verified.
--
dave dot korn dot cygwin at gmail dot com changed:
What|Removed |Added
--- Comment #8 from irar at gcc dot gnu dot org 2009-06-01 08:15 ---
Subject: Bug 39129
Author: irar
Date: Mon Jun 1 08:15:01 2009
New Revision: 148036
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148036
Log:
PR tree-optimization/39129
* tree-vect-loop-manip.c
--- Comment #9 from irar at il dot ibm dot com 2009-06-01 08:20 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|NEW
--- Comment #2 from ghazi at gcc dot gnu dot org 2009-06-01 08:35 ---
(In reply to comment #1)
Kaveh,
After looking into the problem, I think (nan + i nan) is
an acceptable result for z = (-0.1,-2.2)/(0.0,0.0)
because of the standard definition of complex division.
For z2 =
--- Comment #3 from dominiq at lps dot ens dot fr 2009-06-01 10:19 ---
In http://gcc.gnu.org/ml/fortran/2009-06/msg6.html, Dennis Wassel
wrote:
Complex numbers have a well-defined concept of infinity, which I like to
visualise as the infinite-diameter ring around the finite
--- Comment #15 from Woebbeking at web dot de 2009-06-01 10:28 ---
Ian, I know open source and I also know that some parts are more interesting
than others :-)
Most the time I'm a happy GCC user (sure, it could be faster but that's what
compile farms are for). But this bug is
--- Comment #4 from burnus at gcc dot gnu dot org 2009-06-01 11:09 ---
Regarding the run-time evaluation, note that Fortran sets (internally) the
-fcx-fortran-rules flag, which modifies the complex evaluation.
--
burnus at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from dominiq at lps dot ens dot fr 2009-06-01 11:24 ---
(In reply to comment #2)
Does fortran follow a standard here we can compare against
or are we guessing? :-)
What the fortran standard says is you shall not divide by zero! anything else
is just a matter of choice
--- Comment #6 from dennis dot wassel at googlemail dot com 2009-06-01
12:14 ---
(In reply to comment #3)
My understanding of infinity in the complex plane is what is called (I
call?) directed inifinity: if abs((a,b)) goes to +Inf and atan2(a,b) has
a defined value in this limit,
--- Comment #7 from dominiq at lps dot ens dot fr 2009-06-01 12:25 ---
Then this is the gist of the matter - my FA textbook does not require the
argument to converge, but just the modulus, so our understandings of infinity
differ.
Think of something like
$ cat foo.f
write (*,'(A1)') 65
end
$ gfortran -std=f95 -pedantic -Wall foo.f
$ ./a.out
A
$
We might want to permit this with -std=legacy, though. g77 also accepts it.
--
Summary: write (*,'(A1)') 65 should generate an error/warning
Product: gcc
Bootstrapping revision 148039 on i686-apple-darwin9 fails with:
/opt/gcc/i686-darwin/./prev-gcc/xgcc -B/opt/gcc/i686-darwin/./prev-gcc/
-B/opt/gcc/gcc4.5w/i686-apple-darwin9/bin/
-B/opt/gcc/gcc4.5w/i686-apple-darwin9/bin/
-B/opt/gcc/gcc4.5w/i686-apple-darwin9/lib/ -isystem
This is with GCC trunk, revision 148003:
...
[ 69%] Building CXX object
CMakeFiles/openlierox.dir/src/common/PhysicsLX56_Projectiles.o
[ 70%] Building CXX object CMakeFiles/openlierox.dir/src/common/HTTP.o
[ 70%] Building CXX object CMakeFiles/openlierox.dir/src/common/Networking.o
--- Comment #1 from dominiq at lps dot ens dot fr 2009-06-01 14:16 ---
See also Gcc [trunk revision 148039] failed to boostrap on i686! at
http://gcc.gnu.org/ml/gcc-regression/2009-06/msg7.html
and NEW GCC build failure, h...@148039 on native at
--- Comment #8 from jb at gcc dot gnu dot org 2009-06-01 14:21 ---
Whatever you do, as long as the Fortran standard is silent on this matter, can
you hide it behind some -fC99-wankery or such option and not enable it by
default, so that those of us who care less about which of (NaN,
--- Comment #2 from hjl dot tools at gmail dot com 2009-06-01 14:26 ---
Revision 148039:
http://gcc.gnu.org/ml/gcc-cvs/2009-06/msg00016.html
is the cause.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Severity|normal |blocker
Priority|P3 |P1
Target
--- Comment #1 from ich at az2000 dot de 2009-06-01 14:40 ---
Sorry, it was revision 148004.
I also tried with rev 148039, same error:
/home/az/Programmierung/openlierox/src/common/PhysicsLX56_Projectiles.cpp: In
function 'ProjCollisionType FinalWormCollisionCheck(CProjectile*, const
--- Comment #3 from hjl dot tools at gmail dot com 2009-06-01 14:43 ---
On Linux/ia32, I got
/export/gnu/import/svn/gcc-test/bld/./gcc/xgcc
-B/export/gnu/import/svn/gcc-test/bld/./gcc/
-B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/
-isystem
--- Comment #4 from mkuvyrkov at gcc dot gnu dot org 2009-06-01 14:50
---
I've reverted the patch that caused the bootstrap failure.
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ich at az2000 dot de 2009-06-01 14:50 ---
The specific file which fails has a lot of inline code, perhaps that is the
reason for failing. There are certain reasons why we want to have that inline.
This is the file if you want to take a look:
--- Comment #9 from sgk at troutmask dot apl dot washington dot edu
2009-06-01 14:56 ---
Subject: Re: Complex division by zero in gfortran returns wrong results
On Mon, Jun 01, 2009 at 08:35:05AM -, ghazi at gcc dot gnu dot org wrote:
--- Comment #2 from ghazi at gcc dot
--- Comment #3 from ich at az2000 dot de 2009-06-01 16:34 ---
I have commented out the check in tree-ssa-pre.c:2501, and then, after eating
up about 8GB memory (that was all available), I got this:
c++: Internal error: Killed (program cc1plus)
Please submit a full bug report.
See
In revision 148041:
...
make[2]: Verlasse Verzeichnis
'/home/az/Programmierung/gcc-trunk/build/libiberty'
rm -f *.a required-list tmpmulti.out
rm -f libiberty.dvi libiberty.pdf libiberty.info* libiberty.html
make[1]: Verlasse Verzeichnis
'/home/az/Programmierung/gcc-trunk/build/libiberty'
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #4 from ich at az2000 dot de 2009-06-01 16:52 ---
Created an attachment (id=17941)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17941action=view)
source file after preprocessor
I just created the temporary source file (via -save-temps) and attached it.
--
--- Comment #1 from jakub at gcc dot gnu dot org 2009-06-01 17:13 ---
Subject: Bug 40316
Author: jakub
Date: Mon Jun 1 17:13:04 2009
New Revision: 148055
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148055
Log:
PR middle-end/40316
* recog.c
--- Comment #2 from jakub at gcc dot gnu dot org 2009-06-01 17:15 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from burnus at gcc dot gnu dot org 2009-06-01 17:41 ---
If we can have a warning/error at compile time it would be great.
However, I'm inclined to allow it for -std=gnu at run time. (I'm personally
against too much standard diagnostics at run time. If such an error
--- Comment #3 from ghazi at gcc dot gnu dot org 2009-06-01 17:45 ---
Remember to upload the MPC tarball (whatever version we settle on) to:
ftp://gcc.gnu.org/pub/gcc/infrastructure/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40302
--- Comment #28 from pault at gcc dot gnu dot org 2009-06-01 18:00 ---
Created an attachment (id=17942)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17942action=view)
A progression of -fwhole-file
This patch is as far as I have got. It incorporates module procedures and this
is
--- Comment #5 from ich at az2000 dot de 2009-06-01 18:02 ---
Perhaps that was anyway clear from the report, but I didn't noted the most
important point directly: The problem occurs only with -O3. If I don't set a
specific optimisation, it works.
--
--- Comment #3 from jakub at gcc dot gnu dot org 2009-06-01 18:03 ---
Subject: Bug 40024
Author: jakub
Date: Mon Jun 1 18:03:26 2009
New Revision: 148061
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148061
Log:
PR other/40024
* emutls.c (__emutls_get_address):
--- Comment #10 from ghazi at gcc dot gnu dot org 2009-06-01 18:14 ---
(In reply to comment #9)
If MPC returns inf or (inf + i inf) and the MPC developers do not consider
this to be a bug in their library, then gfortran will need to handle the
division by zero during constant folding
This is with GCC trunk, rev 148041:
I have a cpp file where g++ just takes forever with 100% CPU usage and constant
(low) memory usage. I am waiting now for 20 minutes without any visible
progress.
I attached with GDB to the process and this is some of the details I am seeing:
a...@gcomputer:~$
--- Comment #1 from ich at az2000 dot de 2009-06-01 18:32 ---
gdb c
q
^C
Program received signal SIGINT, Interrupt.
___
Error while running hook_stop:
Value can't be converted to integer.
0x00780a0f in
--- Comment #2 from ich at az2000 dot de 2009-06-01 18:35 ---
This only happens with -O3. Without specific optimisation, it compiles just
fine. With all other GCC versions I have tried so far (GCC 4.4, GCC 4.3, GCC
4.0 and a lot others) it works fine (with any possible optimisation).
--- Comment #3 from ich at az2000 dot de 2009-06-01 18:36 ---
Created an attachment (id=17943)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17943action=view)
source file after preprocessor
This is the specific source after the preprocessor.
--
--- Comment #4 from simartin at gcc dot gnu dot org 2009-06-01 19:02
---
Patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00102.html
--
simartin at gcc dot gnu dot org changed:
What|Removed |Added
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
--- Comment #11 from sgk at troutmask dot apl dot washington dot edu
2009-06-01 19:16 ---
Subject: Re: Complex division by zero in gfortran returns wrong results
On Mon, Jun 01, 2009 at 06:14:52PM -, ghazi at gcc dot gnu dot org wrote:
- Comment #10 from ghazi at gcc dot
--- Comment #29 from jv244 at cam dot ac dot uk 2009-06-01 19:34 ---
(In reply to comment #28)
Created an attachment (id=17942)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17942action=view) [edit]
A progression of -fwhole-file
This patch is as far as I have got.
this seems
--- Comment #30 from jv244 at cam dot ac dot uk 2009-06-01 19:43 ---
Created an attachment (id=17944)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17944action=view)
testcase
attached is a testcase, this actually causes a segfault outside of the build
infrastructure, but consumes
--- Comment #8 from eduardo dot m dot costa at gmail dot com 2009-06-01
19:48 ---
(In reply to comment #7)
Subject: Re: [arm] libjava build failure due to missing
thread synchronization primitives
I'm not quite sure what you're trying to do.
What did you change to support
--- Comment #3 from gerald at pfeifer dot com 2009-06-01 20:32 ---
This has been fixed for GCC 4.2.0, I believe by the following patch:
2006-06-21 Frank Ch. Eigler f...@redhat.com
PR 21274
mf-runtime.h installation based on ssp patch for PR 26473 from
Mark
--- Comment #12 from burnus at gcc dot gnu dot org 2009-06-01 20:33 ---
Oh yuck. I just checked n1124.pdf In Annex G.5.1, it explicitly
defines this behavior:
Note: Annex G is only informative and not normative; still it makes probably
sense to follow the informative parts of a
This C program is compiled with no warning or error by mainline.
enum E { A };
void foo(unsigned int);
void (*pfn)(enum E) = foo;
My reading of ISO C says that these function pointers are not compatible types.
I think the compiler should report something like
warning: initialization from
--
gerald at pfeifer dot com changed:
What|Removed |Added
Target Milestone|3.1.x/3.2.x |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18244
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-06-01 20:40 ---
Actually I think they are compatible.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6024#c3 explains why they are.
The reason why they are compatible is explicitly explained in 6.7.2.2#4 (which
specifies that
--- Comment #4 from ich at az2000 dot de 2009-06-01 21:36 ---
It runs now for 200 minutes, so I really think this is not normal.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40323
--- Comment #4 from dje at gcc dot gnu dot org 2009-06-01 21:49 ---
Local variable debugging is broken for AIX stabs as well.
On AIX, the DECL and the insn contain different offsets from virtual-stack-vars
for the same variable:
(mem/c/i:SI (plus:SI (reg/f:SI 115 virtual-stack-vars)
--- Comment #5 from simartin at gcc dot gnu dot org 2009-06-02 05:37
---
Subject: Bug 38089
Author: simartin
Date: Tue Jun 2 05:37:17 2009
New Revision: 148069
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=148069
Log:
gcc/cp/
2009-06-02 Simon Martin
73 matches
Mail list logo
