Ive been working on a c program that does the error
condition check in the beginning as follows,
char *fun(str)
const char *str;
{
if (str == NULL) -- Error check, taking the const char variable directly.
printf(Null string \n);
..
}
But the code fails to perform the error
--- Comment #12 from ubizjak at gmail dot com 2007-06-01 06:42 ---
*** Bug 32123 has been marked as a duplicate of this bug. ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #2 from ubizjak at gmail dot com 2007-06-01 06:42 ---
*** This bug has been marked as a duplicate of 26449 ***
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #11 from ubizjak at gmail dot com 2007-06-01 06:42 ---
New test (from PR32123):
Standalone testcase, compile with -O2 -msse2 -mtune=k8:
--cut here--
typedef short __v8hi __attribute__ ((__vector_size__ (16)));
typedef long long __m128i __attribute__ ((__vector_size__
--- Comment #10 from ubizjak at gmail dot com 2007-06-01 06:39 ---
Not fixed, please look for the same failure at PR32123.
start_sequence ();
op = force_operand (SET_SRC (set), reg);
+ if (!op)
+ {
+ end_sequence ();
+ goto
--- Comment #5 from eres at il dot ibm dot com 2007-06-01 06:24 ---
(In reply to comment #3)
*** This bug has been marked as a duplicate of 28684 ***
Related, but a different issue.
I Agree. Bug 28684 mainly deals with the need to redefine
-funsafe-math-optimizations as IEEE
--- 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
--
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
--- 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
--- 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
--- 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 stdio.h
#include string.h
#include malloc.h
int main()
{
char *a=NULL;
char *b=abcd;
--- 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=13644action=view)
The source code showing the potential 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-
--- 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 to
--- 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
--- 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=13645action=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 they
--- 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
--- 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
with_cleanup_expr 0x2aadb4071380
type void_type 0x2aadb3ecf240 void VOID
align 8 symtab 0 alias set -1 canonical type 0x2aadb3ecf240
pointer_to_this pointer_type 0x2aadb3ecf300
--- 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=gccview=revrev=125265
Log:
PR rtl-optimization/31455
* lower-subreg.c
--- 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
--- 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
--- 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
--- 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 enable
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
--- 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=gccview=revrev=125266
Log:
2007-05-28 Benjamin Kosnik [EMAIL PROTECTED]
PR
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
--- 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
--- 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=13646action=view)
tar file containing complete source to reproduce problem
% sha1sum bug32182.tar.bz2
--- 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
--- 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
--- 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).
--
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
--- 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=13647action=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=13648action=view)
A further simplified example showing the problem without any C++ casting
--
--- 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=13649action=view)
A testcase
This testcase has 2 assembly files compiled with -O2 -ffast-math. good.s is
good and bad.s is bad.
--
--- 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=13650action=view)
The function pointer in RefCount_t can be removed too
This is a smaller program that removes a couple function pointer
--- 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,
--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 version 4.3.0 20070601 (experimental
--- 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
for (i = 0; i
--- 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
--- 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
--- 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 bb 8 (L64);
L102:;
- D.1857_156 =
--- 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 SMT.14_183(16)
L106:;
sum.6_192 = sum.6_87;
- pretmp.56_197 = sf_77 * 500;
# SMT.14_64 = PHI SMT.14_184(18), SMT.14_85(17)
# i_74 = PHI
--- 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 ;j10;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
--- 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 lucon
--
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
--- 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
--
--- 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
--- 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=13651action=view)
Patch for fwrite() and getcwd() unused result warnings
--
77 matches
Mail list logo
