--- Comment #3 from nathan at gcc dot gnu dot org 2008-05-22 06:33 ---
2008-05-22 Nathan Sidwell [EMAIL PROTECTED]
* lib/dg-pch.exp (dg-pch): Fix if bracing.
--
nathan at gcc dot gnu dot org changed:
What|Removed |Added
When compiling mpfr-2.3.1 with gcc-4.3, one gets the following warning
(among others):
{{{
lngamma.c: In function 'mpfr_lngamma_aux':
lngamma.c:160: warning: 'B' may be used uninitialized in this function
}}}
However, looking at the code shows that this variable cannot be used
uninitialized:
* a
The follwoing code generates warning
warning: 'i' may be used uninitialized in this function
Code is compiled with g++ -O1 -Wall -c file.cpp -o file.o
on x86_64 Fedora Core 6 (2.6.22.9-61.fc6)
with gcc version 4.1.2 20070626 (Red Hat 4.1.2-13)
Changing code in almost any way (like removing
--- Comment #1 from paskhaver at yahoo dot com 2008-05-22 07:47 ---
Created an attachment (id=15668)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15668action=view)
result of -save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36297
--- Comment #2 from paskhaver at yahoo dot com 2008-05-22 07:48 ---
Created an attachment (id=15669)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15669action=view)
result of -save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36297
Compiling the following piece of code shows a memoryleak when investigated with
valgrind.
int main() {
#pragma omp parallel for
for (int i = 100; i = 0; --i) {
}
return 0;
}
Below you find everything you need to know (i think). If something is missing,
let me know.
Regards
Klaas
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-22 08:22 ---
It is most likely the case, that we have to use predicated PHI nodes to detect
that the variable is no unitialized.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from vincent at vinc17 dot org 2008-05-22 08:34 ---
The severity should probably be changed to enhancement because gcc behaves as
documented (well, almost).
What can be done IMHO is:
1. Split the -Wuninitialized into two different warnings: one for which gcc
knows that
With -Waddress (implied by -Wall), I get the following warning when I use the
test a == 0 where a is an array: the address of 'a' will never be NULL. This
behavior is undocumented and inconsistent (see below). Here's a testcase:
int main (void)
{
char a[1], *b;
b = a;
if (a == 0)
return
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-05-22 10:21 ---
A way to tell gcc a variable is not uninitialized is to perform
self-initialization like
int i = i;
this will cause no code generation but inhibits the warning. Other compilers
may warn about this construct of
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-05-22 10:17 ---
Please attach the gtk.i file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36294
--- Comment #2 from irar at gcc dot gnu dot org 2008-05-22 10:41 ---
Subject: Bug 36293
Author: irar
Date: Thu May 22 10:41:00 2008
New Revision: 135756
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135756
Log:
PR tree-optimization/36293
* tree-vect-transform.c
--- Comment #3 from irar at il dot ibm dot com 2008-05-22 10:48 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from irar at gcc dot gnu dot org 2008-05-22 10:40 ---
Subject: Bug 36293
Author: irar
Date: Thu May 22 10:39:44 2008
New Revision: 135755
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135755
Log:
PR tree-optimization/36293
* tree-vect-transform.c
--- Comment #4 from vincent at vinc17 dot org 2008-05-22 11:01 ---
(In reply to comment #3)
A way to tell gcc a variable is not uninitialized is to perform
self-initialization like
int i = i;
This doesn't seem to be valid C code.
this will cause no code generation but inhibits
--- Comment #5 from vincent at vinc17 dot org 2008-05-22 11:23 ---
BTW, the i = i trick, which is guaranteed to be valid and no-op only *after* i
has been initialized doesn't avoid the warning in such a case. I don't know if
this would be a good feature (the main drawback I can see
--- Comment #2 from oliver dot kellogg at eads dot com 2008-05-22 11:23
---
Still happens with 4.4.0 20080522.
Please advise if there is any further info that I could provide
to help track the problem down.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34898
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-22 12:28 ---
One slow leaker of memory for large TUs is the operands_bitmap_obstack from
the operand scanner. From it the stmt annotation loaded and stored symbols
bitmaps are allocated but never freed until after the last
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-05-22 12:35 ---
On the trunk things look different:
tree find ref. vars : 22.59 (13%) usr 1.08 (13%) sys 24.42 (14%) wall
815888 kB (47%) ggc
tree PTA : 1.43 ( 1%) usr 0.08 ( 1%) sys 1.39 ( 1%) wall
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-05-22 12:48 ---
The root of all evil is the following code in add_referenced_var():
/* Scan DECL_INITIAL for pointer variables as they may contain
address arithmetic referencing the address of other
--- Comment #3 from paulbeard at gmail dot com 2008-05-22 14:31 ---
Created an attachment (id=15670)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15670action=view)
gtk.i file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36294
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-05-22 14:39 ---
I added gcc.c-torture/execute/20080522-1.c which points at two problems.
First we need to add referenced vars as they come (there is already
find_new_referenced_vars and some users,
tree-ssa
I ran into this error while attempting building 4.2.4 configured as below. Any
suggestion is appreciated. thanks in advance.
/* configuration */
CFLAGS=-O2 $DEPACK_DIR/gcc-4.2.4/configure --target=mips64vrel-elf \
--prefix=$PREFIX_DIR --enable-languages=c,c++ --disable-__cxa_atexit \
System: Debian 2.6.22.8-mw017
GCC: gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
In the expression below:
- VALUE has type uint32_T
- Y gets a wrong result.
- If VALUE is assigned to an int32_T variable, and the variable is used instead
of VALUE, Y gets the correct result.
See attached
--- Comment #1 from acarmeli at mathworks dot com 2008-05-22 14:43 ---
Created an attachment (id=15671)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15671action=view)
Wrong result if expression is inlined
At the bottom of the file there are:
- Instructions on how to compile
-
As seen on the bottom of eoshift0.c and eoshift2.c:
DEFINE_EOSHIFT (1);
DEFINE_EOSHIFT (2);
DEFINE_EOSHIFT (4);
DEFINE_EOSHIFT (8);
Similar for cshift0.c.
I'll fix this.
--
Summary: cshift and eoshift missing some kind=16 functions
Product: gcc
Version: 4.4.0
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last
While experimenting with limited with as described in John Barnes
Ada 2005 Rationale - Structure and visibility the following problem
came up when trying to call Employees.Assign_Employee from Departments.
The attachment contains the complete program compilation proceeded as follows:
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-05-22 16:10 ---
t = (int) ((long int) U1 * 3 2) + 2;
Y = (int) ((long int) (t * t) * 954437177 29);
if combined is folded to
Y = (int) (((long int) (int) ((long int) U1 * 3 2) * 954437177 +
1908874354) * (long int)
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-05-22 16:11 ---
I will try to have a look.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from aph at gcc dot gnu dot org 2008-05-22 16:21 ---
Subject: Bug 35020
Author: aph
Date: Thu May 22 16:20:55 2008
New Revision: 135771
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135771
Log:
2008-05-22 Andrew Haley [EMAIL PROTECTED]
PR libgcj/35020
Location list created for the following test case is incomplete for parameter
p1:
cc1 -v -dD fs.c -dA -m64 -mcmodel=small -gdwarf-2 -O2 -fno-omit-frame-pointer
-quiet
typedef struct s2 {
unsigned short f1;
unsigned short length;
char data[64];
} s2;
int func(s2 *p1, const char *p2)
{
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-22 17:15 ---
This code also does violates C aliasing rules.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jb at gcc dot gnu dot org 2008-05-22 18:13 ---
The proper solution, which as a side effect would take care of the
combinatorial explosion issue as well, would be to inline these intrinsics. See
also PR 31067.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29600
--- Comment #2 from gcaprino at gmail dot com 2008-05-22 18:15 ---
(In reply to comment #1)
This code also does violates C aliasing rules.
I'm sorry, but I don't understand what you mean.
Do you think there is a problem with the code portion
such that it's not legal, safe C code?
(btw
--- Comment #5 from sje at cup dot hp dot com 2008-05-22 18:52 ---
Created an attachment (id=15672)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15672action=view)
cutdown test case
This smaller test case requires the same options as the original.
--
--
sje at cup dot hp dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-05-22 19:15 ---
As noted in comment #1 variable annotations are a major problem (they are
duplicated for global variables, for each function the variable is referenced
from).
It happens that sharing variable annotations for
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-05-22 19:22 ---
That is, var annotations back to sanity:
tree-dfa.c:150 (create_var_ann) 206016: 0.0% 15094400:
3.2% 142592: 0.1% 0: 0.0% 241297
compared to originally
tree-dfa.c:153
--- Comment #2 from tromey at gcc dot gnu dot org 2008-05-22 19:51 ---
Treelang has been removed.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from tromey at gcc dot gnu dot org 2008-05-22 19:52 ---
Treelang has been removed.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-22 19:57 ---
I can do a make install on the trunk using Windows Vista cygwin just fine.
How did you configure GCC? Did you build in the source tree?
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-22 20:00 ---
if (a == 0)
return 1;
else if (a == (void *) 0)
Those two should warn about being address being zero. a decays to a pointer
type and really a[0].
-- Pinski
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Known to work|
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-05-22 20:02 ---
GCC is running out of memory.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-22 20:07 ---
Is there a reason why you use --enable-version-specific-runtime-libs ?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
Component|libgcj
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-22 20:10 ---
VRP did not exist in 4.0.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[Regression 4.4,4.3] Array |[4.3/4.4 Regression] Array
|valued actual
--- Comment #3 from martin dot drab at fjfi dot cvut dot cz 2008-05-22
21:51 ---
Is using --enable-version-specific-runtime-libs the problem?
Should it not be used? I use it because from time to time I have more than one
version installed at the same time. Do you say that it should not
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-05-22 21:56 ---
Subject: Bug 36302
Author: tkoenig
Date: Thu May 22 21:55:43 2008
New Revision: 135777
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135777
Log:
2008-05-22 Thomas Koenig [EMAIL PROTECTED]
PR
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-05-22 21:59 ---
Fixed on trunk.
Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-22 22:38 ---
I'm sorry, but I don't understand what you mean.
*((unsigned int *)((p1)-data[0])),
You are accessing a char array as an unsigned int which violates C/C++ aliasing
rules and causes undefined code at
--
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=31923
--- Comment #4 from gcaprino at gmail dot com 2008-05-22 23:03 ---
(In reply to comment #3)
I'm sorry, but I don't understand what you mean.
*((unsigned int *)((p1)-data[0])),
You are accessing a char array as an unsigned int which violates C/C++
aliasing
rules and causes
--- Comment #5 from paulbeard at gmail dot com 2008-05-22 23:18 ---
emGCC is running out of memory./em
Oh. I'll add a swapfile and see how that goes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36294
$ gcc --version
gcc (GCC) 4.1.2 20070925 (Red Hat 4.1.2-27)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc -Wall -o reversi reversi.c
--- Comment #1 from jbarbero at cs dot washington dot edu 2008-05-22 23:25
---
Created an attachment (id=15673)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15673action=view)
preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36304
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-22 23:51 ---
This is not a bug as %s scans a string so the last x[7] will overwrite past
the array.
Doing:
char x[9];
int k = i;
sscanf(in[k], %s %s %s %s %s %s %s %s, x[0], x[1], x[2], x[3], x[4],
x[5], x[6], x[7]);
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-22 23:53 ---
This is not a bug as %s scans a string so the last x[7] will overwrite past
the array.
That is it will write a NULL character at x[8] which is one past the array.
--
--- Comment #4 from jbarbero at cs dot washington dot edu 2008-05-22 23:59
---
OK, thanks. Sorry to waste your time.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36304
-linux-gnu
Configured with: ../../../gcc-SVN-20080522/gcc-SVN-20080522/configure
--build=x86_64-pc-linux-gnu --prefix=/usr/local/opt/MDL/opt/gcc-4.4
--exec-prefix=/usr/local/opt/MDL/opt/gcc-4.4 --sysconfdir=/etc
--libdir=/usr/local/opt/MDL/opt/gcc-4.4/lib64
--libexecdir=/usr/local/opt/MDL/opt/gcc-4.4
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-05-23 00:44 ---
Is there a reason why you are supplying all these weird configure options?
--exec-prefix=/usr/local/opt/MDL/opt/gcc-4.4 --sysconfdir=/etc
--libdir=/usr/local/opt/MDL/opt/gcc-4.4/lib64
--- Comment #6 from martin dot drab at fjfi dot cvut dot cz 2008-05-23
00:49 ---
One more thing I've forgotten to mention is that (no matter if the
--enable-version-specific-runtime-libs is there or not) files limits.h and
syslimits.h are not generated into the internal include
--- Comment #7 from martin dot drab at fjfi dot cvut dot cz 2008-05-23
01:00 ---
(In reply to comment #5)
Is there a reason why you are supplying all these weird configure options?
--exec-prefix=/usr/local/opt/MDL/opt/gcc-4.4 --sysconfdir=/etc
--- Comment #8 from martin dot drab at fjfi dot cvut dot cz 2008-05-23
01:09 ---
But I have been using the prefixes like these for ages and it used to work with
4.3 and older versions just fine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36213
--- Comment #7 from mmitchel at gcc dot gnu dot org 2008-05-23 01:29
---
I agree on both points: (1) I should not have marked this P5, and (2) we do not
yet have a test case. Marked as WAITING.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed
the following program does not work properly. The value of y2 should be equal
to the value of y2. The real and the imaginary part of y2 are inverted!!!
program riemann
implicit none
complex (KIND=8) y,y2,imag
real (KIND=8) theta,dtheta,thetamax,Pi
integer
--- Comment #1 from kargl at gcc dot gnu dot org 2008-05-23 03:02 ---
Upgrade your compiler. 4.1.2 is extremely old, and the 4.1.x branch
is no longer maintained. With 4.2.3, the first four values are
0.99950656E+00 0.31410759E-01 0.99950656E+00 0.31410759E-01
0.99802673E+00
Here testcase:
namespace foo {
struct bar {};
}
void f(foo::bar::bar ) {}
--
As you can see instead of foo::bar I wrote
foo::bar::bar, but
g++ -c -Wall test.cpp echo ok
ok
g++ --version
g++ (GCC) 4.1.2 (Gentoo 4.1.2 p1.0.2)
Copyright (C) 2006 Free Software
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-23 05:44 ---
*** This bug has been marked as a duplicate of 11764 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-05-23 05:44 ---
*** Bug 36306 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
74 matches
Mail list logo
