--- Comment #4 from pault at gcc dot gnu dot org 2007-03-26 07:19 ---
(In reply to comment #3)
> I haven't seen anything in the Fortran 2003 standard forcing the subroutines
> to
> be in the contains statement.
In this case the interface is said to be implicit and the standard does no
--- Comment #5 from daney at gcc dot gnu dot org 2007-03-26 07:13 ---
Committed to the 4.2 branch as well.
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from daney at gcc dot gnu dot org 2007-03-26 07:07 ---
Subject: Bug 31228
Author: daney
Date: Mon Mar 26 07:07:13 2007
New Revision: 123208
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123208
Log:
PR libgcj/31228
* configure.ac: Add checks for ge
--- Comment #31 from jvdelisle at gcc dot gnu dot org 2007-03-26 07:00
---
Here is a new patch. I need someone to test on SPEC. It is very simple.
Index: transfer.c
===
*** transfer.c (revision 123205)
--- transfer.c (
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-26 06:48 ---
I get:
Set in insn 47 is invariant (0), cost 4, depends on
Where insn 47 is the load constant:
(insn 47 46 48 3 (set (reg:SI 156)
(const_int 0 [0x0])) 328 {*movsi_internal1} (nil)
(nil))
If I change the
Testcase:
void f(int *a)
{
int i;
for (i = 0;i<100;i++)
a[i] = 0;
}
---cut-
we get:
_f:
li r0,0
li r2,4
stw r0,0(r3)
li r0,99
mtctr r0
L2:
li r0,0
stwx r0,r2,r3
addi r2,r2,4
bdnz L2
blr
t
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-26 06:01 ---
Can you show the exact code from openssl which has the problem, there might be
better ways of writting the code instead of what they are doing right now.
This code is still undefined and I don't think we really shou
--- Comment #3 from mikael dot morin at tele2 dot fr 2007-03-26 05:58
---
Created an attachment (id=13286)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13286&action=view)
the working case
The problem arise when the subroutine is not defined in a contains statement in
the main pr
--- Comment #12 from mmitchel at gcc dot gnu dot org 2007-03-26 05:43
---
I agree with Joseph that STRIP_SIGN_NOPS should not be removing changes in
precision that may change the value and that, indeed, mode is probably being
used as an inaccurate proxy for precision.
--
http://gcc
The eventual consensus of the ml thread "gcc 4.2 more strict check for
"function called through a non-compatibletype" [1]:
Mark Mitchell wrote:
> > Ian Lance Taylor wrote:
> >
>> >> I realized that I am still not stating my position very clearly. I
>> >> don't think we should make any extra
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2007-03-26 04:41
---
Subject: Bug 31199
Author: jvdelisle
Date: Mon Mar 26 04:41:29 2007
New Revision: 123207
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123207
Log:
2007-03-25 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #14 from patchapp at dberlin dot org 2007-03-26 04:41 ---
Subject: Bug number PR 18937
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-03/msg01650.html
--
http://gcc.gnu.org/bugzilla/
--- Comment #6 from patchapp at dberlin dot org 2007-03-26 04:41 ---
Subject: Bug number PR 14737
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-03/msg01649.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #11 from patchapp at dberlin dot org 2007-03-26 04:40 ---
Subject: Bug number PR 22156
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-03/msg01625.html
--
http://gcc.gnu.org/bugzilla/
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2007-03-26 04:23
---
Subject: Bug 31199
Author: jvdelisle
Date: Mon Mar 26 04:23:15 2007
New Revision: 123205
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123205
Log:
2007-03-25 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #8 from hjl at lucon dot org 2007-03-26 04:04 ---
The invalid insn is added via
#0 add_insn (insn=0x2aafc690)
at /export/gnu/src/gcc/gcc/gcc/emit-rtl.c:3411
#1 0x004fb88d in emit_insn (x=0x2aafc690)
at /export/gnu/src/gcc/gcc/gcc/emit-rtl.c:4336
#2
--- Comment #7 from hjl at lucon dot org 2007-03-26 03:15 ---
It looks like expr.c and i386.c don't agree how to generate push
instuction. i386.c has gen_push and expr.c has emit_single_push_insn.
If emit_single_push_insn is called, it will generate invalid patten:
(insn 10 9 11 3 (set
--- Comment #5 from bangerth at dealii dot org 2007-03-26 03:13 ---
Manuel,
thanks for (re-)submitting the patch today. I don't have the infrastructure
to test patches any more these days, but I appreciate that someone takes
up the issue again.
I think the text duplication is not the bi
For:
int *f(int *a, int b, int c)
{
int i;
a --;
*a = 1;
for (i = 0;ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=31358
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-03-26 01:59 ---
This works on the trunk at least on powerpc-darwin.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31268
--- Comment #6 from hjl at lucon dot org 2007-03-26 01:55 ---
Jan, it may be related to your code:
http://gcc.gnu.org/ml/gcc-patches/2000-04/msg00263.html
Any idea?
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #7 from mmitchel at gcc dot gnu dot org 2007-03-26 01:44
---
Richard, are you able to confirm this bug?
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
---
--
brooks at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |brooks at gcc dot gnu dot
|dot org
--
brooks at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |brooks at gcc dot gnu dot
|dot org
--- Comment #5 from hjl at lucon dot org 2007-03-26 01:18 ---
It also happens with -Os:
bash-3.1$ /export/build/gnu/gcc/build-x86_64-linux/stage1-gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/stage1-gcc/ -m32 -S -o bar.s bar.i
-Os
bar.i: In function isinfd32:
bar.i:22: error:
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot
|dot org
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-03-26 01:00
---
Turns out this is not a duplicate of 31199. However its is closel related. I
wll work this one as well.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--
As documented, using multiple --help= options in one command line
produces an output that concatenates the output from the various --help=
options.
However, using both --help and --help= gives only the --help output,
regardless of the order in which they are specified.
--
Summary: --
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-26 00:34 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-26 00:33 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
Consider the following output:
> ~/bin-trunk/bin/gcc --help=fortran
The following options are supported by, amoung others, the language :
-I This switch lacks documentation
[...]
T
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-26 00:27 ---
NaN's are unordered so they will compare false for ordered operators.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31354
The documentation in invoke.texi for the --help= option only lists the
"optimizers", "warnings", "target", and "params" values that the option can
take. However, it can also take a language name as a value, and this isn't
documented.
--
Summary: --help= option isn't documented.
I'm guessing at middle-end here, maybe it is target...
I don't think it is correct for NaNs to fail any comparison.
They should only fail comparisons which include equality.
$ cat compare.c
#include
int main()
{
float nan, x;
nan = 0.0;
nan = nan / nan;
x = 3.2;
printf("%f\n", na
Consider the following output:
> ~/bin-trunk/bin/gcc --help=target
The following options are target specific:
-m128bit-long-doublesizeof(long double) is 16
-m32Generate 32bit i386 code
[...]
-muclibc
--- Comment #1 from tobi at gcc dot gnu dot org 2007-03-26 00:13 ---
It probably shouldn't say "rhs" in the error message, either.
It looks like we don't look through the references correctly when determining
the length of the rhs, though I can't see exactly where this goes wrong.
--
--- Comment #2 from tobi at gcc dot gnu dot org 2007-03-26 00:07 ---
*** Bug 31294 has been marked as a duplicate of this bug. ***
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from tobi at gcc dot gnu dot org 2007-03-26 00:07 ---
*** This bug has been marked as a duplicate of 31306 ***
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
When an option is present in multiple front ends, the gcc -v --help output
assumes that the documentation is the same in all of the front ends for which
the option is present, and only reports the documentation string for the first
front end for which it appears.
For example, in 4.2, the Ada outpu
When an option is shared between multiple front ends, the output of gcc -v
--help uses the documentation string from the first front end for which it is
listed.
Ada is listed before C, and thus all of the shared Ada/C options use the Ada
documentation, rather than the C documentation. Unfortunate
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-25 23:48 ---
This was caused by:
2007-02-12 Nick Clifton <[EMAIL PROTECTED]>
* doc/invoke.texi (Overall Options): Document --help=.
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|
gcc -v --help is inconsistent about where it places its output. If I try to
redirect the output to a file (which is rather a reasonable thing to do, given
how long it is!), some of it still gets printed to the console via standard
error:
---
To quote from the output of gcc -v --help on
gcc (GCC) 4.3.0 20070323 (experimental):
--
The following options are specific to the language Ada:
-gnat Specify options to GNAT
The following options are specific to the language C:
No options with the
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-03-25 23:36 ---
Something like:
(define_insn_and_split "altivec_dup"
[(set (match_operand:V 0 "register_operand" "v")
(vec_duplicate: (match_operand: 0 "r")))
(clobber (match_operand:V 3 "memory_operand" "=Z"))]
"TARG
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-03-25 23:05 ---
Now the patch does not solve the following testcase:
int main1 (int X)
{
int s = X;
int i;
for (i = 0; i < 96*16; i+=16)
s += i;
return s;
}
For this one to be fixed, we need to define an insn which doe
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-03-25 22:55 ---
(In reply to comment #4)
> I do not believe the patch will help with the original missed optimization
> because the backend never sees a direct assignment from the CONSTRUCTOR -- it
> already is placed in memory. T
--- Comment #4 from tkoenig at gcc dot gnu dot org 2007-03-25 22:18 ---
Subject: Bug 31297
Author: tkoenig
Date: Sun Mar 25 21:17:51 2007
New Revision: 123200
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123200
Log:
2007-03-25 Thomas Koenig <[EMAIL PROTECTED]>
PR li
--- Comment #11 from tkoenig at gcc dot gnu dot org 2007-03-25 22:04
---
I'll give this a shot.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
As
--- Comment #4 from dje at gcc dot gnu dot org 2007-03-25 21:56 ---
I do not believe the patch will help with the original missed optimization
because the backend never sees a direct assignment from the CONSTRUCTOR -- it
already is placed in memory. The example in comment #2 is differe
--- Comment #2 from pcarlini at suse dot de 2007-03-25 21:01 ---
I'm looking into this: apparently the problem is just (or mostly) that at the
beginning of instantiate_decl we are not copying DECL_IN_SYSTEM_HEADER (d) into
in_system_header: doing it fixes the test here (and avoids the wa
--- Comment #6 from tkoenig at gcc dot gnu dot org 2007-03-25 20:55 ---
(In reply to comment #5)
> Thomas, the testcase fails the execution test on i386-darwin at all
> optimization levels in an up-to-date tree.
*sigh*
Can you maybe investigate the following:
- print line1 and line 2
--- Comment #13 from tobi at gcc dot gnu dot org 2007-03-25 20:51 ---
I have a patch which does eveything, except detecting branches to END DOs. I
can't seem to figure out how to do this in a sensible way without introducing a
replacement quadratic bottleneck :-(
--
http://gcc.gnu.
--- Comment #5 from tobi at gcc dot gnu dot org 2007-03-25 20:34 ---
Thomas, the testcase fails the execution test on i386-darwin at all
optimization levels in an up-to-date tree.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31196
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-03-25 19:40
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-03-25 19:38
---
Reduced testcase:
$ cat a.c
typedef struct
{
unsigned char bits;
} decNumber;
typedef struct
{
unsigned char bytes[1];
} decimal32;
decNumber *__decimal32ToNumber (const decimal32 *, decNumber *);
void __ho
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-25 19:23 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-25 19:23 ---
*** Bug 31348 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-25 19:23 ---
*** This bug has been marked as a duplicate of 30972 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-03-25 19:23
---
Created an attachment (id=13285)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13285&action=view)
Preprocessed source file triggering the ICE
Here's the preprocessed source, sorry for forgetting it in the f
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-25 19:22 ---
Vista is not support right now IIRC.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-03-25 19:20 ---
*** Bug 31347 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-25 19:20 ---
*** This bug has been marked as a duplicate of 29826 ***
*** This bug has been marked as a duplicate of 29826 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #2 from hjl at lucon dot org 2007-03-25 19:18 ---
Where is "the attached preprocessed source"?
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #1 from terminatorul at gmail dot com 2007-03-25 19:17 ---
Created an attachment (id=13284)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13284&action=view)
C source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31347
Version exacta: gcc version 4.1.0
System type: Windows Vista
Manufacturer: Dell
Model: Inspiron I6400
Rating: Windows Experience Index: Unrated
Processor: Genuine Intel(R) CPU T2060 @ 1.60GHz 1.60 GHz
Memory(Ram): 1022
This happes trying to compile gettetxt-0.16 with -O3 -mthreads -msse2 -mmmx ...
Note that it compiles just fine without all the
'-march=pentium4 -msse -msse2 -mmmx -O3 -mfpmath=sse -mthreads -Wall -v
-save-temps' options ...
Here is the output
/bin/sh ../libtool --tag=CC --mode=compile i786-pc-
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-25 18:58 ---
Note, I think decLibrary.c changed but does not cause this not to be an user
visible regression.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31344
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-25 18:41 ---
I think this is a regression also on the 4.2 branch now since the set of
patches that caused this is also there.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pthaugen at us dot ibm dot com 2007-03-25 18:38 ---
I hit the same ICE building the 191.fma3d benchmark from cpu2000 when compiling
lsold.f90 with -O2 -ftree-loop-linear.
--
pthaugen at us dot ibm dot com changed:
What|Removed |
--- Comment #12 from s_j_newbury at yahoo dot co dot uk 2007-03-25 16:52
---
(In reply to comment #11)
> I have everything built except for libjava/exception.cc which fails as seen
> below.
>
libjava/exception.cc needs special handling of the EABI unwind support as is
done in the libsu
--- Comment #5 from dayas2003 at yahoo dot com 2007-03-25 15:07 ---
I am unsing the following version:
arm-2006q1-6-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar
I get the same error as said above. I am not sure whether to modify the Code [
there are many files; so painful solution :-( ]
--- Comment #2 from mikael dot morin at tele2 dot fr 2007-03-25 14:41
---
$ FC=gfortran; $FC -v; $FC -o test test.f; echo; ./test
Lecture des spécification à partir de
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/specs
Target: x86_64-pc-linux-gnu
Configuré avec: /usr/src/gcc-4.1.2/configure -
--- Comment #1 from mikael dot morin at tele2 dot fr 2007-03-25 14:38
---
Created an attachment (id=13283)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13283&action=view)
program showing the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31346
size and ubound are lost when passing an array as argument of a procedure
--
Summary: wrong values for ubound and size of deferred shape
arrays
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Pr
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-25 13:37 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #9 from dorit at gcc dot gnu dot org 2007-03-25 13:08 ---
Subject: Bug 30784
Author: dorit
Date: Sun Mar 25 12:08:29 2007
New Revision: 123197
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123197
Log:
PR tree-optimization/30784
* fold-const.c (fold_t
--- Comment #1 from tbm at cyrius dot com 2007-03-25 12:28 ---
Created an attachment (id=13282)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13282&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31345
Hi Ian,
Your fix for PR31034 worked for 18 out of 20 affected applications in Debian,
but there are 2 applications that still exhibit a related ICE:
[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -c -O2 qdbm-depot.c
qdbm-depot.c: In function 'dpsnaffle':
qdbm-depot.c:2: internal compiler erro
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-03-25 11:49
---
$ cat nan.f90
real :: nan, x
x = 7.2
nan = 0.0
nan = nan / nan
print *, minval((/ nan, x /)), maxval((/ nan, x /))
print *, minval((/ nan /)), maxval((/ nan /))
print *, minloc((/ nan
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot
|dot org
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot
|dot org
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-03-25 11:19
---
(In reply to comment #1)
> http://gcc.gnu.org/ml/fortran/2006-10/msg00583.html
Yes, thanks, I know. I followed in my patch
(http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01605.html) the idea I already
had at that
--- Comment #1 from dannysmith at users dot sourceforge dot net 2007-03-25
11:12 ---
http://gcc.gnu.org/ml/fortran/2006-10/msg00583.html
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31335
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-03-25 11:02
---
Fixed, thanks Joost for the report!
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-03-25 11:01
---
Subject: Bug 30877
Author: fxcoudert
Date: Sun Mar 25 10:01:23 2007
New Revision: 123196
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123196
Log:
PR fortran/30877
* fortran/interface.c
extract_insn, at recog.c:2119
The last revision known to compile OK on that particular setup was: 123178. I
can reproduce it with the attached preprocessed source and the following
command line:
$ /home/fxcoudert/gfortran_nightbuild/ibin-20070325/./gcc/cc1 -fpreprocessed
foo.i -mtune=i386
gnu_dev_major
--- Comment #4 from tkoenig at gcc dot gnu dot org 2007-03-25 10:29 ---
Subject: Bug 31196
Author: tkoenig
Date: Sun Mar 25 09:29:10 2007
New Revision: 123195
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123195
Log:
2007-03-25 Thomas Koenig <[EMAIL PROTECTED]>
PR li
--- Comment #1 from irar at il dot ibm dot com 2007-03-25 10:02 ---
Created an attachment (id=13281)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13281&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31343
An attempt to divide by zero is made (causing ICE on the attached test
case) for evolution functions with zero step.
For the following evolution functions of pS[i_15].x and pS[i_15].y from the
attached test
(chrec_a = {{0, +, 1}_1, +, 0}_2)
(chrec_b = {{1, +, 1}_1, +, 0}_2)
the difference (-1)
90 matches
Mail list logo
