free touble
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 memory become 0 free, and it got hang.i did some
investigation, and found there is something strange in free.
anyone got idea what happen and give me a solution?
thanks in advance
Johny Jugianto
using gcc:
$ gcc --version
gcc (GCC) 4.2.0
here is my machine info
$ uname -a
Linux localhost.svr 2.6.9-55.ELsmp #1 SMP Wed May 2 14:28:44 EDT 2007 i686
athlon i386 GNU/Linux
-RESULT: pmap for test_malloc.c after ready to insert-
[EMAIL PROTECTED] ~]$ pmap 5836
5836: ./test_malloc
007ad000 88K r-x-- /lib/ld-2.3.4.so
007c3000 4K r /lib/ld-2.3.4.so
007c4000 4K rw--- /lib/ld-2.3.4.so
007c7000 1176K r-x-- /lib/tls/libc-2.3.4.so
008ed000 8K r /lib/tls/libc-2.3.4.so
008ef000 8K rw--- /lib/tls/libc-2.3.4.so
008f1000 8K rw---[ anon ]
08048000 4K r-x-- /home/nyto/test_malloc
08049000 4K rw--- /home/nyto/test_malloc
08dcb000132K rw---[ anon ]
b7ba2000 3920K rw---[ anon ]
bfff 64K rw---[ stack ]
e000 4K -[ anon ]
total 5424K
-RESULT: pmap for test_malloc.c after done free---
[EMAIL PROTECTED] ~]$ pmap 5836
5836: ./test_malloc
007ad000 88K r-x-- /lib/ld-2.3.4.so
007c3000 4K r /lib/ld-2.3.4.so
007c4000 4K rw--- /lib/ld-2.3.4.so
007c7000 1176K r-x-- /lib/tls/libc-2.3.4.so
008ed000 8K r /lib/tls/libc-2.3.4.so
008ef000 8K rw--- /lib/tls/libc-2.3.4.so
008f1000 8K rw---[ anon ]
08048000 4K r-x-- /home/nyto/test_malloc
08049000 4K rw--- /home/nyto/test_malloc
08dcb000 15708K rw---[ anon ]
b7ba2000 3920K rw---[ anon ]
bfff 64K rw---[ stack ]
e000 4K -[ anon ]
total21000K
-RESULT: pmap for test_malloc2.c after ready to insert
[EMAIL PROTECTED] ~]$ pmap 5841
5841: ./test_malloc2
007ad000 88K r-x-- /lib/ld-2.3.4.so
007c3000 4K r /lib/ld-2.3.4.so
007c4000 4K rw--- /lib/ld-2.3.4.so
007c7000 1176K r-x-- /lib/tls/libc-2.3.4.so
008ed000 8K r /lib/tls/libc-2.3.4.so
008ef000 8K rw--- /lib/tls/libc-2.3.4.so
008f1000 8K rw---[ anon ]
08048000 4K r-x-- /home/nyto/test_malloc2
08049000 4K rw--- /home/nyto/test_malloc2
087c3000132K rw---[ anon ]
b7baa000 3920K rw---[ anon ]
bfee6000 1128K rw---[ stack ]
e000 4K -[ anon ]
total 6488K
-RESULT: pmap for test_malloc2.c after done free--
[EMAIL PROTECTED] ~]$ pmap 5841
5841: ./test_malloc2
007ad000 88K r-x-- /lib/ld-2.3.4.so
007c3000 4K r /lib/ld-2.3.4.so
007c4000 4K rw--- /lib/ld-2.3.4.so
007c7000 1176K r-x-- /lib/tls/libc-2.3.4.so
008ed000 8K r /lib/tls/libc-2.3.4.so
008ef000 8K rw--- /lib/tls/libc-2.3.4.so
008f1000 8K rw---[ anon ]
08048000 4K r-x-- /home/nyto/test_malloc2
08049000 4K rw--- /home/nyto/test_malloc2
087c3000132K rw---[ anon ]
b7baa000 3920K rw---[ anon ]
bfee6000 1128K rw---[ stack ]
e000 4K -[ anon ]
total 6488K
-FILE: test_malloc.c--
#includestdio.h
#includestdlib.h
#includestring.h
#define JUMLAH 100
#define ISI 100
typedef struct _dodol
{
char *abc;
} dodol;
int main()
{
dodol **abc = (dodol**)calloc( JUMLAH, sizeof(dodol*) );
char *lala = (char*)malloc(sizeof(char)*ISI +1);
int i;
char a[10];
for(i=0; iISI; i++)
lala[i] = 'a';
lala[i]=0;
printf(ready to insert\n);
scanf(%s,a);
for(i=0; iJUMLAH; i++) {
abc[i] = (dodol *)malloc(sizeof(dodol));
//free( abc[i] );
}
//printf(ready to free\n);
//scanf(%s,a);
for(i=0; iJUMLAH; i++) {
free( abc[i] );
}
//free(abc);
printf(done free\n);
scanf(%s,a);
return 0;
}
-FILE: test_malloc2.c-
#includestdio.h
#includestdlib.h
#includestring.h
#define JUMLAH 100
#define ISI 100
typedef struct _dodol
{
char *abc;
} dodol;
int main()
{
dodol **abc = (dodol**)calloc( JUMLAH, sizeof(dodol*) );
char *lala = (char*)malloc(sizeof(char)*ISI +1);
int i;
char a[10];
for(i=0; iISI; i++)
lala[i] = 'a';
lala[i]=0;
printf(ready to insert\n);
scanf(%s,a);
for(i=0; iJUMLAH; i++) {
abc[i] = (dodol *)malloc(sizeof(dodol));
free( abc[i] );
}
//printf(ready to free\n);
//scanf(%s,a);
[Bug bootstrap/33031] New: Bootstrap fails on gcc/tree.c
My automated nightly build failed to bootstrap this evening on i386-pc-linux-gnu. This is for trunk rev. 127311, and the error is: /home/fx/gfortran_nightbuild/ibin-20070809/./prev-gcc/xgcc -B/home/fx/gfortran_nightbuild/ibin-20070809/./prev-gcc/ -B/home/fx/gfortran_nightbuild/irun-20070809/i386-pc-linux-gnu/bin/ -c -g -O2 -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror-DHAVE_CONFIG_H -I. -I. -I/home/fx/gfortran_nightbuild/trunk/gcc -I/home/fx/gfortran_nightbuild/trunk/gcc/. -I/home/fx/gfortran_nightbuild/trunk/gcc/../include -I/home/fx/gfortran_nightbuild/trunk/gcc/../libcpp/include -I/home/fx/gfortran_nightbuild/software/include -I/home/fx/gfortran_nightbuild/trunk/gcc/../libdecnumber -I/home/fx/gfortran_nightbuild/trunk/gcc/../libdecnumber/bid -I../libdecnumber /home/fx/gfortran_nightbuild/trunk/gcc/tree.c -o tree.o cc1: warnings being treated as errors /home/fx/gfortran_nightbuild/trunk/gcc/tree.c: In function 'initializer_zerop': /home/fx/gfortran_nightbuild/trunk/gcc/tree.c:7694: error: passing argument 1 of 'fixed_zerop' discards qualifiers from pointer target type make[3]: *** [tree.o] Error 1 make[3]: Leaving directory `/home/fx/gfortran_nightbuild/ibin-20070809/gcc' make[2]: *** [all-stage2-gcc] Error 2 -- Summary: Bootstrap fails on gcc/tree.c Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: build Severity: blocker Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org GCC build triplet: i386-pc-linux-gnu GCC host triplet: i386-pc-linux-gnu GCC target triplet: i386-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33031
[Bug tree-optimization/32941] [4.3 regression] Bootstrap comparison failure
--- Comment #4 from andreasmeier80 at gmx dot de 2007-08-09 08:43 --- It worked well with r126900, but did not with r126976 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32941
[Bug bootstrap/33031] Bootstrap fails on gcc/tree.c
--- Comment #1 from irar at il dot ibm dot com 2007-08-09 08:44 --- I got this too on x86_64-linux. I guess the guilty patch is r127306 | chaoyingfu | 2007-08-09 01:29:12 +0300 (Thu, 09 Aug 2007) | 213 lines since it added the function fixed_zerop: * tree.c ... (fixed_zerop): New function. Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33031
[Bug c/33033] New: FAIL: gcc.dg/20061124-1.c: undefined reference to `__sync_add_and_fetch_2'
Aurora SPARC Linux release 2.99 (Angel)/TI UltraSparc IIi (Sabre) sun4u: binutils-2.17.50.0.3-6.sparc.sparc bison-2.3-2.1.sparc dejagnu-1.4.4-5.1.noarch expect-5.43.0-5.1.sparc gcc-4.1.1-30.1.sparc glibc-2.5-3.1.sparcv9 glibc-2.5-3.1.sparc64 glibc-devel-2.5-3.1.sparc glibc-devel-2.5-3.1.sparc64 glibc-headers-2.5-3.1.sparc gmp-2.4.1 (local build from gcc's infrastructure) mpfr-2.2.1 (local build from gcc's infrastructure) kernel-2.6.21-1.3149.al3.12.sparc64 libgcc-4.1.1-30.1.sparc libgcc-4.1.1-30.1.sparc64 libstdc++-4.1.1-30.1.sparc libstdc++-4.1.1-30.1.sparc64 libstdc++-devel-4.1.1-30.1.sparc libstdc++-devel-4.1.1-30.1.sparc64 make-3.81-1.1.sparc tcl-8.4.13-3.al3.sparc LAST_UPDATED: Mon Aug 6 09:19:03 UTC 2007 (revision 127237) test results posted at http://gcc.gnu.org/ml/gcc-testresults/2007-08/msg00248.html In the gcc testsuite, (--with-cpu=v7) I get this failure: PASS: gcc.dg/20061026.c (test for excess errors) Executing on host: /usr/local/src/branch/objdir/gcc/xgcc -B/usr/local/src/branch/objdir/gcc/ /usr/local/src/branch/gcc/gcc/testsuite/gcc.dg/20061124-1.c-ansi -pedantic-errors -fno-show-column -lm -o ./20061124-1.exe(timeout = 1200) /tmp/cc0xZZ4Z.o: In function `main': 20061124-1.c:(.text+0x14): undefined reference to `__sync_add_and_fetch_2' collect2: ld returned 1 exit status compiler exited with status 1 output is: /tmp/cc0xZZ4Z.o: In function `main': 20061124-1.c:(.text+0x14): undefined reference to `__sync_add_and_fetch_2' collect2: ld returned 1 exit status FAIL: gcc.dg/20061124-1.c (test for excess errors) Excess errors: 20061124-1.c:(.text+0x14): undefined reference to `__sync_add_and_fetch_2' WARNING: gcc.dg/20061124-1.c compilation failed to produce executable -- Summary: FAIL: gcc.dg/20061124-1.c: undefined reference to `__sync_add_and_fetch_2' Product: gcc Version: 4.2.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: christian dot joensson at gmail dot com GCC build triplet: sparc64-unknown-linu-gnu GCC host triplet: sparc64-unknown-linu-gnu GCC target triplet: sparc64-unknown-linu-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33033
[Bug c/33034] New: FAIL: gcc.c-torture/unsorted/DFcmp.c SFset.c: internal compiler error: in extract_insn, at recog.c:2077
Aurora SPARC Linux release 2.99 (Angel)/TI UltraSparc IIi (Sabre) sun4u: binutils-2.17.50.0.3-6.sparc.sparc bison-2.3-2.1.sparc dejagnu-1.4.4-5.1.noarch expect-5.43.0-5.1.sparc gcc-4.1.1-30.1.sparc glibc-2.5-3.1.sparcv9 glibc-2.5-3.1.sparc64 glibc-devel-2.5-3.1.sparc glibc-devel-2.5-3.1.sparc64 glibc-headers-2.5-3.1.sparc gmp-2.4.1 (local build from gcc's infrastructure) mpfr-2.2.1 (local build from gcc's infrastructure) kernel-2.6.21-1.3149.al3.12.sparc64 libgcc-4.1.1-30.1.sparc libgcc-4.1.1-30.1.sparc64 libstdc++-4.1.1-30.1.sparc libstdc++-4.1.1-30.1.sparc64 libstdc++-devel-4.1.1-30.1.sparc libstdc++-devel-4.1.1-30.1.sparc64 make-3.81-1.1.sparc tcl-8.4.13-3.al3.sparc LAST_UPDATED: Mon Aug 6 09:19:03 UTC 2007 (revision 127237) test results posted at http://gcc.gnu.org/ml/gcc-testresults/2007-08/msg00248.html In the gcc testsuite, (--with-cpu=v7, but also -m64), I get these failures: Executing on host: /usr/local/src/branch/objdir/gcc/xgcc -B/usr/local/src/branch/objdir/gcc/ -w -O1 -fno-show-column -c -m64 -o /usr/local/src/branch/objdir/gcc/testsuite/gcc/DFcmp.o /usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/unsorted/DFcmp.c (timeout = 1200) /usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/unsorted/DFcmp.c: In function 'reg0limm1': /usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/unsorted/DFcmp.c:39: error: unrecognizable insn: (insn 37 14 15 2 (set (reg:DI 42 %f10) (mem/u/c/i:DI (symbol_ref/u:DI (*.LLC1) [flags 0x2]) [0 S8 A64])) -1 (nil) (nil)) /usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/unsorted/DFcmp.c:39: internal compiler error: in extract_insn, at recog.c:2077 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. compiler exited with status 1 output is: /usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/unsorted/DFcmp.c: In function 'reg0limm1': /usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/unsorted/DFcmp.c:39: error: unrecognizable insn: (insn 37 14 15 2 (set (reg:DI 42 %f10) (mem/u/c/i:DI (symbol_ref/u:DI (*.LLC1) [flags 0x2]) [0 S8 A64])) -1 (nil) (nil)) /usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/unsorted/DFcmp.c:39: internal compiler error: in extract_insn, at recog.c:2077 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. FAIL: gcc.c-torture/unsorted/DFcmp.c, -O1 (internal compiler error) Executing on host: /usr/local/src/branch/objdir/gcc/xgcc -B/usr/local/src/branch/objdir/gcc/ -w -O2 -fno-show-column -c -m64 -o /usr/local/src/branch/objdir/gcc/testsuite/gcc/DFcmp.o /usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/unsorted/DFcmp.c (timeout = 1200) /usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/unsorted/DFcmp.c: In function 'reg0limm1': /usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/unsorted/DFcmp.c:39: error: unrecognizable insn: (insn 39 14 15 2 (set (reg:DI 42 %f10) (mem/u/c/i:DI (symbol_ref/u:DI (*.LLC1) [flags 0x2]) [8 S8 A64])) -1 (nil) (nil)) /usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/unsorted/DFcmp.c:39: internal compiler error: in extract_insn, at recog.c:2077 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. compiler exited with status 1 output is: /usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/unsorted/DFcmp.c: In function 'reg0limm1': /usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/unsorted/DFcmp.c:39: error: unrecognizable insn: (insn 39 14 15 2 (set (reg:DI 42 %f10) (mem/u/c/i:DI (symbol_ref/u:DI (*.LLC1) [flags 0x2]) [8 S8 A64])) -1 (nil) (nil)) /usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/unsorted/DFcmp.c:39: internal compiler error: in extract_insn, at recog.c:2077 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. FAIL: gcc.c-torture/unsorted/DFcmp.c, -O2 (internal compiler error) Executing on host: /usr/local/src/branch/objdir/gcc/xgcc -B/usr/local/src/branch/objdir/gcc/ -w -O3 -fomit-frame-pointer -fno-show-column -c -m64 -o /usr/local/src/branch/objdir/gcc/testsuite/gcc/DFcmp.o /usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/unsorted/DFcmp.c (timeout = 1200) /usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/unsorted/DFcmp.c: In function 'reg0limm1': /usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/unsorted/DFcmp.c:39: error: unrecognizable insn: (insn 39 14 15 2 (set (reg:DI 42 %f10) (mem/u/c/i:DI (symbol_ref/u:DI (*.LLC1) [flags 0x2]) [8 S8 A64])) -1 (nil) (nil)) /usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/unsorted/DFcmp.c:39: internal compiler error: in extract_insn, at recog.c:2077 Please submit a full bug report, with preprocessed source if appropriate. See
[Bug middle-end/33030] libgcc2.c:1890: internal compiler error: in local_cprop_pass, at gcse.c:3236
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-09 09:08 --- *** This bug has been marked as a duplicate of 33029 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE Summary|libgcc2.c:1890: internal|libgcc2.c:1890: internal |compiler error: in local_cpr|compiler error: in |op_pass, at gcse.c:3236 |local_cprop_pass, at ||gcse.c:3236 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33030
[Bug middle-end/33029] libgcc2.c:1890: internal compiler error: in local_cpr op_pass, at gcse.c:3236
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-09 09:08 --- *** Bug 33030 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33029
[Bug middle-end/33029] [4.3 Regression] libgcc2.c:1890: internal compiler error: in local_cprop_pass, at gcse.c:3236
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||build, ice-on-valid-code Summary|libgcc2.c:1890: internal|[4.3 Regression] |compiler error: in local_cpr|libgcc2.c:1890: internal |op_pass, at gcse.c:3236 |compiler error: in ||local_cprop_pass, at ||gcse.c:3236 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33029
[Bug c++/33025] [4.3 Regression] Wrong calling of placement new with conditionals
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-08-09 09:18 --- Because placement new is required to reproduce this bug and the front-end is where the broken code happens already, then the patch to fix PR 29286 is the cause. The problem is in build_new_1 where we create a temp variable to hold the placement variable is initialized with the value of the placement new which is wrong as we don't get that initialization inside the conditional. You can most likely reduce this testcase further using printf instead of cout and saying if you call operator() too many times to abort. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||ian at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|x86_64-unknown-linux-gnu| GCC host triplet|x86_64-unknown-linux-gnu| GCC target triplet|x86_64-unknown-linux-gnu| Last reconfirmed|-00-00 00:00:00 |2007-08-09 09:18:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33025
[Bug fortran/31629] option to make module entities PRIVATE by default
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-08-09 09:35
---
What about the following:
Index: gfortran.h
===
--- gfortran.h (revision 127224)
+++ gfortran.h (working copy)
@@ -1865,6 +1865,7 @@ typedef struct
int flag_d_lines;
int flag_openmp;
int flag_sign_zero;
+ int flag_module_private;
int fpe;
Index: lang.opt
===
--- lang.opt(revision 127224)
+++ lang.opt(working copy)
@@ -212,6 +212,10 @@ fmax-stack-var-size=
Fortran RejectNegative Joined UInteger
-fmax-stack-var-size=n Size in bytes of the largest array that will be
put on the stack
+fmodule-private
+Fortran
+Set default accessibility of module entities to PRIVATE.
+
fopenmp
Fortran
Enable OpenMP
Index: module.c
===
--- module.c(revision 127224)
+++ module.c(working copy)
@@ -3714,7 +3714,10 @@ gfc_check_access (gfc_access specific_ac
if (specific_access == ACCESS_PRIVATE)
return FALSE;
- return default_access != ACCESS_PRIVATE;
+ if (gfc_option.flag_module_private)
+return default_access == ACCESS_PUBLIC;
+ else
+return default_access != ACCESS_PRIVATE;
}
Index: options.c
===
--- options.c (revision 127224)
+++ options.c (working copy)
@@ -93,6 +93,7 @@ gfc_init_options (unsigned int argc ATTR
gfc_option.flag_preprocessed = 0;
gfc_option.flag_automatic = 1;
gfc_option.flag_backslash = 1;
+ gfc_option.flag_module_private = 0;
gfc_option.flag_backtrace = 0;
gfc_option.flag_allow_leading_underscore = 0;
gfc_option.flag_dump_core = 0;
@@ -575,6 +576,10 @@ gfc_handle_option (size_t scode, const c
gfc_option.flag_max_stack_var_size = value;
break;
+case OPT_fmodule_private:
+ gfc_option.flag_module_private = value;
+ break;
+
case OPT_frange_check:
gfc_option.flag_range_check = value;
break;
Index: invoke.texi
===
--- invoke.texi (revision 127228)
+++ invoke.texi (working copy)
@@ -121,7 +121,7 @@ by type. Explanations are in the follow
[EMAIL PROTECTED] -ffixed-line-length-none @gol
[EMAIL PROTECTED] -ffree-line-length-none @gol
-fdefault-double-8 -fdefault-integer-8 -fdefault-real-8 @gol
--fcray-pointer -fopenmp -frange-check -fno-backslash }
+-fcray-pointer -fopenmp -frange-check -fno-backslash -fmodule-private}
@item Error and Warning Options
@xref{Error and Warning Options,,Options to request or suppress errors
@@ -238,6 +238,14 @@ Allow @samp{$} as a valid character in a
Change the interpretation of backslashes in string literals from
``C-style'' escape characters to a single backslash character.
[EMAIL PROTECTED] -fmodule-private
[EMAIL PROTECTED] @code{fmodule-private}
[EMAIL PROTECTED] module entities
[EMAIL PROTECTED] private
+Set the default accessibility of module entities to @code{PRIVATE}.
+Use-associated entities will not be accessible unless they are explicitly
+declared as @code{PUBLIC}.
+
@item [EMAIL PROTECTED]
@opindex @[EMAIL PROTECTED]
@cindex file format, fixed
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31629
[Bug middle-end/32820] optimizer malfunction when mixed with asm statements
--- Comment #4 from jbuehler at spirentcom dot com 2007-08-09 11:38 --- Created an attachment (id=14045) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14045action=view) gcc 4.0.4 global register variable optimizer patch The attached patch fixes the optimizer bug for gcc 4.0.4 and allows GHC 6.6.1 to be compiled with optimization turned on. The problem is that lifetime analysis is marking global registers as REG_UNUSED and then the combiner pass is eliminating them. The fix is to not mark global registers as unused. The fix is based on a review of the flow.c code for gcc 4.2.0. Code was added to flow.c somewhere after 4.0.4 to handle stack registers and no mark them as REG_UNUSED. This patch merely mimics stack register handling in flow.c for global registers. I am not a gcc expert and make no claims for the correctness of this patch -- it does fix my ghc compile though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32820
[Bug c++/33035] New: ICE on local class destructor. Regression?
gcc-4.3-20070727 fails with ICE on code:
---
templateclass A
struct a {
templateclass B
struct b {
templateclass C
void f()
{
struct g
{
~g() {}//--here
};
}
};
};
---
Compiler output is:
---
G++ -v -save-temps gcc-err.cpp
Using built-in specs.
Target: i686-pc-mingw32
Configured with: ../gcc-4.3-20070727/configure --disable-bootstrap
--enable-languages=c,c++ --with-gcc --with-gnu-ld --with-gnu-as --with-dwarf2
--without-stabs --disable-sjlj-exceptions --prefix=/mingw
--libexecdir=/mingw/lib --disable-werror --enable-threads --disable-nls
--disable-win32-registry --disable-shared --disable-libssp
--disable-libstdcxx-debug --disable-concept-checks
Thread model: win32
gcc version 4.3.0 20070727 (experimental)
d:/TOOLS/GCC/lib/gcc/i686-pc-mingw32/4.3.0/cc1plus.exe -E -quiet -v -iprefix
d:\tools\gcc\bin\../lib/gcc/i686-pc-mingw32/4.3.0/ gcc-err.cpp -mtune=generic
-fpch-preprocess -o gcc-err.ii
#include ... search starts here:
#include ... search starts here:
d:\TOOLS\GCC/include
d:\TOOLS\GCC/local/include
d:\TOOLS\GCC/win32api/include
d:/prj/libs/include
d:/prj/libs/boost
d:\tools\gcc\bin\../lib/gcc/i686-pc-mingw32/4.3.0/include
d:\tools\gcc\bin\../lib/gcc/i686-pc-mingw32/4.3.0/include-fixed
d:/TOOLS/GCC/include/c++/4.3.0
d:/TOOLS/GCC/include/c++/4.3.0/i686-pc-mingw32
d:/TOOLS/GCC/include/c++/4.3.0/backward
d:/TOOLS/GCC/include
d:/TOOLS/GCC/include
d:/TOOLS/GCC/lib/gcc/i686-pc-mingw32/4.3.0/include
d:/TOOLS/GCC/lib/gcc/i686-pc-mingw32/4.3.0/include-fixed
d:/TOOLS/GCC/lib/gcc/i686-pc-mingw32/4.3.0/include-fixed
d:/TOOLS/GCC/include
End of search list.
d:/TOOLS/GCC/lib/gcc/i686-pc-mingw32/4.3.0/cc1plus.exe -fpreprocessed
gcc-err.ii -quiet -dumpbase gcc-err.cpp -mtune=generic -auxbase gcc-err
-version -o gcc-err.s
GNU C++ version 4.3.0 20070727 (experimental) (i686-pc-mingw32)
compiled by GNU C version 4.2.0, GMP version 4.2.1, MPFR version 2.2.0.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: b6f7d618f50d2b0792a732058b53d781
gcc-err.cpp: In member function 'void aA::bB::f()':
gcc-err.cpp:10: internal compiler error: tree check: expected class 'type',
have 'declaration' (function_decl) in push_template_decl_real, at cp/pt.c:3917
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
---
3.4.2, 4.1.1 and 4.2.0 compile it well.
--
Summary: ICE on local class destructor. Regression?
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vasili dot burdo at gmail dot com
GCC build triplet: i686-pc-mingw32
GCC host triplet: i686-pc-mingw32
GCC target triplet: i686-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33035
[Bug c++/33025] [4.3 Regression] Wrong calling of placement new with conditionals
--- Comment #4 from theodore dot papadopoulo at sophia dot inria dot fr 2007-08-09 12:02 --- Created an attachment (id=14046) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14046action=view) A new more minimal test case The same program was still working with gcc version 4.3.0 20070608 (experimental). This reduces slightly the bug introduction window even though it looks that Andrew already spotted the exact patch that introduced the bug (By the way thank's a lot!!). grenade- /usr/local/gcc-4.3/bin/g++ Bug.C grenade- /usr/local/gcc-4.3/bin/g++ -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /user/papadop/laptop/home/src/Cvs/Refs/gcc/gcc-svn-ref/trunk/configure --prefix=/usr/local/gcc-4.3/ --enable-languages=c,c++,fortran --enable-__cxa_atexit Thread model: posix gcc version 4.3.0 20070703 (experimental) grenade- ./a.out Abort grenade- g++ Bug.C grenade- g++ -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.1 20070105 (Red Hat 4.1.1-51) grenade- ./a.out grenade- /usr/local/gcc-4.3.old/bin/g++ Bug.C grenade- /usr/local/gcc-4.3.old/bin/g++ -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /user/papadop/laptop/home/src/Cvs/Refs/gcc/gcc-svn-ref/trunk/configure --prefix=/usr/local/gcc-4.3/ --enable-languages=c,c++,fortran --enable-__cxa_atexit Thread model: posix gcc version 4.3.0 20070608 (experimental) grenade- ./a.out -- theodore dot papadopoulo at sophia dot inria dot fr changed: What|Removed |Added Attachment #14043|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33025
[Bug tree-optimization/32941] [4.3 regression] Bootstrap comparison failure
--- Comment #5 from andreasmeier80 at gmx dot de 2007-08-09 12:52 --- It worked well with r126941, but did not with r126959 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32941
[Bug target/33036] New: LINUX_DYNAMIC_LINKER undefined in gcc-4.2.1/gcc/config/arm/linux-elf.h
Hello! The undefined variable LINUX_DYNAMIC_LINKER, included in the Variable LINK_SPEC in the file gcc-4.2.1/gcc/config/arm/linux-elf.h lines 56-68 causes an error during compilation of gcc-4.2.1/gcc/gcc.c at line 740. The error was: path/gcc-4.2.1/gcc/gcc.c:740: error: expected , or ; before LINUX_DYNAMIC_LINKER Defining this variable fixed the compilation problem. I assume, a reasonable value would be e.g. #define GLIBC_DYNAMIC_LINKER /lib/ld-linux.so.2 #define LINUX_DYNAMIC_LINKER GLIBC_DYNAMIC_LINKER and will solve this problem at once. I looked up, how this variable was defined in other architecture header files e.g. at gcc-4.2.1/gcc/config/alpha/linux-elf.h. There is the dynamic linker of uClibc (/lib/ld-uClibc.so.0) used as well. Maybe it is more reasonable to use the same definition like in the alpha header file. Also, there is another bug, caused by the undefined funcion or macro LINUX_TARGET_OS_CPP_BUILTINS() in the same file (gcc-4.2.1/gcc/config/alpha/linux-elf.h) line 73, which caused a compilation error in file gcc-4.2.1/gcc/c-cppbuiltin.c line 559: The error was: c-cppbuiltin.o: In function `c_cpp_builtins': path/gcc-4.2.1/gcc/c-cppbuiltin.c:559: undefined reference to `LINUX_TARGET_OS_CPP_BUILTINS' Before I posted this bug, I had a look at the current development tree snapshot (file gcc-4.3-20070803.tar.bz2) and found the same header file. (with minor change in commentaries) The configuration was: configure --prefix=/prefix --build=i686-pc-linuc-gnu --host=i686-pc-linuc-gnu --target=arm-none-uclinux --disable-nls --disable-shared --enable-languages=c --disable-threads --disable-tls --with-sysroot=/prefix/sysroot --with-gnu-as --with-gnu-ld --without-headers If you need further information, please feel free to contact me by email: [EMAIL PROTECTED] Best regards Andreas Gajda -- Summary: LINUX_DYNAMIC_LINKER undefined in gcc- 4.2.1/gcc/config/arm/linux-elf.h Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: andreas_gajda at web dot de GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: arm-none-uclinux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33036
[Bug middle-end/33007] [4.3 Regression] builtin lround doesn't work
--- Comment #10 from hjl at lucon dot org 2007-08-09 14:15 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00450.html -- hjl at lucon dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||08/msg00450.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33007
[Bug fortran/33037] New: TRANSFER intrinsic is context sensitive
When using the transfer intrinsic to convert a character string to an array of
integers, and the string does not fit exactly into the integer array data
block, the resultant integer array is scope dependent, with the same code
giving a different resultant integer array in different subroutines/program
units. Basically, the transfer function is not deterministic in the case where
the source data is smaller than the destination data.
There is a small program below to demonstrate the issue. The integer array is
printed twice, and (on my machine) is different each time. The code producing
the two sets of output is exactly the same, but in the first case the code is
embedded in the main program, and in the other case in a subroutine.
I do not have a copy of the standard, but I cannot imagine that this behavior
is correct. The problem arises even if the destination array is initialized to
zero (as shown in the example).
module DataMod
type Byte
character(len=1) :: singleByte
end type
end module
subroutine sub()
use DataMod
integer :: i(1), intarray(4), j
character(len=15) :: str1
type (Byte) :: bytes(15)
type (Byte) :: byteProt(1)
bytes = transfer('123456789012345', byteProt)
print *, bytes(:)%singleByte
intarray = 0
intarray = transfer(bytes, i)
print *, intarray
end subroutine
program test
use DataMod
integer :: i(1), intarray(4), j
character(len=15) :: str1
type (Byte) :: bytes(15)
type (Byte) :: byteProt(1)
bytes = transfer('123456789012345', byteProt)
print *, bytes(:)%singleByte
intarray = 0
intarray = transfer(bytes, i)
print *, intarray
call sub()
end program
--
Summary: TRANSFER intrinsic is context sensitive
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drewmccormack at mac dot com
GCC build triplet: gcc version 4.3.0 20070511 (experimental)
GCC host triplet: powerpc-apple-darwin8.9.0
GCC target triplet: powerpc-apple-darwin8.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33037
[Bug libfortran/33038] New: Unsatisfied symbol lroundl in file libgfortran.sl
/test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../ /test/gnu/gcc/gcc/gcc/testsui te/gfortran.dg/PR19754_2.f90 -O1 -pedantic-errors -L/test/gnu/gcc/objdir/hp pa64-hp-hpux11.11/./libgfortran/.libs -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11 /./libgfortran/.libs -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libiberty -lm -o ./PR19754_2.exe(timeout = 300) ld: (Warning) Unsatisfied symbol lroundl in file /test/gnu/gcc/objdir/hppa64-h p-hpux11.11/./libgfortran/.libs/libgfortran.sl 1 warnings. output is: ld: (Warning) Unsatisfied symbol lroundl in file /test/gnu/gcc/objdir/hppa64-h p-hpux11.11/./libgfortran/.libs/libgfortran.sl 1 warnings. FAIL: gfortran.dg/PR19754_2.f90 -O1 (test for excess errors) I see in the build log: checking for lroundl in -lm... no -- Summary: Unsatisfied symbol lroundl in file libgfortran.sl Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa64-hp-hpux11.11 GCC host triplet: hppa64-hp-hpux11.11 GCC target triplet: hppa64-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33038
[Bug bootstrap/33031] Bootstrap fails on gcc/tree.c
--- Comment #2 from matz at gcc dot gnu dot org 2007-08-09 15:50 --- Fixed with my checkin of rev 127316. -- matz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33031
[Bug fortran/33037] TRANSFER intrinsic is context sensitive
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-09 15:50 --- Could you please tell us your gfortran version? (gfortran -v, the gcc-version line is of most interest.) Not that TRANSFER is free of bugs, but it produces here 4.3.0 20070808 (x86_64-unknown-linux-gnu) the same result as NAG f95. NAG f95 warns: Warning: a.f90, line 17: Intrinsic TRANSFER has partly undefined result Warning: a.f90, line 32: Intrinsic TRANSFER has partly undefined result If one runs valgrind on the a.out as produced by gfortran (-m64; no errors shown for -m32): ==21023== Conditional jump or move depends on uninitialised value(s) ==21023==at 0x4E3DD77: _gfortrani_gfc_itoa (error.c:138) ==21023==by 0x4EC0AA3: write_integer (write.c:1343) ==21023==by 0x4EC2BCA: _gfortrani_list_formatted_write (write.c:1541) ==21023==by 0x4EBA76A: _gfortran_transfer_array (transfer.c:1513) ==21023==by 0x40138E: MAIN__ (in /dev/shm/a.out) ==21023==by 0x4013DB: main (fmain.c:22) (and some more of these kind). [Actually, g95 has a similar valgrind output; for NAG f95, ifort and openf95 valgrind finds no error.] This PR could be related to PR 31610. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33037
[Bug fortran/33037] TRANSFER intrinsic is context sensitive
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-09 15:59 --- This is undefined code, when I rewrote most of the transfer code for scalars, I had asked what happens when the sizes did not match and everyone I asked said it was undefined behavior. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33037
[Bug c++/32984] add checking for array new delete
--- Comment #9 from dcb314 at hotmail dot com 2007-08-09 16:03 --- (In reply to comment #8) I suggest taking a technique from the STL and using an auto_array class In practice, I find both STL and Boost are rarely used. Such advanced tools are fine for experienced C++ programmers. For ex-Fortran programmers, new to C++, making their first steps in C++ manual memory management, the news that the C++ compiler will silently eat certainly wrong code is worrying. Hence my bug report. Some newbie C++ programmers need more hand-holding than traditional C++ compilers provide. And as C++ becomes more and more mainstream, this will be more and more true. The bug report remains at resolved wontfix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32984
[Bug tree-optimization/32941] [4.3 regression] Bootstrap comparison failure
--- Comment #6 from andreasmeier80 at gmx dot de 2007-08-09 16:07 --- It worked well with r126947, but did not with r126951 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32941
[Bug fortran/33039] New: Read NAMELIST: reads wrong namelist name
This has probably already been submitted by Daniel Franke or Jerry DeLisle. I am just trying to see if I can work this system. FORTRAN NAMELIST Run Time Problem The FORTRAN statement READ(5, nml=CODE) should read through the input file (connected to device number 5) until it finds a namelist with the name 'CODE', and then read/process that one namelist. On the next call to this read statement, the program should read further into the input file to find the next occurrence of the name 'CODE'. This was the behaviour from the IBM and HP FORTRAN 77 compilers. It is also the behaviour from the open source g77 compiler. A namelist with name 'CODEone', 'CODEtwo', or 'CODEx' is treated as having a different name, on the basis that the name ends at the trailing 'space' delimiter. A gfortran compiled program appears to read these names and conclude that since the first four letters match the requested name 'CODE', it has found the requested namelist. The program then treats the remaining letters in the name as a variable name and complains that 'one' and 'two' are not defined variables for this namelist. In the case of reading the name 'CODEx', the gfortran program treats the x as a variable name that it recognizes as a valid variable, but complains that it is not followed by an equal sign. It appears that the compiled program needs to read the whole namelist name (up to the delimiting space) and then ask if this name matches the request in the READ statement. I include a short FORTRAN program 'namelist.f' that illustrates the problem when used with the supplied input file 'namelist.in' . The annotated output file 'namelist.out' gives the output (with errors) I found using gfortran and g77 compilers. The problem occurs using gcc-gfortran - 4.1.2-13.fc6.x86_64 libgfortran - 4.1.2-13.fc6.x86_64 running under Linux (Red Hat Fedora Core 6) and gcc-gfortran - 4.1.2-12.i386 libgfortran - 4.1.2-12.i386 running under Linux (Red Hat Fedora Core 7). Victor J. Slabinski C1*2*3*4*5*6*7** C Test of namelist operation in Linux gfortran compiled program: C Does the namelist read skip over namelists with other names or C similar names? namelist.f PROGRAM namelist CHARACTER*25 CHAR NAMELIST /CODE/ CHAR, X NAMELIST /CODEtwo/ X C OPEN(5, file='namelist.in') 100 CHAR = 'Initialize string ***' X= -777. READ(5, nml=CODE, END=999) WRITE(6,*) CHAR, X GO TO 100 999 Itest = 95 write(6,*) 'Itest=',Itest call exit(Itest) STOP 'namelist' END PROGRAM namelist File namelist.in with test NAMELIST inputs CODVJS char='VJS-Not a proper nml name', X=-0.5/ CODEone char='CODEone input', X=-1.0 / CODEtwo char='CODEtwo inputs', X=-2.0/ codechar='Improper lower case name',X=-3.0/ CODEchar='Desired namelist sel', X=44./ CODEx char='Should not read CODEx nml', X=-5./ $CODEchar='Second desired nml', X=66.0 / $CODEX=77.0, char='Reordered desired nml'/ ** Program output from NAMELIST reads with added, interpretive comments; call on FORTRAN compiler also listed. namelist.out ** FORTRAN compiler call: gfortran namelist.f -o namelist Output from executing program 'namelist': Cannot match namelist object name one !variable name 'one' is actually part of nml name CODEone CODEone input -1.00 !output for namelist read that should not have occurred Cannot match namelist object name two !variable name 'two' is actually part of nml name CODEtwo CODEtwo inputs -2.00 !output for namelist read that should not have occurred Improper lower case name -3.00 !shows that nml name upper/lower case does not matter Desired namelist sel44.0 Equal sign must follow namelist object name x !variable name 'x' is actually part of nml name CODEx Cannot match namelist object name har !words in nml string namelist read: missplaced = sign !variable are now Cannot match namelist object name should !treated as variable Cannot match namelist object name not !names Cannot match namelist object name read Cannot match namelist object name codex Cannot match namelist object name nml', Initialize string *** -5.00 !output for namelist read that should not have
[Bug tree-optimization/32941] [4.3 regression] Bootstrap comparison failure
--- Comment #7 from sje at cup dot hp dot com 2007-08-09 17:02 --- Created an attachment (id=14047) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14047action=view) untested patch I can't reliably reproduce the problem but the attached patch may fix it. It removes the sort and replaces bsearch with a simple linear search. While bootstrapping the largest size I saw for the queue was 7. While compiling larger C++ tests (SPEC2006) I saw it reach 30, but that is the largest I saw. For 30 elements or less (99% of the time it is a single element) I think a linear search is reasonable. Can someone who can reliably reproduce the problem test this patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32941
[Bug libffi/28313] libffi has not been ported to mips64-linux-gnu
--- Comment #3 from daney at gcc dot gnu dot org 2007-08-09 17:06 --- I will commit n32/n64 support shortly. -- daney at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |daney at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-07-08 14:28:04 |2007-08-09 17:06:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28313
[Bug target/31325] gcj support for ARM EABI
--- Comment #21 from aph at gcc dot gnu dot org 2007-08-09 17:44 --- I've created abranch for this work at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-eabi-branch It's mostly done, but there are still some bugs. I'll post the patches to the gcc list when they're in a fit state. -- aph at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aph at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-03-23 19:32:20 |2007-08-09 17:44:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31325
[Bug libfortran/33038] Unsatisfied symbol lroundl in file libgfortran.sl
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2007-08-09 17:57 --- Subject: Re: New: Unsatisfied symbol lroundl in file libgfortran.sl The symbol is from misc_specifics.o. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33038
[Bug java/33018] Not able to get past this error
--- Comment #5 from tromey at gcc dot gnu dot org 2007-08-09 18:05 --- See comment #3. The installation manual explains the correct way to configure and build. I'm closing this. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33018
[Bug java/33023] throw null
--- Comment #1 from tromey at gcc dot gnu dot org 2007-08-09 18:07 --- Yup, it's a bug. We aren't really fixing bugs in the old front end though. I'm closing it because this is a weird case and has a couple simple workarounds. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33023
[Bug fortran/33039] Read NAMELIST: reads wrong namelist name
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-09 18:39 --- I think this is a duplicate of PR 33019. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33039
[Bug libfortran/33038] Unsatisfied symbol lroundl in file libgfortran.sl
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-09 18:41 --- http://gcc.gnu.org/ml/fortran/2007-08/msg00119.html http://gcc.gnu.org/ml/fortran/2007-08/msg00122.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33038
[Bug libfortran/33038] Unsatisfied symbol lroundl in file libgfortran.sl
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2007-08-09 18:41 --- Subject: Re: New: Unsatisfied symbol lroundl in file libgfortran.sl The symbol is from misc_specifics.o. It looks like lroundl there is an implementation using roundl. There is an implementation of roundl using ceill, but ceill isn't available. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33038
[Bug fortran/33037] TRANSFER intrinsic is context sensitive
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-09 18:54 --- This is undefined code, when I rewrote most of the transfer code for scalars, I had asked what happens when the sizes did not match and everyone I asked said it was undefined behavior. Well, nonetheless gfortran could be that kind to follow NAG f95 and print Intrinsic TRANSFER has partly undefined result. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33037
[Bug libfortran/32989] getarg and -fdefault-integer-8
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-08-09 19:14 --- Right now, I'd rather work on something else. Unassigning myself (for now, at least). -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|tkoenig at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32989
[Bug fortran/32860] Support %ld (for long) for gfc_warning
-- 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 |org Status|NEW |ASSIGNED Last reconfirmed|2007-08-06 23:46:07 |2007-08-09 19:22:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32860
[Bug tree-optimization/32941] [4.3 regression] Bootstrap comparison failure
--- Comment #8 from andreasmeier80 at gmx dot de 2007-08-09 19:24 --- The regression was caused by the following patch New Revision: 126951 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126951 Log: 2007-07-26 Richard Guenther [EMAIL PROTECTED] toplev/ * configure.ac: Add types checking to stage1 checking flags. * configure: Regenerate. gcc/ * tree-cfg.c (verify_gimple_unary_expr, verify_gimple_binary_expr, verify_gimple_min_lval, verify_gimple_reference, verify_gimple_expr, verify_gimple_modify_stmt, verify_gimple_stmt, verify_gimple_1, verify_gimple): New functions. * tree-flow.h (verify_gimple): Declare. (verify_gimple_1): Declare. * gimplify.c (cpt_same_type): Remove. (gimplify_addr_expr): Remove checking code. (check_pointer_types_r): Remove. (gimplify_body): Call verify_gimple_1 instead of check_pointer_types_r. Only verify if there were no errors. * configure.ac: Add types checking flag. * configure: Regenerate. * config.in: Regenerate. Modified: trunk/ChangeLog trunk/configure trunk/configure.ac trunk/gcc/config.in trunk/gcc/configure trunk/gcc/configure.ac trunk/gcc/gimplify.c trunk/gcc/tree-cfg.c trunk/gcc/tree-flow.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32941
[Bug tree-optimization/32941] [4.3 regression] Bootstrap comparison failure
--- Comment #9 from andreasmeier80 at gmx dot de 2007-08-09 19:33 --- I'm now testing the patch from Comment #7. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32941
[Bug fortran/33040] New: ICE in gfc_trans_structure_assign
The following reduced example, based on http://www.lrz-muenchen.de/services/software/mathematik/gsl/fortran/, gives an segmentation fault: fgsl.f90: In function 'fgsl_multifit_fdfsolver_jac': fgsl.f90:24: internal compiler error: Segmentation fault valgrind shows: ==21413== Invalid read of size 2 ==21413==at 0x49810A: gfc_trans_structure_assign (trans-expr.c:3179) tmp = build3 (COMPONENT_REF, TREE_TYPE (field), dest, field, NULL_TREE); ==21413==by 0x497FF3: gfc_trans_subcomponent_assign (trans-expr.c:3139) ==21413==by 0x498142: gfc_trans_structure_assign (trans-expr.c:3180) ==21413==by 0x4982FE: gfc_conv_structure (trans-expr.c:3207) ==21413==by 0x494EA0: gfc_trans_assignment_1 (trans-expr.c:4020) ==21413==by 0x49501B: gfc_trans_assignment (trans-expr.c:4171) ==21413==by 0x4791CA: gfc_trans_code (trans.c:577) The crash occurs because field = NULL, which fails when using TREE_TYPE(field). module fgsl use, intrinsic :: iso_c_binding implicit none type, public :: fgsl_matrix private type(c_ptr) :: gsl_matrix = c_null_ptr end type fgsl_matrix type, public :: fgsl_multifit_fdfsolver private type(c_ptr) :: gsl_multifit_fdfsolver = c_null_ptr end type fgsl_multifit_fdfsolver interface function gsl_multifit_fdfsolver_jac(s) bind(c) import :: c_ptr type(c_ptr), value :: s type(c_ptr) :: gsl_multifit_fdfsolver_jac end function gsl_multifit_fdfsolver_jac end interface contains function fgsl_multifit_fdfsolver_jac(s) type(fgsl_multifit_fdfsolver), intent(in) :: s type(fgsl_matrix) :: fgsl_multifit_fdfsolver_jac fgsl_multifit_fdfsolver_jac%gsl_matrix = gsl_multifit_fdfsolver_jac(s%gsl_multifit_fdfsolver) end function fgsl_multifit_fdfsolver_jac end module fgsl -- Summary: ICE in gfc_trans_structure_assign Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33040
[Bug fortran/33001] error with hexadecimal DATA
--- Comment #8 from burnus at gcc dot gnu dot org 2007-08-09 21:28 --- Subject: Bug 33001 Author: burnus Date: Thu Aug 9 21:27:52 2007 New Revision: 127321 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127321 Log: 2007-08-09 Tobias Burnus [EMAIL PROTECTED] PR fortran/33001 * arith.c (arith_error): Point in the error message to -fno-range-check. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/arith.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33001
[Bug middle-end/32813] [4.3 Regression] ICE for array expression in empty if statement, compiled with -fbounds-check
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-08-09 21:37 --- Subject: Bug 32813 Author: pinskia Date: Thu Aug 9 21:36:27 2007 New Revision: 127322 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127322 Log: 2007-08-09 Andrew Pinski [EMAIL PROTECTED] PR middle-end/32813 * fold-const.c (omit_one_operand): Return only the ommitted expression if the result is an empty statement. (pedantic_omit_one_operand): Likewise. 2007-08-09 Andrew Pinski [EMAIL PROTECTED] PR middle-end/32813 * gfortran.fortran-torture/compile/emptyif-1.f90: New test. * lib/fortran-torture.exp (fortran-torture): Use TORTURE_OPTIONS instead of just -O. Added: trunk/gcc/testsuite/gfortran.fortran-torture/compile/emptyif-1.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/fortran-torture.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32813
[Bug c/32796] [4.3 Regression] internal compiler error: tree check: expected integer_type or enumeral_type or boolean_type or real_type, have pointer_type in int_fits_type_p
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-08-09 21:39 --- Subject: Bug 32796 Author: pinskia Date: Thu Aug 9 21:39:08 2007 New Revision: 127323 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127323 Log: 2007-08-09 Andrew Pinski [EMAIL PROTECTED] PR c/32796 * c-typeck.c (build_binary_op): Check for non pointer types before calling int_fits_type_p. 2007-08-09 Andrew Pinski [EMAIL PROTECTED] PR c/32796 * gcc.c-torture/compile/pr32796.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr32796.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32796
[Bug middle-end/32813] [4.3 Regression] ICE for array expression in empty if statement, compiled with -fbounds-check
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-08-09 21:39 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32813
[Bug c/32796] [4.3 Regression] internal compiler error: tree check: expected integer_type or enumeral_type or boolean_type or real_type, have pointer_type in int_fits_type_p
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-08-09 21:40 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32796
[Bug fortran/33020] Bind(C): c_f_pointer: type/rank mismatch error with integer(8) SHAPE
--- Comment #2 from patchapp at dberlin dot org 2007-08-09 21:45 --- Subject: Bug number PR 33020 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-08/msg00604.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33020
[Bug libfortran/33038] Unsatisfied symbol lroundl in file libgfortran.sl
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-08-09 21:51 --- (In reply to comment #3) It looks like lroundl there is an implementation using roundl. There is an implementation of roundl using ceill, but ceill isn't available. This has been fixed since, sorry for the breakage. I've just build a hppa2.0w-hp-hpux11.31 compiler since, and it works OK. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33038
[Bug fortran/31832] FAIL: gfortran.dg/integer_exponentiation_2.f90 at -O1 and above
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-08-09 21:54 --- (In reply to comment #1) I have looked into this bug and I think it is an HP math lib bug. The 64 bit powf function is using %fr12R but not saving/restoring it the way it is supposed to. I have a query in to the math lib folks to see if they can verify my finding. Any results? I cannot reproduce this on hppa2.0w-hp-hpux11.31 (neither the original bug nor your testcase that gives different results depending on optimization level). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31832
[Bug libfortran/26252] FAIL: gfortran.fortran-torture/execute/nan_inf_fmt.f90 execution
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-09 21:56 --- Still can't reproduce this on hppa2.0w-hp-hpux11.31. I'm starting to think that printf might be broken there, after all. Since it's a corner case on a platform that is not the current one, I'd like to close it as WONTFIX, John, what do you think? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26252
[Bug fortran/32860] Support %ld (for long) for gfc_warning
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-08-09 21:58 --- The patch in the previous comment wasn't even building, here is a one that regtests and that I submitted to review. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||08/msg00605.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32860
[Bug fortran/32987] TAB in FORMAT: accept extension, warn with -std=f*
--- Comment #8 from burnus at gcc dot gnu dot org 2007-08-09 22:03 --- Subject: Bug 32987 Author: burnus Date: Thu Aug 9 22:02:32 2007 New Revision: 127324 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127324 Log: 2007-08-09 Tobias Burnus [EMAIL PROTECTED] PR fortran/32987 * io.c (format_token): Add FMT_ERROR. (next_char_not_space): Print error/warning when '\t' are used in format specifications. (format_lex): Propagate error. (check_format): Ditto. 2007-08-09 Tobias Burnus [EMAIL PROTECTED] PR fortran/32987 * io/format.c (next_char): Treat '\t' as ' ' in format specification. 2007-08-09 Tobias Burnus [EMAIL PROTECTED] PR fortran/32987 * gfortran.dg/fmt_tab_1.f90: New. * gfortran.dg/fmt_tab_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/fmt_tab_1.f90 trunk/gcc/testsuite/gfortran.dg/fmt_tab_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/io/format.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32987
[Bug fortran/32987] TAB in FORMAT: accept extension, warn with -std=f*
--- Comment #9 from burnus at gcc dot gnu dot org 2007-08-09 22:08 --- FIXED for gfortran 4.3.0; gfortran now accepts the tab; it checks also at compile time for the tab character and gives either a warning (-std=gnu/legacy) or an error (-std=f95/f2003) if a tab has been found. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32987
[Bug fortran/31629] option to make module entities PRIVATE by default
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-09 22:20 --- Patch submitted for review. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||08/msg00607.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31629
[Bug fortran/31629] option to make module entities PRIVATE by default
--- Comment #4 from patchapp at dberlin dot org 2007-08-09 22:20 --- Subject: Bug number PR 31629 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-08/msg00607.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31629
[Bug fortran/33040] ICE in gfc_trans_structure_assign
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-09 22:23 ---
Some more debugging - I modified gfc_trans_structure_assign to:
--
cm = expr-ts.derived-components; i = 1;
for (c = expr-value.constructor; c; c = c-next, cm = cm-next)
{
printf(DEBUG: gfc_trans_structure_assign, loop %i; cm-name = %s\n,i++,
cm-name);
if (!c-expr)
continue;
field = cm-backend_decl;
if (field == NULL) {
gfc_error (field is zero at %L, c-expr-where); continue;
}
--
DEBUG: gfc_trans_structure_assign, loop 1; cm-name = __c_ptr_c_address
fgsl.f90:2.33:
use, intrinsic :: iso_c_binding
1
Error: field is zero at (1)
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||crickett at lanl dot gov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33040
[Bug fortran/33037] TRANSFER should warn on mismatched sizes
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2007-08-09 22:58:12 date|| Summary|TRANSFER intrinsic is |TRANSFER should warn on |context sensitive |mismatched sizes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33037
[Bug fortran/33040] [ISO_C_BINDING] ICE in gfc_trans_structure_assign
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||32630 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-09 22:54:15 date|| Summary|ICE in |[ISO_C_BINDING] ICE in |gfc_trans_structure_assign |gfc_trans_structure_assign http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33040
[Bug fortran/31822] Missing run-time bound checks for character pointer = target
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-09 22:52:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31822
[Bug fortran/33039] Read NAMELIST: reads wrong namelist name
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-08-09 23:27
---
Regarding the test case:
codechar='Improper lower case name',X=-3.0/
Fortran 95 Standard 10.9.1 states:
If a processor is capable of representing letters in both upper and lower
case, a group name or object name is without regard to case.
So lower case is not improper.
The standard also states that at least one space is required after the namelist
name. This patch fixes it:
Index: list_read.c
===
--- list_read.c (revision 127265)
+++ list_read.c (working copy)
@@ -2592,6 +2592,13 @@ find_nml_name:
if (dtp-u.p.nml_read_error)
goto find_nml_name;
+
+ c = next_char (dtp);
+ if (c != ' ')
+{
+ unget_char (dtp, c);
+ goto find_nml_name;
+}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33039
[Bug fortran/33020] Bind(C): c_f_pointer: type/rank mismatch error with integer(8) SHAPE
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-09 23:04:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33020
[Bug c/22371] C front-end produces mis-match types in MODIFY_EXPR
--- Comment #4 from jsm28 at gcc dot gnu dot org 2007-08-09 23:39 --- Created an attachment (id=14048) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14048action=view) Candidate patch from 2005 Here's my patch from 2005 as requested. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22371
[Bug fortran/33039] Read NAMELIST: reads wrong namelist name
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-08-09 23:37 --- *** Bug 33019 has been marked as a duplicate of this bug. *** -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33039
[Bug fortran/31832] FAIL: gfortran.dg/integer_exponentiation_2.f90 at -O1 and above
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2007-08-09 23:30 --- Subject: Re: FAIL: gfortran.dg/integer_exponentiation_2.f90 at -O1 and above Any results? I cannot reproduce this on hppa2.0w-hp-hpux11.31 (neither the original bug nor your testcase that gives different results depending on optimization level). To reproduce the original bug, you would need to build for hppa64-hp-hpux11.31 target. If you bootstrap with an HP compiler, you would need to add +DA2.0W to the stage1 CFLAGS. The two targets use different math libraries. The hppa64 problem was still present in my last build prior to the lroundl issue. Somewhere between August 4 and 8 bootstrap started to fail on this target. I also still see the fails mentioned in comment #3. See http://gcc.gnu.org/ml/gcc-testresults/2007-08/msg00236.html This might be a different bug. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31832
[Bug fortran/32131] knowing that stride==1 when using allocated arrays and escaping allocatable arrays
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-08-09 23:06 --- How on earth did that PR get assigned to me? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32131
[Bug libfortran/33019] FORTRAN NAMELIST Run Time Problem
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-08-09 23:37 --- *** This bug has been marked as a duplicate of 33039 *** -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33019
[Bug fortran/33039] Read NAMELIST: reads wrong namelist name
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-08-09 23:38 --- This report is better than my own. :) -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-09 23:38:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33039
[Bug objc++/31032] [4.3 Regression] expected tree that contains 'decl with RTL' structure, have 'field_decl' in assemble_external_real, at varasm.c:2225
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31032
[Bug tree-optimization/30375] [4.3 Regression] tree-ssa-dse incorrectly removes struct initialization
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30375
[Bug target/32276] [4.3 Regression]: libmudflap.c++/pass41-frag.cxx
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32276
[Bug middle-end/30017] [4.3 Regression] ICE in cp_expr_size, at cp/cp-objcp-common.c:101
--- Comment #17 from mmitchel at gcc dot gnu dot org 2007-08-10 00:23 --- Closed, since Andrew says this can no longer be reproduced. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30017
[Bug tree-optimization/31611] [4.3 regression] ICE with -ftree-loop-linear in remove_referenced_var for loc == *0
--- Comment #8 from mmitchel at gcc dot gnu dot org 2007-08-10 00:25 --- Closed, as Sebastian says he cannot reproduce, and as Richard says there is another testcase in PR31762. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31611
[Bug target/31897] [4.3 Regression] 30% speed regression with -m32 on Opteron with rnflow
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31897
[Bug bootstrap/32009] [4.3 Regression] building gcc4-4.3.0-20070518 failed on OSX 10.3.9
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32009
[Bug target/32130] [4.3 Regression] linking problems: multiple definition of `__DTOR_END__'
--- Comment #3 from mmitchel at gcc dot gnu dot org 2007-08-10 00:29 --- Apparently, this only affects libffi/java, so I've marked this P2, rather than P1. However, build failures are nasty, since many people just do configure; make. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32130
[Bug middle-end/32946] [4.3 Regression] ICE with -fpredictive-commoning in build_classic_dist_vector_1
--- Comment #4 from mmitchel at gcc dot gnu dot org 2007-08-10 00:55 --- P5 unless/until a C/C++ testcase can be found; upgrade to P3 if found. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32946
[Bug tree-optimization/32964] [4.3 Regression] union cause ineffient code inside loops
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32964
[Bug debug/32914] [4.2/4.3 Regression] ICE in rtl_for_decl_init with -g option
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32914
[Bug c++/32898] [4.2/4.3 regression] Definition of variable N::i outside namespace N not rejected
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32898
[Bug target/32855] [4.3 Regression] g++.dg/tree-ssa/pr28003.C
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32855
[Bug target/32853] [4.3 regression] failing libjava testcases
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32853
[Bug c++/32992] [4.1/4.2/4.3 Regression] Incorrect code generated for anonymous union and return
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-10 00:51 --- This is most likely caused by: 2005-09-09 Richard Henderson [EMAIL PROTECTED] PR debug/20998 * cp-tree.def (ALIAS_DECL): Remove. * cp-lang.c (cp_init_ts): Remove support for it. * error.c (dump_decl): Likewise. * name-lookup.c (pushdecl): Likewise. * semantics.c (finish_id_expression): Likewise. * decl2.c (build_anon_union_vars): Use a VAR_DECL with DECL_VALUE_EXPR instead. Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.1.0 4.2.0 4.3.0 Known to work||4.0.0 3.4.0 3.3.3 Last reconfirmed|-00-00 00:00:00 |2007-08-10 00:51:02 date|| Summary|Incorrect code generated for|[4.1/4.2/4.3 Regression] |anonymous union and return |Incorrect code generated for ||anonymous union and return Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32992
[Bug target/32787] [4.2/4.3 Regression] Sun Studio 12 Undefined symbol addl
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32787
[Bug c++/32756] [4.3 Regression] wrong ambiguous overload error?
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32756
[Bug tree-optimization/32733] [4.3 regression] error: definition in block 11 does not dominate use in block 12
--- Comment #5 from mmitchel at gcc dot gnu dot org 2007-08-10 00:45 --- P5 until/unless a non-Ada example is found. Upgrade to P3 if so. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32733
[Bug tree-optimization/32698] [4.3 regression] inefficient pointer expression
--- Comment #21 from mmitchel at gcc dot gnu dot org 2007-08-10 00:44 --- I'm not convinced that there's anything to fix here; it sounds like we've just traded which of two examples is better. If there is a bug here, please add a note explaining, and upgrade back to P3. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32698
[Bug libfortran/26252] FAIL: gfortran.fortran-torture/execute/nan_inf_fmt.f90 execution
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2007-08-10
00:41 ---
Subject: Re: FAIL: gfortran.fortran-torture/execute/nan_inf_fmt.f90 execution
Still can't reproduce this on hppa2.0w-hp-hpux11.31. I'm starting to think
that
printf might be broken there, after all. Since it's a corner case on a
platform
that is not the current one, I'd like to close it as WONTFIX, John, what do
you
think?
I just happened to have an old build of 4.2.0 lying around. The failure
is caused by a segmentation fault:
Program received signal SIGSEGV, Segmentation fault.
0x328a8 in atoi () at lib2funcs.asm:77
77 lib2funcs.asm: No such file or directory.
Current language: auto; currently asm
(gdb) bt
#0 0x328a8 in atoi () at lib2funcs.asm:77
#1 0x1d5a4 in output_float (dtp=0x7b03b2c0, f=0x4001bd10, value=-nan)
at ../../../gcc/libgfortran/io/write.c:557
#2 0x1dfbc in write_float (dtp=0x0, f=0x0,
source=0x7b03b950 \004üGÙ{\003¸{\003·ø\006\002ÿÿ, len=2063841318)
at ../../../gcc/libgfortran/io/write.c:973
#3 0xdcf0 in formatted_transfer (dtp=0x7b03b2c0, type=BT_REAL, p=0x7b03b950,
kind=4, size=4, nelems=1) at ../../../gcc/libgfortran/io/transfer.c:1086
#4 0xc5c8 in *_gfortran_transfer_real (dtp=0x7b03b2c0, p=0x7b03b290, kind=4)
at ../../../gcc/libgfortran/io/transfer.c:1369
#5 0x9d74 in MAIN__ ()
at
/xxx/gnu/gcc/gcc/gcc/testsuite/gfortran.fortran-torture/execute/nan_inf_fmt.f90:19
#6 0xae3c in main (argc=1, argv=0x7b03b048)
at ../../../gcc/libgfortran/fmain.c:18
The 11.11 manpage for printf says:
The e, f, and g conversions will print inf for infinity and nan for
both quiet and signaling NaN values.
The 10.20 manpage doesn't say anything about this but sprintf returned
+inf followed by ' ' 42 times. Obviously, somewhat broken... However,
output_float doesn't seem to handle returns of inf or nan.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26252
[Bug c++/32674] [4.1/4.2/4.3 regression] ICE in lvalue_p_1 initialising static variable inside template class
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32674
[Bug tree-optimization/32636] [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related verify_ssa failure
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32636
[Bug middle-end/32628] [4.3 Regression] bogus integer overflow warning
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32628
[Bug libgcj/32967] [4.3 regression] gcjavac throws java exceptions on startup
--- Comment #2 from tromey at gcc dot gnu dot org 2007-08-10 00:38 --- What is 'gcjavac'? -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32967
[Bug middle-end/32624] [4.3 Regression] r126198 causes tramp3d slowdown w/o leafify
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32624
[Bug c++/32596] [4.3 Regression] ICE with inline template specialization in anonymous namespace
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32596
[Bug tree-optimization/32586] [4.3 Regression] New VN misses FRE opportunities
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32586
[Bug tree-optimization/32573] [4.3 Regression] ice for legal code with -O3
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32573
[Bug c++/32565] [4.3 regression] ICE with specialization of variadic template
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32565
[Bug c++/32400] [4.3 Regression] ICE in expand_or_defer_fn, at cp/semantics.c:3220
--- Comment #7 from mmitchel at gcc dot gnu dot org 2007-08-10 00:30 --- I believe this to be valid code. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32400
[Bug middle-end/32546] [4.3 Regression] 'warning: array subscript is above/below array bounds' on delete[]
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32546
[Bug rtl-optimization/32557] [4.3 Regression] internal compiler error: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:956
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32557
[Bug c++/32566] [4.3 regression] ICE with invalid specialization of variadic template
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32566
[Bug c++/32567] [4.3 regression] ICE on invalid use of parameter pack
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32567
