--- Comment #5 from patchapp at dberlin dot org 2007-06-01 07:05 ---
Subject: Bug number PR 27078
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-06/msg8.html
--
http://gcc.gnu.org/bugzilla/s
reduced from CP2K (PR 29975)
gfortran -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
gcc version 4.3.0 20070531 (experimental)
gfortran -fprefetch-loop-arrays -O2 test.f90
test.f90: In function polint:
test.f90:1: internal compiler error: tree check: expected integer_cst, have
plus_e
--- Comment #105 from jv244 at cam dot ac dot uk 2007-06-01 07:08 ---
Another ICE has been filed as PR 32176
gfortran -fprefetch-loop-arrays -O2 test.f90
test.f90: In function polint:
test.f90:1: internal compiler error: tree check: expected integer_cst, have
plus_expr in int_cst_valu
--- Comment #13 from ubizjak at gmail dot com 2007-06-01 07:29 ---
(In reply to comment #11)
> New test (from PR32123):
>
> Standalone testcase, compile with -O2 -msse2 -mtune=k8:
Hm, this bug was misteriously fixed. It was manifested as
gcc.target/i386/sse2-vec-6.c failure in [1] and
--- Comment #1 from burnus at gcc dot gnu dot org 2007-06-01 07:49 ---
While the assert is occurs in the middle end, I think it is very likely a
tree-type mismatch in the front end.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from mikael dot morin at tele2 dot fr 2007-06-01 10:57
---
Ok, placing the function in a contains statement still reproduces the bug with
4.1.2, but doesn't compile with 4.3, complaining about the wrong size
of the string arguments.
And using variable size strings (len=*
--- Comment #2 from kmanjunat at gmail dot com 2007-06-01 07:52 ---
The test case is being called from a shared library with the
eabi support using dlopen.
The following is the test case
#include
#include
#include
int main()
{
char *a=NULL;
char *b="abcd";
char *ret=NULL;
ret
--- Comment #1 from theodore dot papadopoulo at sophia dot inria dot fr
2007-06-01 10:22 ---
Created an attachment (id=13644)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13644&action=view)
The source code showing the potential bug
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #2 from jv244 at cam dot ac dot uk 2007-06-01 11:06 ---
reduced:
SUBROUTINE polint(n)
INTEGER, PARAMETER :: dp=KIND(0.0D0)
REAL(dp) :: ya(n), xa(n), x
DO m = 1,n-1
DO i = 1,n-m
ho=xa(i)-x
hp=xa(i+m)-x
den=ho-hp
This is with gcc version 4.3.0 20070528 (experimental) and gcc-4.1.1 (redhat
FC5 version). I suspect it is also true for all intermediate versions...
The attached program when compiled with g++ and the flags -fopenmp gives the
following diagnostic and aborts compilation:
futuna-> /usr/local/gcc-4.
--- Comment #5 from kloedej at knmi dot nl 2007-06-01 08:41 ---
(In reply to comment #1)
> for integer overflows, see e.g.
> https://www.cisl.ucar.edu/docs/ibm/ref/fpe.html
> For x86 (32/64) platforms, this does not seem to be directly supported by
> hardware; in this case one would need
--- Comment #8 from pcarlini at suse dot de 2007-06-01 08:49 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-01 11:19 ---
*** This bug has been marked as a duplicate of 32166 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-06-01 11:19 ---
*** Bug 32174 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32166
First here is my gcc -v output:
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,ob
--- Comment #1 from henne at nachtwindheim dot de 2007-06-01 11:38 ---
Created an attachment (id=13645)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13645&action=view)
The eample snippet.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32178
--- Comment #9 from burnus at gcc dot gnu dot org 2007-06-01 11:36 ---
> Indeed, the compiler should report an error ; but it is just an improvement.
> Still much to learn about Fortran ;)
In Fortran, subroutines and functions in the same file have nothing to do with
each another if the
--- Comment #32 from kazssym at nifty dot com 2007-06-01 12:24 ---
If Bug 21706 is fixed, it can be built without defining _ALL_SOURCE even on
Interix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15212
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-06-01 11:28 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-01 11:19 ---
*** This bug has been marked as a duplicate of 32166 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-06-01 11:19 ---
*** Bug 32175 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32166
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-06-01 11:23 ---
#2 0x00a30ddc in int_cst_value (x=0x2b8d9ea73780)
at /space/rguenther/src/svn/trunk/gcc/tree.c:7720
7720 unsigned HOST_WIDE_INT val = TREE_INT_CST_LOW (x);
(gdb) call debug_generic_expr (x)
(int8) {
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-06-01 11:28 ---
We have a
>
side-effects
arg 0
side-effects nothrow
fn
constant invariant arg 0 >
arg 0
invariant arg 0 >
t.ii:8>>
that we don't handle in lower_s
--- Comment #33 from markus dot duft at salomon dot at 2007-06-01 12:32
---
(In reply to comment #32)
> If Bug 21706 is fixed, it can be built without defining _ALL_SOURCE even on
> Interix.
are you sure? my experiences with interix tell me to almost allways enable
_ALL_SOURCE, or not
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-01 14:14 ---
Your inline-asm is broken, you early clobber the output so you need to mark as
such like:
asm volatile("movl $1,%0 \n\t" \
"xchgl %0,%1 \n\t" \
"xorl $1,%0"
--- Comment #1 from ian at gcc dot gnu dot org 2007-06-01 15:06 ---
Subject: Bug 31455
Author: ian
Date: Fri Jun 1 15:06:19 2007
New Revision: 125265
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125265
Log:
PR rtl-optimization/31455
* lower-subreg.c (find_deco
--- Comment #2 from ian at airs dot com 2007-06-01 15:09 ---
Fixed.
--
ian at airs dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RE
--- Comment #10 from burnus at gcc dot gnu dot org 2007-06-01 15:21 ---
As gfortran seems to do everything as required by the Fortran standard (or at
least other compilers do the same ;-), this no bug.
It it only missing whole-file interface checking. As this enhancement is
tracked in P
--- Comment #10 from burnus at gcc dot gnu dot org 2007-06-01 15:21 ---
*** Bug 32170 has been marked as a duplicate of this bug. ***
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
GCC 4.3.0 compiled on Linux does NOT pass as many tests as GCC 3.4.4 for
Cygwin.
How seriously will people take _newer_ versions gcc if it can't pass the same
tests as older versions did. Something has slipped over the years.
Now that I have a great compiler I decide to do some tests to see how w
--- Comment #34 from kazssym at nifty dot com 2007-06-01 15:39 ---
(In reply to comment #33)
> (In reply to comment #32)
> > If Bug 21706 is fixed, it can be built without defining _ALL_SOURCE even on
> > Interix.
>
> are you sure? my experiences with interix tell me to almost allways e
Just to now forget ...
To the patch to PR 32156, Paul Thomas wrote in
http://gcc.gnu.org/ml/fortran/2007-05/msg00531.html :
"There is something not right with string concatenation
in the front-end that fails to transmit the string length correctly.
I have made several attempts to get to the botto
--- Comment #11 from bkoz at gcc dot gnu dot org 2007-06-01 16:35 ---
Subject: Bug 31717
Author: bkoz
Date: Fri Jun 1 16:35:34 2007
New Revision: 125266
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125266
Log:
2007-05-28 Benjamin Kosnik <[EMAIL PROTECTED]>
PR libst
The following program prints FAILED; it should print PASSED
as per RM 3.4(27), which states:
-- "For the execution of a call on an inherited subprogram,
-- a call on the corresponding primitive subprogram of the
-- parent or progenitor type is performed; the normal conversion
-- of each actual par
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-01 16:15 ---
Can you try with -ffloat-store, this might be the normal x87 issue (see PR
323).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2007-06-01 16:01 ---
> Just to now forget ...
A Freudian slip, I presume. This should of cause be:
"Just to NOT forget [to fix it]..."
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32179
--- Comment #6 from rask at sygehus dot dk 2007-06-01 19:56 ---
According to the documentation, -B passes -L to the linker, so there is no need
to pass both. It seems to work as documented.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32154
I may have found a situation where GCC's optimizations causes a constructor to
be skipped that leads to a crash. This problem first manifested itself in a
program involving well over 10 lines of code (not including the extra lines
from #include'd files). The initial problem is in code generat
--- Comment #1 from epperly2 at llnl dot gov 2007-06-01 20:44 ---
Created an attachment (id=13646)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13646&action=view)
tar file containing complete source to reproduce problem
% sha1sum bug32182.tar.bz2
ce7372671f73d316ad946aede1aad3d41
--- Comment #2 from epperly2 at llnl dot gov 2007-06-01 20:53 ---
To avoid depending on system #include files, the example has
typedef unsigned int size_t;
hardwired in the code. This may be an incorrect definition for some platforms.
Oddly enough, if I delete NextClass and make TestCl
--- Comment #3 from epperly2 at llnl dot gov 2007-06-01 21:07 ---
The Babel bug tracking entry corresponding to this GCC issue report is here:
https://www.cca-forum.org/bugs/babel/issue480
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32182
--- Comment #5 from epperly2 at llnl dot gov 2007-06-01 21:24 ---
In response to comment #4, I may be violating C++ aliasing rules, but I don't
see how that explains the behavior I am seeing and where I am seeing it. How
could aliasing analysis give the compiler permission to skip _loca
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-01 21:16 ---
I am thinking you are volating C++ aliasing rules (though if you convert the
static casts over to placement news it will not work either but that is PR
29286).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3218
With -O2 -ffast-math on Linux/x86-64, I got
Running (#1) 482.sphinx3 ref base o2 default
Error with '/export/spec/src/2006/spec/bin/specinvoke -E -d
/export/spec/src/2006/spec/benchspec/CPU2006/482.sphinx3/run/run_base_ref_o2.
-c 1 -e compare.err -o compare.stdout -f compare.cmd': check file
--- Comment #6 from epperly2 at llnl dot gov 2007-06-01 22:04 ---
Created an attachment (id=13647)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13647&action=view)
An example involving less casting than the previous one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32182
--- Comment #7 from epperly2 at llnl dot gov 2007-06-01 22:12 ---
Created an attachment (id=13648)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13648&action=view)
A further simplified example showing the problem without any C++ casting
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #1 from hjl at lucon dot org 2007-06-01 22:13 ---
Created an attachment (id=13649)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13649&action=view)
A testcase
This testcase has 2 assembly files compiled with -O2 -ffast-math. good.s is
good and bad.s is bad.
--
htt
--- Comment #8 from epperly2 at llnl dot gov 2007-06-01 22:14 ---
I've simplified the sample case that demonstrates the problem, and it has *no*
casting in C++. In C, it casts the result of malloc to the appropriate pointer
type.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32182
--- Comment #2 from hjl at lucon dot org 2007-06-01 23:09 ---
Is that OK to transform
float sf;
...
sf = 500 * sf;
for (i = 0; i < ceplen; i++)
sum[i] *= sf;
to
for (i = 0; i < ceplen; i++)
sum[i] = (sum[i]* 500)*sf;
You can certainly get
--- Comment #3 from rakdver at gcc dot gnu dot org 2007-06-01 23:13 ---
(In reply to comment #2)
> Is that OK to transform
>
> float sf;
> ...
> sf = 500 * sf;
> for (i = 0; i < ceplen; i++)
> sum[i] *= sf;
>
> to
>
> for (i = 0; i < ceplen; i++)
--- Comment #9 from epperly2 at llnl dot gov 2007-06-01 23:24 ---
Created an attachment (id=13650)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13650&action=view)
The function pointer in RefCount_t can be removed too
This is a smaller program that removes a couple function pointe
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-06-01 23:57
---
test_3 works for me on the trunk on i686-linux-gnu.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32182
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-02 00:01 ---
So this is not a wrong code, just a missed optimization.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from mikael dot morin at tele2 dot fr 2007-06-02 00:06
---
Here is an other test case.
program testCode
implicit none
type vec
real, dimension(3) :: coords
end type
integer, parameter :: n = 5
integer :: i
real, d
enable-libgcj-multifile
--with-stabs --enable-hash-synchronization --enable-gc-debug
--enable-interpreter --with-system-zlib --enable-libada --with-tls
--with-cpu=athlon-xp --with-arch=athlon-xp
--enable-stage1-checking=assert,gc,misc,rtl,rtlflag,runtime,tree
Thread model: posix
gcc versio
--- Comment #5 from hjl at lucon dot org 2007-06-02 00:10 ---
(In reply to comment #3)
> (In reply to comment #2)
> > Is that OK to transform
> >
> > float sf;
> > ...
> > sf = 500 * sf;
> > for (i = 0; i < ceplen; i++)
> > sum[i] *= sf;
> >
> > to
> >
--- Comment #3 from danglin at gcc dot gnu dot org 2007-06-02 00:13 ---
After some discussion on the parisc-linux list, this bug was determined
to be in _start. This is pure assembly code and part of glibc. Therefore,
this is not a GCC bug.
--
danglin at gcc dot gnu dot org changed
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-06-02 00:21 ---
(In reply to comment #5)
> We moved a multiply, which is outside of loop in source, into
> a loop. I don't think gcc should do it with any optimization
> flag, including -ffast-math.
Yes but this is still just a mis
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-06-02 00:24 ---
This happens with integers too. That is if you do:
s/float float32/int float32/
You still get the diff:
@@ -184,15 +178,15 @@ cmn_prior (incep, varnorm, nfr, ceplen,
goto ();
:;
- D.1857_156 = nframe_lsm.64_9
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-06-02 00:26 ---
I pasted the wrong part of the diff:
# SMT.14_85 = PHI
:;
sum.6_192 = sum.6_87;
- pretmp.56_197 = sf_77 * 500;
# SMT.14_64 = PHI
# i_74 = PHI
@@ -244,7 +237,8 @@ cmn_prior (incep, varnorm, nfr, cepl
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-06-02 00:37 ---
Here is a simple example:
int f(int i, int *k, int l)
{
int j;
i*=20;
for(j= 0 ;j<10;j++)
k[j] *=i;
}
Where we change the order to be slower by pulling into the loop the multiply by
20. This is a recent r
--- Comment #10 from hjl at lucon dot org 2007-06-02 00:42 ---
(In reply to comment #9)
>
> Where we change the order to be slower by pulling into the loop the multiply
> by
> 20. This is a recent regression too.
>
I will try to track down which checkin causes this.
--
hjl at l
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32183
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-06-02 00:56
---
(In reply to comment #10)
> I will try to track down which checkin causes this.
No need, it was just the addition of DCE. So what is happening now is that DCE
removes the other use of the multiply so reassiocation
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-06-02 00:58
---
Maybe someone should timings without the second reassoc.
Jeff mentioned the loop optimizers cause new reassociations:
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00469.html
And Daniel Berlin agreed with him (but t
--- Comment #6 from patchapp at dberlin dot org 2007-06-02 01:03 ---
Subject: Bug number PR 27078
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-06/msg00076.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #13 from hjl at lucon dot org 2007-06-02 02:00 ---
(In reply to comment #11)
> (In reply to comment #10)
> > I will try to track down which checkin causes this.
> No need, it was just the addition of DCE. So what is happening now is that
> DCE
> removes the other use of the
--- Comment #14 from pinskia at gcc dot gnu dot org 2007-06-02 02:23
---
(In reply to comment #13)
> Has anyone measured impact of adding DCE on SPEC CPU 2000/2006 peformance?
Take a look at:
http://www.suse.de/~gcctest/SPEC/CFP/sb-haydn-head-64-32o-32bit/172_mgrid_recent_big.png
And:
--- Comment #11 from epperly2 at llnl dot gov 2007-06-02 02:52 ---
I tried test_4.tar.bz2 on my home PC whose details are below. I had to change
the definition of size_t to "typedef unsigned long size_t;" in RefCount.c. It
failed just like the other system I tested it with.
> ./compile
When building GCC with -D_FORTIFY_SOURCE we get some warnings which will cause
--enable-werror builds to die. I'm attaching a small patch.
--
Summary: unused result warnings and -werror
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severit
--- Comment #1 from robert at linuxfromscratch dot org 2007-06-02 03:14
---
Created an attachment (id=13651)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13651&action=view)
Patch for fwrite() and getcwd() unused result warnings
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-02 06:16 ---
First you should be using the trunk to create patches.
Second we do check later on if there was an error on the write so I think glibc
is wrong in warning about this case.
--
pinskia at gcc dot gnu dot org change
72 matches
Mail list logo
