--- Comment #3 from raeburn at raeburn dot org 2007-08-15 06:03 ---
Section 6.7.3 says: If the specification of an array type includes any type
qualifiers, the element type is so-qualified, not the array type. The more I
think about it, the more I think the compiler is technically
--- Comment #1 from raeburn at raeburn dot org 2007-08-15 06:13 ---
Subject: Re: New: Warning when passing a pointer to a const array to a
function that expects a pointer to a non-cast one
On Aug 14, 2007, at 23:45, martin dot ferrari at gmail dot com wrote:
Sorry if I'm
--- Comment #2 from raeburn at raeburn dot org 2007-08-15 06:15 ---
Subject: Re: New: Warning when passing a pointer to a const array to a
function that expects a pointer to a non-cast one
On Aug 14, 2007, at 23:45, martin dot ferrari at gmail dot com wrote:
Sorry if I'm
--- Comment #3 from paolo at gcc dot gnu dot org 2007-08-15 09:06 ---
Subject: Bug 33035
Author: paolo
Date: Wed Aug 15 09:06:42 2007
New Revision: 127508
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127508
Log:
/cp
2007-08-15 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #4 from pcarlini at suse dot de 2007-08-15 09:07 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--
pcarlini at suse dot de changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33035
--- Comment #2 from pcarlini at suse dot de 2007-08-15 09:14 ---
So the problem is already fixed in all the active branches. Thanks, anyway!
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-08-15 09:16
---
OK, I've found the culprit: the variable is created in
gfc_trans_vla_one_sizepos(). However, it makes no sense to issue warnings about
anonymous variables, since these are emitted by the front-end for internal
If I run
gfortran -g gfortran.dg/random_7.f90
valgrind a.out
==27210== Conditional jump or move depends on uninitialised value(s)
==27210==at 0x400A35: MAIN__ (random_7.f90:12)
==27210==by 0x400D0B: main (fmain.c:22)
Using gfortran -g -fdefault-integer-8, ./a.out aborts and
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-08-15 09:54
---
(In reply to comment #0)
==27210== Conditional jump or move depends on uninitialised value(s)
==27210==at 0x400A35: MAIN__ (random_7.f90:12)
==27210==by 0x400D0B: main (fmain.c:22)
Humpf, stupid me,
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-08-15 10:16
---
Fixing as FIXED: I think the -fpack-derived option is used for this very
purpose.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-08-15 10:41
---
cp2k compiles fine on i686-darwin as of today, and I can't see the memory leak
any more, so I'm closing this.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
--- Comment #142 from fxcoudert at gcc dot gnu dot org 2007-08-15 10:44
---
As there's only one bug left here, and it's been worked on, I'm closing this
PR. Hopefully, with the inclusion of cp2k into regression-testers, we won't
need to REOPEN it!
--
fxcoudert at gcc dot gnu dot
--- Comment #1 from pcarlini at suse dot de 2007-08-15 11:22 ---
Cannot be reproduced anymore in mainline, likely because of 33035.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #1 from jakub at gcc dot gnu dot org 2007-08-15 11:43 ---
Caused by http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00571.html
Testing a fix.
--
jakub 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
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #3 from jakub at gcc dot gnu dot org 2007-08-15 12:08 ---
Subject: Bug 32992
Author: jakub
Date: Wed Aug 15 12:08:42 2007
New Revision: 127510
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127510
Log:
PR c++/32992
* typeck.c (check_return_expr): Don't
--- Comment #2 from jakub at gcc dot gnu dot org 2007-08-15 12:11 ---
Subject: Bug 33074
Author: jakub
Date: Wed Aug 15 12:11:38 2007
New Revision: 127511
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127511
Log:
PR middle-end/33074
* emit-rtl.c (try_split): Use
--- Comment #3 from jakub at gcc dot gnu dot org 2007-08-15 12:17 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from pcarlini at suse dot de 2007-08-15 12:35 ---
working on it.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-08-15 12:36
---
Subject: Bug 33077
Author: fxcoudert
Date: Wed Aug 15 12:35:57 2007
New Revision: 127512
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127512
Log:
PR fortran/33077
* intrinsics/random.c
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-15 12:37
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
g++ --version
g++ (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
on debian lenny i386; reproduced on sid amd64 too.
g++ -DUNIX_THREADING -D_THREAD_SAFE -D_REENTRANT -ggdb -Wall -DLINUX -D_POSIX_
SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -DUSE_STRCASECMP -DUSE_STRNCASECMP -g -pg
-c test1.cpp
--- Comment #1 from room_debugs at outgesourced dot org 2007-08-15 12:39
---
Created an attachment (id=14061)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14061action=view)
simple test file failing
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33078
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-08-15 12:39
---
Subject: Bug 29459
Author: fxcoudert
Date: Wed Aug 15 12:39:18 2007
New Revision: 127513
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127513
Log:
PR fortran/29459
* trans.c
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2007-08-15 12:39
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from room_debugs at outgesourced dot org 2007-08-15 12:40
---
Created an attachment (id=14062)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14062action=view)
same code with {}; and not failing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33078
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
Hi!
See
http://gcc.gnu.org/ml/fortran/2007-08/msg00336.html
and
http://gcc.gnu.org/ml/fortran/2007-08/msg00338.html
GFortran seems to handle in a slightly surprising way optional empty strings...
Cheers!
Philippe
PS: a testcase from François-Xavier Coudert
CHARACTER(LEN=1) :: s
s =
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-15 13:11
---
Subject: Bug 32765
Author: fxcoudert
Date: Wed Aug 15 13:11:40 2007
New Revision: 127514
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127514
Log:
PR target/32765
*
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-08-15 13:12
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-08-15 14:05
---
The problem is shared by the TRIM and MIN/MAX. It is demonstrated by:
character(len=1) :: s
character(len=0) :: s0
s =
s0 =
call bar ()
call bar (s)
call bar (s0)
call bar (trim(s))
call bar
--- Comment #2 from schwab at suse dot de 2007-08-15 14:18 ---
Why do you need to special case len == 0? The other strings aren't NUL
terminated either.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33079
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-15 14:22
---
(In reply to comment #2)
Why do you need to special case len == 0? The other strings aren't NUL
terminated either.
The zero-termination is just a detail to avoid keeping memory uninitialized.
The thing is
--- Comment #9 from manu at gcc dot gnu dot org 2007-08-15 14:22 ---
(In reply to comment #8)
*** Bug 17172 has been marked as a duplicate of this bug. ***
I see that the xfail is still there, so how can this be fixed ?
http://gcc.gnu.org/svn/gcc/trunk/gcc/testsuite/gcc.dg/uninit-B.c
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-15 14:38
---
(In reply to comment #1)
* An INTEGER SELECT construct has a CASE that can never be matched as its
lower value is greater than its upper value.
It is also implemented:
$ cat u1.f90
integer :: i, j
--- Comment #6 from manu at gcc dot gnu dot org 2007-08-15 14:41 ---
I am not so sure this is fixed. I need to double check this.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from manu at gcc dot gnu dot org 2007-08-15 15:02 ---
(In reply to comment #12)
Created an attachment (id=13354)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13354action=view) [edit]
patch to preserve uninitialized PHI arguments in CCP
like so. -O -Wall gives
--- Comment #14 from manu at gcc dot gnu dot org 2007-08-15 15:05 ---
Diego, I think this is caused by CCP silently merging UNDEFINED PHI nodes. We
could group similar cases into PR18501, don't you think?
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from manu at gcc dot gnu dot org 2007-08-15 15:21 ---
(In reply to comment #3)
Is it really quite as 22456? That bug is about variable used for initializing
itself, and really strange do-nothing code, while this one is straightforward
use of unitialized variable:
--- Comment #35 from manu at gcc dot gnu dot org 2007-08-15 15:23 ---
If there are not going to be more releases of GCC 4.0 or 4.1, I guess we can
close this, no?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pcarlini at suse dot de 2007-08-15 15:25 ---
This is a duplicate of 33035 and indeed the latter isn't a regression, I'm
fixing that.
*** This bug has been marked as a duplicate of 33035 ***
--
pcarlini at suse dot de changed:
What|Removed
--- Comment #5 from pcarlini at suse dot de 2007-08-15 15:25 ---
*** Bug 31516 has been marked as a duplicate of this bug. ***
--
pcarlini at suse dot de changed:
What|Removed |Added
Add possibility (maybe a configure param) for building libstdc++ (and other gcc
companion libraries) with libgcc linked-in staticaly.
--
Summary: Building libstdc++ with static libgcc
Product: gcc
Version: unknown
Status: UNCONFIRMED
--- Comment #3 from jakub at gcc dot gnu dot org 2007-08-15 15:31 ---
Caused by PR31923.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32596
--- Comment #14 from manu at gcc dot gnu dot org 2007-08-15 15:36 ---
Trying to improve the summary to help spot duplicates.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from mbo dot massimo at tiscali dot it 2007-08-15 15:56
---
Created an attachment (id=14063)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14063action=view)
make log of the build process
log of the make produced during build gcc
--
--- Comment #6 from mbo dot massimo at tiscali dot it 2007-08-15 15:56
---
I tryed to build gcc in a different directory from the source directory and I
obtained the following error:
make[3]: Leaving directory `/home/compiler/build/temporary_build/build-gcc'
Comparing stages 2 and 3
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-15 16:44 ---
Use --disable-shared --enable-shared=libstdc++,
libffi,ada,libada,libjava,libobjc instead.
Anyways you don't want to use the static version of libgcc in many places,
because exceptions will not always work now.
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-08-15 16:40 ---
*** Bug 33078 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pcarlini at suse dot de 2007-08-15 16:37 ---
Feedback not forthcoming...
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-08-15 16:40 ---
This is on purpose.
*** This bug has been marked as a duplicate of 26068 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pcarlini at suse dot de 2007-08-15 17:07 ---
On it.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-15 17:14 ---
gcc version 3.4.5 (mingw special)
Can you try the trunk as it was the officially (for FSF versions) got dwarf2 eh
support recently for win32?
--
pinskia at gcc dot gnu dot org changed:
What
This patch
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00705.html
causes
[EMAIL PROTECTED] rrs]$ /export/gnu/import/rrs/127491/usr/bin/gcc -O
/export/gnu/import/rrs/127491/src/gcc/testsuite/gcc.dg/dfp/convert-bfp-fold.c
/tmp/cc2dvlFs.o: In function `main':
convert-bfp-fold.c:(.text+0x3a):
--- Comment #1 from hjl at lucon dot org 2007-08-15 17:37 ---
I saw it on both Linux/ia32 and Linux/x86-64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33082
--- Comment #13 from andreasmeier80 at gmx dot de 2007-08-15 18:50 ---
Fixed
--
andreasmeier80 at gmx dot de changed:
What|Removed |Added
Status|NEW
--- Comment #2 from craig dot powers at gmail dot com 2007-08-15 19:08
---
(In reply to comment #0)
Came across this head-scratcher in building Qt with GCC 4.2.0. Heavily
simplified version:
foo.cxx:
typedef void (*funcptr)(void);
typedef void GLvoid;
typedef
--- Comment #3 from craig dot powers at gmail dot com 2007-08-15 19:13
---
Looking at CVS for glu.h, the official patch is:
#ifdef __cplusplus
typedef GLvoid (*_GLUfuncptr)();
#else
...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32364
--- Comment #5 from sje at gcc dot gnu dot org 2007-08-15 20:08 ---
Subject: Bug 32963
Author: sje
Date: Wed Aug 15 20:08:43 2007
New Revision: 127523
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127523
Log:
PR target/32963
caller-save.c (reg_save_code): Set
--- Comment #6 from sje at cup dot hp dot com 2007-08-15 20:12 ---
Fixed with patch to caller-save.c
--
sje at cup dot hp dot com changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|ICE in failed_reload, could |[4.3 Regression] ICE in
|not find a spill register
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-15 20:46 ---
Can you try after revision 127523?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33011
When a noreturn function is called, the compiler should emit a jmp
instruction rather than call, because the called function will not return.
Saving callee-save registers in the function prologue also seems unnecessary
since there won't be an epilogue to restore them.
The following example uses
--- Comment #2 from dannysmith at users dot sourceforge dot net 2007-08-16
05:59 ---
This executes with no stack growth on mingw32 4.3.0 with Dwarf2 EH unwind.
Ditto for 4.2.1.
I think this may be related to the deallocation problem reported in PR 19771
Danny
--
dannysmith at
69 matches
Mail list logo
