hi, all
i want to ask, why free function did not do properly as it expected
(happened in test_malloc.c), the usage memory (using malloc) still exist
please help me, i have another program it, doing malloc continously, and
free it when not needed, this happened several times,
after some looping, my
--- Comment #8 from fang at csl dot cornell dot edu 2007-08-09 02:54
---
Please forgive a wee bit more noise on this matter: (Yes, I know this is
resolved invalid)
If you really insist on using a pointer instead of a valarray or vector, I
suggest taking a technique from the STL and usi
>
>
> --- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-08-06 09:20
> ---
> Without any more news, let's consider this fixed. Douglas, if it so happens
> that your bug wasn't fixed by the patch, please reopen this bug-report.
>
>
> --
>
> fxcoudert at gcc dot gnu dot org ch
/test/gnu/gcc/objdir/./gcc/xgcc -B/test/gnu/gcc/objdir/./gcc/
-B/opt/gnu64/gcc/g
cc-4.3.0/hppa64-hp-hpux11.11/bin/
-B/opt/gnu64/gcc/gcc-4.3.0/hppa64-hp-hpux11.11
/lib/ -isystem /opt/gnu64/gcc/gcc-4.3.0/hppa64-hp-hpux11.11/include -isystem
/op
t/gnu64/gcc/gcc-4.3.0/hppa64-hp-hpux11.11/sys-include -g
/test/gnu/gcc/objdir/./gcc/xgcc -B/test/gnu/gcc/objdir/./gcc/
-B/opt/gnu64/gcc/g
cc-4.3.0/hppa64-hp-hpux11.11/bin/
-B/opt/gnu64/gcc/gcc-4.3.0/hppa64-hp-hpux11.11
/lib/ -isystem /opt/gnu64/gcc/gcc-4.3.0/hppa64-hp-hpux11.11/include -isystem
/op
t/gnu64/gcc/gcc-4.3.0/hppa64-hp-hpux11.11/sys-include -g
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-08-08 23:38
---
Fixed, with mention of C_SIZE_T.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-08 23:36
---
Subject: Bug 32902
Author: fxcoudert
Date: Wed Aug 8 23:36:24 2007
New Revision: 127307
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127307
Log:
PR fortran/32902
* intrinsic.texi (SIZEO
Hi,
AVR backend have peephole2 for optimizing two register move instructions (mov)
in one register pair move instruction (movw):
(define_peephole2 ; movw
[(set (match_operand:QI 0 "even_register_operand" "")
(match_operand:QI 1 "even_register_operand" ""))
(set (match_operand:QI 2 "o
--- Comment #31 from pluto at agmk dot net 2007-08-08 21:50 ---
r84072 introduces an extra movq regression:
+2004-07-04 Richard Henderson <[EMAIL PROTECTED]>
+
+ * rtl.def (ADDRESSOF): Remove.
+ * alias.c (rtx_equal_for_memref_p): Don't handle addressof.
+ (find_base
--- Comment #6 from jim dot turnquist at qlogic dot com 2007-08-08 21:44
---
I am seeing the same thing on powerpc405, gcc=4.2.1, openssl-0.9.8e.
I confirmed what Jann had noticed.
Fails with -O3 & -O2. Finishes with -O1
With -O3:
jturnquist>
/usr/local/itasca/buildtools/26/devtoo
--- Comment #4 from andreast at gcc dot gnu dot org 2007-08-08 20:56
---
and please answer the question from pinskia, how did you configure GCC.
Here on my linuxbox it looks like this:
Configured with: /export/home/tobleran/devel/gcc/head/gcc/configure
--prefix=/export/home/tobleran/d
--- Comment #3 from drow at gcc dot gnu dot org 2007-08-08 20:45 ---
Subject: Re: Not able to get past this error
On Wed, Aug 08, 2007 at 08:01:59PM -, maybe_guess_who_is at yahoo dot com
wrote:
> when to each sub dirctory and ran ./configure then
> went to main dirctory ran ./co
--- Comment #2 from maybe_guess_who_is at yahoo dot com 2007-08-08 20:01
---
Subject: Re: Not able to get past this error
when to each sub dirctory and ran ./configure then
went to main dirctory ran ./configure then make
OK so it worked for you. but that statement does not
help sol
The following code could be optimised significantly better (to help C++ with
inlined generic-style stuff).
# 1 "doopt.cc"
# 1 ""
# 1 ""
# 1 "doopt.cc"
unsigned int fn(unsigned int n, unsigned int dmax) throw()
{
for (unsigned int d = 0; d < dmax; ++d) {
n += d?d:1;
}
return n;
}
There
--- Comment #2 from burnus at gcc dot gnu dot org 2007-08-08 19:01 ---
I still would like to have somewhere a reference to "c_size_t" of the
"iso_c_binding" module as this helps the user to actually code it. It is in any
case more portable than hard coding some value, even though it may
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-08-08 18:58 ---
*** Bug 33026 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-08-08 18:58 ---
*** This bug has been marked as a duplicate of 31899 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-08 18:55 ---
data[i] = (i%2==0) ? new(alloc.value()) unsigned(2) :
new(alloc()) unsigned(1);
D.2395 = value (&alloc);
D.2367 = D.2395;
D.2396 = operator() (&alloc);
uns
--- Comment #1 from dcb314 at hotmail dot com 2007-08-08 18:53 ---
Created an attachment (id=14044)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14044&action=view)
gzipped C++ source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33026
I just tried to compile Suse Linux package enblend-3.0-8
with the GNU C compiler version 4.3 snapshot 20070803.
The compiler said
from enblend.cc:121:
anneal.h: At global scope:
anneal.h:61: internal compiler error: in reference_to_unused, at
dwarf2out.c:10305
Please submit a full bug report,
wit
--- Comment #10 from drow at gcc dot gnu dot org 2007-08-08 18:51 ---
Subject: Re: gcc allows negatively-sized arrays
On Wed, Aug 08, 2007 at 05:34:47PM -, sdyoung at miranda dot org wrote:
> main() {
> int y = 0xFFFD;
> int x[y];
> }
This is roughly equivalent to malloc (
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-08-08 18:42 ---
> fails to compile (array too large).
One is runtime undefined (VLAs) and the other is compile time undefined
(constant size).
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2007-08-08
18:11 ---
Subject: Re: Segmentation fault bootstrapping on HP-UX 11.11
> --- Comment #2 from pda at freeshell dot org 2007-08-08 17:10 ---
> I tried configuring for HP ld as you suggested, but that didn't m
--- Comment #1 from theodore dot papadopoulo at sophia dot inria dot fr
2007-08-08 17:49 ---
Created an attachment (id=14043)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14043&action=view)
The piece of code that shows the problem.
One more note. The bug seems related to the pla
The attached code fails with gcc version 4.3.0 20070703 (experimental). It call
the alloc() function at each iteration producing a memory corruption. I get the
following trace.
grenade-> g++ /tmp/test.C
grenade-> ./a.out
2000
*** glibc detected *** ./a.out: double free or corruption (!prev):
0x00
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-08-08 17:37
---
The following are easy to fix (I have a patch that just needs writing doc, I'll
submit later today): COUNT, IACHAR, ICHAR, INDEX, LBOUND, LEN, LEN_TRIM, SCAN,
SIZE, UBOUND, VERIFY.
This will leave: ACHAR (not so
--- Comment #8 from sdyoung at miranda dot org 2007-08-08 17:34 ---
Consider:
main() {
int x[0xFFFD];
}
fails to compile (array too large).
main() {
int y = 0xFFFD;
int x[y];
}
does compile. Somewhere, your error checking (or lack thereof) for VLAs is
broken. Unless I
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-08-08 17:32
---
4.1 and 4.2 only means closing as WONTFIX, sorry :(
Please reopen if this bug happens with the latest gfortran.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |A
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-08-08 17:29 ---
We can warn if we get a VLA with a "large" unsigned number but that requires
dataflow which means you don't get the warning at -O0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33024
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-08-08 17:27
---
See PR32943 for other examples of testcases that exhibit the same ICE. When
this one is fixed, we should make sure all these have gone.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32933
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-08-08 17:27 ---
>should not segfault (which it does).
Not when you consider the stack pointer will wrap and increase (instead of
decrease) by 8.
Again this is only undefined C99. (this code is invalid C90 and C++98 anyways
as var
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-08-08 17:26
---
*** This bug has been marked as a duplicate of 32933 ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-08-08 17:26
---
*** Bug 32943 has been marked as a duplicate of this bug. ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-08-08 17:25 ---
On i686-apple-darwin, I get the following warning:
t.c:8: warning: format '%d' expects type 'int', but argument 2 has type 'long
unsigned int'
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33024
--- Comment #8 from tapani at chalmers dot se 2007-08-08 17:23 ---
The "rep ret" bug is not athlon64 specific.
I have a similar bug where gcc-4.2.1 generates several "rep ret" instructions,
without me using -march=athlon64. In my case, it seems to be triggered by a
combination of "-ma
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-08-08 17:22
---
I think it is indeed valid.
type :: my_type
integer :: data
end type my_type
interface
subroutine func1(param)
import :: my_type
type(my_type) :: param
end subroutine func1
end in
--- Comment #4 from sdyoung at miranda dot org 2007-08-08 17:18 ---
I should clarify that the assembly below is generated from exactly the code I
included in my original bug report.
Furthermore, if it is being converted to 0xFFFD, then
#include
int main(int argc, char **argv) {
--- Comment #3 from sdyoung at miranda dot org 2007-08-08 17:14 ---
Subject: Re: gcc allows negatively-sized arrays
On Wed, Aug 08, 2007 at 04:55:08PM -, pinskia at gcc dot gnu dot org wrote:
> --- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-08 16:55
> ---
> Th
--- Comment #2 from pda at freeshell dot org 2007-08-08 17:10 ---
I tried configuring for HP ld as you suggested, but that didn't make a
difference. However what seems to have done the trick was bootstrapping with
HP's C compiler rather than gcc-3.3.6. My gcc-3.3.6 has been configured
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-08-08 17:08
---
Why not?
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|un
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-08-08 17:05
---
Target specific, I can't reproduce it on x86_64-linux, with both -m32 and -m64,
even when using valgrind.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-08 16:55 ---
This is not a bug, VLA's size is unsigned so -2 is converted over to
0xFFFD. also sizeof gives back an unsigned type. This is only undefined
behavior anyways.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-08-08 16:50
---
What do you think about the following doc patch? I'm CCing Thomas Koenig
because he's the one who implemented SIZEOF, IIRC.
Index: intrinsic.texi
=
By using an integer variable as the size of an array to be
initialized on the stack, you can trick gcc into accepting
and trying to create a negatively-sized array. The assembly
it generates in such a case seems to indicate it really thinks
it has a negatively-sized array.
E
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu dot
|
--- Comment #11 from pault at gcc dot gnu dot org 2007-08-08 16:34 ---
The patch below fixes this problem and all its variants. It regtests, except
for allocatable_function_1.f90. This runs OK but the number of free's goes up
from 10 to 11; hence the failure on exepecting 10 of them.
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-08-08 15:26
---
Confirmed on x86_64-linux with -m32.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-08-08 15:24
---
I reduced bounds_check_5.f90 to the following:
$ cat o2.f90
INTEGER, POINTER :: x(:)
logical :: l
l = associated(x,x)
end
$ gfortran -fdefault-integer-8 -m32 o2.f90
o2.f90: In function MAIN__:
o2.f90:3: i
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-08-08 14:35 ---
Here is a reduced testcase:
int ctl2_encode_string(
const char *string,
char **result)
{
int length;
static char converted_string[0x104];
int offset;
length = strlen(string);
for(offset = 0; off
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-08 14:23 ---
Some further testing shows:
NAG f95 always wants to have a default kind for SHAPE in c_f_pointer
though the standard allows all kinds.
If I change integer(fgsl_size_t) (fgsl_size_t = c_site_t = 8) into integer(4),
t
--- Comment #4 from saliu at de dot ibm dot com 2007-08-08 13:38 ---
Okey, I have a Red Hat GCC 4.1.1, which might be different from the FSF one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32970
--- Comment #26 from eesrjhc at bath dot ac dot uk 2007-08-08 13:19 ---
(In reply to comment #25)
> Created an attachment (id=14039)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14039&action=view) [edit]
> Prevent fixincludes false positive on gentoo stdio.h wrapper
Very many th
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
gcj (GCC) 4.1.2 20070626 (Red Hat 4.1.2-13)
public class n
{
public static void main(String[] args)
{
throw null;
}
}
$ gcj -C n.java
n.java: In class 'n':
n.java: In method 'n.main(java.lang.String[])':
n.java:5: error: Checked exception null isn't thrown from a try block.
thro
running the testsuite with --target_board=unix\{,-m64\} lets all gnat testcase
for -m64 fail because gnat doesn't support -m64. Is there an easy way to
disable the 64bit tests? A workaround would be to run all test with
--target_board=unix\{,-m64\} first, remove the gnat logs and run it again
witho
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-08 09:22 ---
This works for me and many many other people.
How did you configure GCC?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-08 09:18 ---
Reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33017
--- Comment #3 from pcarlini at suse dot de 2007-08-08 09:18 ---
I was about to reply the same as Andrew's... Mainline is also ok, by the way.
I'm afraid this will end up being a WONTFIX in 4_1-branch because there are
zero chances that those fixes will be backported to the branch...
-
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #2 from cylau at clustertech dot com 2007-08-08 09:13 ---
I have tried the code and it works for gcc 4.2.
But I have to sticked at gcc 4.1.x for compatibility reason
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33021
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-08 09:11 ---
Can you try a later version of GCC as 4.1.x's libstdc++ did not have the fix
for -fvisibility=hidden, see PR 19664 for more details (it was fixed for
4.2.0).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33021
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-08-08 09:07 ---
This should work on the trunk also via the pointer plus branch merge where we
no longer get a multiplication in a pointer type.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32544
--
pcarlini at suse dot de changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33021
--- Comment #9 from aph at gcc dot gnu dot org 2007-08-08 08:48 ---
I've seen this in a few different contexts now.
Looks like the dataflow merge broke _Unwind_fallback_frame_state_for.
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from pixel at mandriva dot com 2007-08-08 08:45 ---
Known to work: 4.1.2 4.3.0
Known to fail: 4.2.1
--
pixel at mandriva dot com changed:
What|Removed |Added
---
73 matches
Mail list logo
