Hi,
I'm trying to build a cross-compiler from GCC 4.2.0 source. I've
built the binutils as cross tools and launched the configure script
for gcc source as follows:
[gcc-source]/configure --build=i686-pc-linux-gnu
--host=i686-pc-linux-gnu --target=arm-elf --prefix=[toolchain-prefix]
On Thu, 2007-08-30 at 10:05 +1000, Jonathan Adamczewski wrote:
I don't have gcc-4.2 handy - does changing this to a const reference
solve the problem? i.e
templatetypename Op
void foo(const Op op) { op(); }
Thanks for the suggestion, it doesn't help:
test.cpp: In member function 'void
I am pleased to announce that the GCC Steering Committee has
appointed Krister Walfridsson as NetBSD OS port maintainer.
Please join me in congratulating Krister on his new role.
Krister, please update your listing in the MAINTAINERS file.
Happy hacking!
David
Michael Matz wrote:
Hi,
On Wed, 29 Aug 2007, Bernd Schmidt wrote:
Apart from that I agree that in the case of conditional defs multiple
ones might reach a use. I disagree for partial defs, if one dominates
the other. For most cases (except register allocation) a partial def
is just
Hi,
On Thu, 30 Aug 2007, Kenneth Zadeck wrote:
Michael and Bernd,
I you look at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33224 you will
see that this bug has nothing to do with the type of def. It is pilot
error on the author of the loop unrolling code. They are looking in the
On Thu, 30 Aug 2007, David Edelsohn wrote:
I am pleased to announce that the GCC Steering Committee has
appointed Krister Walfridsson as NetBSD OS port maintainer.
Please join me in congratulating Krister on his new role.
Krister, please update your listing in the MAINTAINERS
On ons, 2007-08-29 at 16:42 -0400, Daniel Drake wrote:
Hi,
Take the following code sample:
#define BREAK_GCC4_2
templatetypename Op
void foo(Op op) { op(); }
class My {
public:
static void myOp() { }
void test() {
#ifdef
On ons, 2007-08-29 at 16:42 -0400, Daniel Drake wrote:
#define BREAK_GCC4_2
templatetypename Op
void foo(Op op) { op(); }
class My {
public:
static void myOp() { }
void test() {
#ifdef BREAK_GCC4_2
foo(myOp);
#else
foo(My::myOp);
#endif
}
};
On
Date: Thu, 30 Aug 2007 14:24:36 -0500
From: Stephen M. Kenton [EMAIL PROTECTED]
Can anyone explain why LIMITS_H_TEST is defined in cris/t-linux, while
it is not defined for any other linux target?
A STFW would have given you
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00717.html.
I can't
Segher - If remember right, cris was one of the targets that did not
build for you. This might help.
No idea if it would help or not -- it currently dies with
an ICE while building __mulvdi3:
/home/segher/src/gcc/libgcc/../gcc/libgcc2.c: In function '__mulvdi3':
Andrea Marongiu wrote:
It seems to be using the correct as (arm-elf-as) which anyhow doesn't support
the -Qy option.
No, it is using the wrong assembler. There are two compilers here, the
native x86 linux one, and the cross compiler. You have the native x86
linux compiler using the
From: Segher Boessenkool [EMAIL PROTECTED]
Date: Fri, 31 Aug 2007 02:31:07 +0200
Segher - If remember right, cris was one of the targets that did not
build for you. This might help.
No idea if it would help or not -- it currently dies with
an ICE while building __mulvdi3:
What
Janis Johnson wrote:
But it looks like libdecnumber is processed in stage 1. What if the
stage 1 compiler doesn't handle C++ comments?
Right, decNumber is used in the C compiler and it's the C++ comments
that convinced me of the need to modify the sources. While I'm at it I
might as well
As a somewhat related follow on to Kenny's new interference graph
builder patch (which is still waiting for a full review):
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01729.html
I'd like to squeeze in a new representation of the interference graph
that in some cases can save a significant
Interesting. I built it (along with 22 others) today and it worked
using gcc 4.2.1 and binutils 2.18 on x86_64 to build a 4.2.1 criss
cross-compiler on top of the inhibit_libc check for linux-unwind.h I
posted yesterday. I need to rework that one a bit,
but it got alpha, sparc, and several
--- Comment #7 from dominiq at lps dot ens dot fr 2007-08-30 07:03 ---
Subject: Re: [4.3 regression] Missing last digit is
some formatted output
gives the output
1.797693134862316E+30^@ 2.225073858507201E-30^@
^@ is binary 0 and is not display on my terminal. If I send
the
--- Comment #13 from andreagrassi at sogeasoft dot com 2007-08-30 07:54
---
Subject: R: Error in compiling when there is a function with a char parameter
called before its declaration with inline parameters.
Ok, Ken, I understood. Thank you again for your detailed explanation.
Your
seen with 4.3 20070829, configured with --enable-targets=all, binutils-2.18
the libstdc++ testsuite (32bit) fails, 64bit works:
Executing on host: /home/doko/gcc/snap/gcc-snapshot-20070829/build/./gcc/g++
-shared-libgcc -B/home/doko/gcc/snap/gcc-snapsh
ot-20070829/build/./gcc -nostdinc++
--- Comment #2 from steven at gcc dot gnu dot org 2007-08-30 08:07 ---
Having this case vectorized might help us look better compared to other
compilers. gfortran produces a 65% slower fatigue binary than the faster
compiler (Sun f95, see
--- Comment #3 from dorit at gcc dot gnu dot org 2007-08-30 08:12 ---
(In reply to comment #2)
I suspect this might be due to not updating the rd information after
unrolling.
Can you check if
analyze_insns_in_loop() (which calls df_analyze()) is being called just before
the
--- Comment #32 from jakub at gcc dot gnu dot org 2007-08-30 08:27 ---
Subject: Bug 32758
Author: jakub
Date: Thu Aug 30 08:27:33 2007
New Revision: 127923
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127923
Log:
PR middle-end/32758
* dce.c (dce_process_block):
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-30 08:41 ---
Please attach such long examples the next time. This makes the bug report
easier to read and saves one from removing all the line breaks that get added.
I tried your example with NAG f95 and it reports:
Error: line
--- Comment #33 from jakub at gcc dot gnu dot org 2007-08-30 08:43 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-30 09:03 ---
I see the same thing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2007-08-30 09:04 ---
Forgot to mention that gfortran gives the same error as NAG f95 but only when
using -std=f95 or f2003:
Error: The CHARACTER elements of the array constructor at (1) must have the
same length (24/32)
Work around:
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-30 09:07 ---
Created an attachment (id=14138)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14138action=view)
Testcase of comment 0 as file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33241
--- Comment #23 from rguenth at gcc dot gnu dot org 2007-08-30 09:07
---
I don't think the patch fixes anything. Can you elaborate on
D.8892_26 is a non-pointer variable, eliminating edges.
but D.8892 _is_ a pointer. Or is it just that D.8892_26 is ultimately copied
from a pointer
--- Comment #7 from cyberflex at mail dot ru 2007-08-30 09:34 ---
Problem is reproducible, but it likely should be posted to other list.
It looks that behaviour of particular utility rfcomm is such specific that
it not only ignores some signals but also forks one more child in detached
--- Comment #8 from cyberflex at mail dot ru 2007-08-30 09:34 ---
Created an attachment (id=14139)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14139action=view)
test.java
test.java to run with bt_connect.bash
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33218
--- Comment #9 from cyberflex at mail dot ru 2007-08-30 09:35 ---
Created an attachment (id=14140)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14140action=view)
script bt_connect.bash
script to use with 14139: test.java
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33218
--- Comment #10 from cyberflex at mail dot ru 2007-08-30 09:36 ---
Created an attachment (id=14141)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14141action=view)
one more helper script bt_param.bash
helper script for 14139: test.java
--
--- Comment #11 from cyberflex at mail dot ru 2007-08-30 09:41 ---
It looks that the fact that, rfcomm in some situations are killed when shell
script called with Proces.destroy() and in some situations don't
misleded me.
Also the strace shows that rfcomm sleep inside accept system
--- Comment #24 from rguenth at gcc dot gnu dot org 2007-08-30 09:49
---
Note that even with the proposed patch we generate different code dependent on
if -g is enabled or not. Starting with the first alias pass there are
differences
in the has_volatile_ops annotations!
@@ -3818,9
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-08-30 10:06 ---
4.1 ICEs during expansion of stack vars while 4.2 and 4.3 ICE in
force_constant_size, at gimplify.c:718.
4.1 backtrace:
#1 0x00808124 in tree_low_cst (t=0x2ad57f2a61c0, pos=1)
at
--- Comment #2 from dorit at gcc dot gnu dot org 2007-08-30 10:12 ---
There are two time consuming routines in air.f90 of the Polyhedron
benchmark that are not vectorized: lines 1328 and 1354. These appear
in the top counting of execution time with oprofile:
SUBROUTINE
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-30 11:44 ---
I have a patch - accept.
The standard says:
C1208 (R1206) If MODULE appears in a procedure-stmt, each procedure-name in
that statement shall be accessible in the current scope as a module procedure.
module
source file :
/*
* The execution gives wrong results when compiled with mingw32-gcc 3.4.2
* (MinGW-5.1.3)
* (no problem with previous mingw32-gcc 3.2.3 / MinGW-3.1.0)
*
* KO when REAL = float
* OK when REAL = double
*
* Expected results are : tab[0] = 123 and tab[1] = -123
*
*
--- Comment #25 from rguenth at gcc dot gnu dot org 2007-08-30 12:14
---
Created an attachment (id=14142)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14142action=view)
reduced testcase for the volatile diffs
against same svn revision + the proposed patch
--
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-08-30 12:33 ---
There is no sequence point between *p++ and *p. So you hit #2 of the most
frequently reported (non-)bugs.
*** This bug has been marked as a duplicate of 11751 ***
--
rguenth at gcc dot gnu dot org changed:
--- Comment #79 from rguenth at gcc dot gnu dot org 2007-08-30 12:33
---
*** Bug 33248 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from patchapp at dberlin dot org 2007-08-30 13:05 ---
Subject: Bug number PR33228
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-08/msg02178.html
--
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-08-30 13:30
---
Not much use any more, closing.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-30 13:45 ---
Subject: Bug 33228
Author: burnus
Date: Thu Aug 30 13:44:47 2007
New Revision: 127925
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127925
Log:
2007-08-30 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #4 from burnus at gcc dot gnu dot org 2007-08-30 13:47 ---
FIXED.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from spop at gcc dot gnu dot org 2007-08-30 14:19 ---
Subject: Re: Missed opportunities for vectorization due to unhandled real_type
Thanks for the detailed comments and further investigation.
On 30 Aug 2007 10:12:26 -, dorit at gcc dot gnu dot org
I couldn't
The following code gives different results with -O3 (or -O2) and no
optimization.The -O3 output is wrong.
try:
$g++ -O3 test.cpp
$cat test.cpp
#include iostream
class foo
{
int _type;
public:
foo( int t ) : _type(t) {};
bool is_1() { return _type == 1; }
bool is_23() { return
--- Comment #4 from zadeck at naturalbridge dot com 2007-08-30 14:43
---
Subject: Re: failing rtl iv analysis (maybe due
to df)
dorit at gcc dot gnu dot org wrote:
--- Comment #3 from dorit at gcc dot gnu dot org 2007-08-30 08:12 ---
(In reply to comment #2)
I
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-08-30 14:43 ---
This works for me on x86_64 and i686. Possibly a rtl-optimization or target
bug.
As there were loop fixes after 4.1.2 went out can you try with the trunk of
the gcc-4_1-branch or give the exact version of your
--- Comment #26 from rguenth at gcc dot gnu dot org 2007-08-30 14:52
---
Subject: Bug 33199
Author: rguenth
Date: Thu Aug 30 14:52:28 2007
New Revision: 127927
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127927
Log:
2007-08-30 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #27 from dberlin at gcc dot gnu dot org 2007-08-30 14:56
---
(In reply to comment #23)
I don't think the patch fixes anything.
Uh, sure it does.
Before we were ignoring the pointer results from calls.
They should point to anything.
Can you elaborate on
D.8892_26
--- Comment #8 from burnus at gcc dot gnu dot org 2007-08-30 15:03 ---
Can reproduce the problems with x86-64/Linux. -m64 works, but -m32 fails.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from alduc1 at free dot fr 2007-08-30 15:22 ---
I do not think it is the same bug 11751.
For example:
*p++ = *p + 1.0;
*p++ = *p + 1.0;
works. But
*p++ = (float) floor((double) *p + 0.5);
*p++ = (float) floor((double) *p + 0.5);
does not work (with float). It
--- Comment #1 from dberlin at gcc dot gnu dot org 2007-08-30 15:24 ---
Subject: Re: New: Missed opportunities for vectorization due to PRE
On 30 Aug 2007 02:55:17 -, spop at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
The following loop showing up in the top time users in
--- Comment #3 from schwab at suse dot de 2007-08-30 16:10 ---
It invokes undefined behaviour, if it breaks you get to keep the pieces. There
is no requirement that you get any useful result.
http://c-faq.com/expr/evalorder1.html
*** This bug has been marked as a duplicate of 11751
--- Comment #80 from schwab at suse dot de 2007-08-30 16:10 ---
*** Bug 33248 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11751
--- Comment #5 from dorit at gcc dot gnu dot org 2007-08-30 16:29 ---
dorit,
i am having trouble exactly reproducing this example because you did not
give the svn revision and so all of the numbers are a little bit
different.
it's revision 127623
However, I am going to submit a
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #5 from jason at gcc dot gnu dot org 2007-08-30 16:30 ---
Fixed for 4.3, IMO not enough evident interest in the bug to bother
backporting.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from jason at gcc dot gnu dot org 2007-08-30 16:33 ---
Fixed by Simon Martin.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from jakub at gcc dot gnu dot org 2007-08-30 16:43 ---
Subject: Bug 33168
Author: jakub
Date: Thu Aug 30 16:43:19 2007
New Revision: 127928
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127928
Log:
PR target/33168
* config/rs6000/rs6000.c
During gfortran compilation of the integration subpack of scipy-0.5.2.1,
gfortran fails with an internal compiler error: Bus error when trying to
compile dqelg.f.
Command line and error info:
gfortran:f77: Lib/integrate/quadpack/dqelg.f
Lib/integrate/quadpack/dqelg.f: In function 'dqelg':
--- Comment #4 from victor dot prosolin at gmail dot com 2007-08-30 17:09
---
I am sorry for posting such a long example, but the code was not written by me
so I didn't want to make stupid changes. It's my first time reporting a bug via
bugzilla so don't be too critical about me not
The problem is that the I/O system reads one (admittedly malformed)
field into two variables in list directed input.
Take this one line and put it in a file named 'the_test_file'
- cut - cut - cut - cut
13.5-1420.83 10.350E+00 -0.181E+19
- cut
--- Comment #1 from claumann at princeton dot edu 2007-08-30 17:25 ---
Compiles with no errors using gfortran 4.2.1 for i686-apple-darwin8.
--
claumann at princeton dot edu changed:
What|Removed |Added
--- Comment #12 from daney at gcc dot gnu dot org 2007-08-30 17:44 ---
Does GCJ's behavior differ from Sun's in this test?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33218
--- Comment #7 from rakdver at kam dot mff dot cuni dot cz 2007-08-30
18:09 ---
Subject: Re: failing rtl iv analysis (maybe due to df)
The only thing that you are allowed to do with the DF_REF_ID is to get
it from a df_def
AFTER YOU ARE SURE THAT THE DEF IS IN THE REGION
OK, this
--disable-libmudflap --disable-nls --disable-werror
--disable-multilib --with-ibmlongdouble --with-cpu=G4 --enable-clocale=gnu
--with-system-zlib
Thread model: posix
gcc version 4.3.0 20070830 (experimental) (GCC)
The significant increase concerns gfortran; but, others appear high.
This ist
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33250
--- Comment #2 from burnus at gcc dot gnu dot org 2007-08-30 18:12 ---
(gfortran bugs are by definition not critical or major for GCC as a whole;
still the gfortran team tries to fix regressions as soon as possible.)
I cannot reproduce this problem with today's gfortran on
tests 114
/var/tmp/43/build-156/gcc/testsuite/g++/../../g++ version 4.3.0 20070830
(experimental) (GCC)
make[2]: [check-g++] Error 1 (ignored)
make[2]: Entering directory
`/var/tmp/43/build-156/powerpc-unknown-linux-gnu/libgfortran'
make check-am
make[3]: Entering directory
`/var/tmp/43
87
# of unsupported tests 114
/var/tmp/43/build-156/gcc/testsuite/g++/../../g++ version 4.3.0 20070830
(experimental) (GCC)
make[2]: [check-g++] Error 1 (ignored)
make[2]: Entering directory
`/var/tmp/43/build-156/powerpc-unknown-linux-gnu/libgfortran'
make check-am
make[3
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-30 18:26 ---
I tried you example with g77 and it shows No Error. However, using all other
compilers I have (ifort, sunf95, openf95, g95, gfortran, NAG f95) it shows
Error!.
...
Ok, after re-reading your bug report, I see that
/var/tmp/43/gcc-4.3.0/libstdc++-v3/testsuite/libstdc++-abi/abi.exp.
ERROR: could not compile testsuite_abi.cc
This was fixed by:
2007-08-30 Jakub Jelinek [EMAIL PROTECTED]
PR target/33168
* config/rs6000/rs6000.c (rs6000_elf_in_small_data_p): Return
true if any of the
--- Comment #3 from pinskia at gmail dot com 2007-08-30 18:35 ---
Subject: Re: GCC-4.3.0 Bootstrap testsuite error increase
/var/tmp/43/gcc-4.3.0/libstdc++-v3/testsuite/libstdc++-abi/abi.exp.
ERROR: could not compile testsuite_abi.cc
This was fixed by:
2007-08-30 Jakub Jelinek
--- Comment #3 from claumann at princeton dot edu 2007-08-30 18:40 ---
Subject: Re: [Regression 4.3] bus error compiling dqelg.f in scipy on intel
mac
Howdy-
Thanks for looking into it!
It compiles just fine with
gfortran -c dqelg.f
I'm not especially excited about trying to
On 30 Aug 2007 18:40:51 -, claumann at princeton dot edu
[EMAIL PROTECTED] wrote:
build_classic_dist_vector_1 (ddr=0x434c3b20, ddr_a=0x0,
ddr_b=0x434af898, dist_v=0x7b4d8c, init_b=0x434e9bd0 A,
index_carry=0x7) at ../../gcc-4.3-20070810/gcc/tree-data-ref.c:2719
2719
--- Comment #4 from pinskia at gmail dot com 2007-08-30 18:44 ---
Subject: Re: [Regression 4.3] bus error compiling dqelg.f in scipy on intel
mac
On 30 Aug 2007 18:40:51 -, claumann at princeton dot edu
[EMAIL PROTECTED] wrote:
build_classic_dist_vector_1 (ddr=0x434c3b20,
--- Comment #8 from zadeck at naturalbridge dot com 2007-08-30 18:51
---
Subject: Re: failing rtl iv analysis (maybe due
to df)
rakdver at kam dot mff dot cuni dot cz wrote:
--- Comment #7 from rakdver at kam dot mff dot cuni dot cz 2007-08-30
18:09 ---
Subject: Re:
--- Comment #5 from claumann at princeton dot edu 2007-08-30 18:51 ---
Subject: Re: [Regression 4.3] bus error compiling dqelg.f in scipy on intel
mac
Great! Will do. Sorry to take your time.
Chris
On Aug 30, 2007, at 12:44 PM, pinskia at gmail dot com wrote:
--- Comment #4
Reading back a namelist string which contains an
apostrophe doesn't work.
I am marking this as an enhancement because reading back
what we wrote with a namelist isn't guaranteed to work
(see note 10.37 in the working draft). It does work with
ifort, for example.
$ cat namelist.f90
program main
--- Comment #9 from zadeck at naturalbridge dot com 2007-08-30 18:57
---
Subject: Re: failing rtl iv analysis (maybe due
to df)
zadeck at naturalbridge dot com wrote:
--- Comment #8 from zadeck at naturalbridge dot com 2007-08-30 18:51
---
Subject: Re: failing rtl iv
--- Comment #2 from William dot H dot Daffer at jpl dot nasa dot gov
2007-08-30 19:33 ---
Subject: Re: f77 reads one field into two variables in
list directed i/o
On Thu, 2007-08-30 at 18:26 +, burnus at gcc dot gnu dot org wrote:
--- Comment #1 from burnus at gcc
--- Comment #14 from patchapp at dberlin dot org 2007-08-30 19:45 ---
Subject: Bug number PR 30315
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-08/msg02217.html
--
--- Comment #10 from rakdver at gcc dot gnu dot org 2007-08-30 20:05
---
I know how to fix the problem, now.
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jakub at gcc dot gnu dot org 2007-08-30 20:15 ---
Should be fixed now, see
http://gcc.gnu.org/viewcvs?root=gccview=revrev=127928
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from dominiq at lps dot ens dot fr 2007-08-30 21:04 ---
The following code:
real x
x = 1.0
print '(3E20.2e2)', x, x/10.0, x/100.0
print '(3E20.2e3)', x, x/10.0, x/100.0
print '(3E20.2e4)', x, x/10.0, x/100.0
print '(3E20.2e5)', x, x/10.0, x/100.0
print '(3E20.2e6)', x,
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-08-30 21:06 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-08-30 21:09 ---
Not a GCC bug so closing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-08-30 21:09 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-30 21:15 ---
I have a patch which needs testing for the trunk.
I am thinking about adding to my normal testing -mminimal-toc with -m64.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|c |middle-end
Target Milestone|--- |4.2.2
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-08-30 21:19 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33205
--- Comment #11 from zadeck at naturalbridge dot com 2007-08-30 21:46
---
Subject: Re: failing rtl iv analysis (maybe due
to df)
rakdver at gcc dot gnu dot org wrote:
--- Comment #10 from rakdver at gcc dot gnu dot org 2007-08-30 20:05
---
I know how to fix the problem,
The following program is invalid Fortran 95/2003, but this cannot be diagnosed
at compile time:
program array_char
implicit none
character (len=2) :: x, y
x = a
y = cd
print*,[trim(x),trim(y)] ! [ a, cd ] -INVALID: different string lengths
end program array_char
While behavior of gfortran is ok
--- Comment #12 from fago at caltech dot edu 2007-08-30 21:52 ---
A stupid question: why cannot gfortran detect this invalid code at compile
time? I was quite surprised by a runtime error.
BTW, I was compiling some legacy code with 4.2.1 and just hit this ...
--
--- Comment #3 from pault at gcc dot gnu dot org 2007-08-30 22:11 ---
Subject: Bug 32703
Author: pault
Date: Thu Aug 30 22:10:55 2007
New Revision: 127939
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127939
Log:
2007-08-31 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #7 from pault at gcc dot gnu dot org 2007-08-30 22:11 ---
Subject: Bug 31258
Author: pault
Date: Thu Aug 30 22:10:55 2007
New Revision: 127939
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127939
Log:
2007-08-31 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #22 from pault at gcc dot gnu dot org 2007-08-30 22:11 ---
Subject: Bug 31197
Author: pault
Date: Thu Aug 30 22:10:55 2007
New Revision: 127939
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127939
Log:
2007-08-31 Paul Thomas [EMAIL PROTECTED]
PR
1 - 100 of 139 matches
Mail list logo
