[Bug target/27117] [4.2 Regression] gcc fails to build on sh64-elf targets
-- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-12 07:11:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27117
[Bug middle-end/27095] [4.1/4.2 Regression] O2 produces duplicate code
--- Comment #3 from amodra at bigpond dot net dot au 2006-04-12 07:12 --- Testing a fix -- amodra at bigpond dot net dot au changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net |dot org |dot au Status|NEW |ASSIGNED Last reconfirmed|2006-04-09 21:49:06 |2006-04-12 07:12:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27095
[Bug target/27117] [4.2 Regression] gcc fails to build on sh64-elf targets
--- Comment #2 from bonzini at gnu dot org 2006-04-12 07:30 --- And the funny part is, it is again Dale's patch that causes the failure. I'm more and more inclined to revert that part, but it may be a latent bug as in the AIX case (note: David Edelsohn decided to "fix" the bug by making sure the problematic RTL is not produced, but it still was an rs6000 latent bug in some sense). So, if Joern wants to take a look... -- bonzini at gnu dot org changed: What|Removed |Added CC||amylaar at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27117
[Bug c/27126] New: -Wswitch-enums doesn't detect impossible cases in switch()
Given:
int main(void)
{
enum foo { A, B, C, D} bar;
bar = D;
if(bar == A) {
;
} else if(bar == B) {
;
} else {
switch(bar) {
case C:
case D:
;
}
}
return 0;
}
barbeque/zarathustra:src: /usr/local/bin/gcc-4.1.0 -Wswitch-enum a.c
a.c: In function 'main':
a.c:10: warning: enumeration value 'A' not handled in switch
a.c:10: warning: enumeration value 'B' not handled in switch
A & B aren't valid targets for the switch statement by the time it's hit as
they have been handled by the if statements above.
Locally built gcc:
barbeque/zarathustra:src: /usr/local/bin/gcc-4.1.0 -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.1.0/configure --prefix=/usr/local/stow/gcc-4.1.0
--enable-languages=c,c++,objc --infodir=/usr/local/stow/gcc-4.1.0/share/info
--mandir=/usr/local/stow/gcc-4.1.0/share/man --enable-shared --enable-threads
--enable-tls --program-suffix=-4.1.0 --enable-__cxa_atexit
--enable-version-specific-runtime-libs
--enable-targets=x86_64-unknown-linux-gnu --enable-bootstrap=lean
--disable-biarch --disable-multilib
Thread model: posix
gcc version 4.1.0
On Debian/stable from amd64.debian.net.
Also happens on gcc 3.3.5 from the Debian apt archives.
--
Summary: -Wswitch-enums doesn't detect impossible cases in
switch()
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ramune+gcc at net-ronin dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27126
[Bug java/27127] New: internal compiler error when compiling libjava with jc1
I'm trying to build gcc on solaris8 sparc. after the command below, Class.d is 0 bytes in size. I don't see any other temporary files left behind by -save-temps [EMAIL PROTECTED]:~/gcc-3.4.6/sparc-sun-solaris2.8/sparcv9/libjava$ /export/home/rainer/gcc-3.4.6/gcc/gcj -v -save-temps -B/export/home/rainer/gcc-3.4.6/sparc-sun-solaris2.8/sparcv9/libjava/ -B/export/home/rainer/gcc-3.4.6/gcc/ --encoding=UTF-8 -Wno-deprecated -fclasspath= -fbootclasspath=/export/home/rainer/gcc-3.4.6/sparc-sun-solaris2.8/sparcv9/libjava -g -O2 -m64 -MD -MT java/lang/Class.lo -MF java/lang/Class.d -c ../../.././libjava/java/lang/Class.java -fPIC -o java/lang/.libs/Class.o Reading specs from /export/home/rainer/gcc-3.4.6/gcc/specs Reading specs from /export/home/rainer/gcc-3.4.6/sparc-sun-solaris2.8/sparcv9/libjava/libgcj.spec rename spec lib to liborig Configured with: ./configure --prefix=/usr/local/gcc-4.1.0 --program-suffix=4.1.0 --with-gnu-ld=/usr/local/bin/ld --with-gnu-as=/usr/local/bin/as Thread model: posix gcc version 3.4.6 /export/home/rainer/gcc-3.4.6/gcc/jc1 ../../.././libjava/java/lang/Class.java -fuse-divide-subroutine -fcheck-references -fuse-boehm-gc -fkeep-inline-functions -mptr64 -mstack-bias -mno-v8plus -mcpu=v9 -quiet -dumpbase Class.java -m64 -auxbase-strip java/lang/.libs/Class.o -g -O2 -Wno-deprecated -version -fencoding=UTF-8 -fclasspath= -fbootclasspath=/export/home/rainer/gcc-3.4.6/sparc-sun-solaris2.8/sparcv9/libjava -fPIC -MD_ -MT java/lang/Class.lo -MF java/lang/Class.d -o Class.s GNU Java version 3.4.6 (sparc-sun-solaris2.8) compiled by GNU C version 3.4.2. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Class path starts here: ./ /export/home/rainer/gcc-3.4.6/sparc-sun-solaris2.8/sparcv9/libjava/ (system) ../../.././libjava/java/lang/Class.java: In class `java.lang.Class': ../../.././libjava/java/lang/Class.java: In method `java.lang.Class.getDeclaredFields()': ../../.././libjava/java/lang/Class.java:85: internal compiler error: in size_binop, at fold-const.c:1601 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: internal compiler error when compiling libjava with jc1 Product: gcc Version: 3.4.6 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rainer-gccbugzilla at 7val dot com GCC build triplet: sparc-sun-solaris2.8 GCC host triplet: sparc-sun-solaris2.8 GCC target triplet: sparc-sun-solaris2.8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27127
[Bug java/27127] internal compiler error when compiling libjava with jc1
--- Comment #1 from rainer-gccbugzilla at 7val dot com 2006-04-12 08:38 --- Created an attachment (id=11247) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11247&action=view) Class.s, as built by gcj/jc1 before failure -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27127
[Bug java/27127] internal compiler error when compiling libjava with jc1
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2006-04-12 09:06
---
This is known to work, please make sure to read carefully the instructions at
http://gcc.gnu.org/install/specific.html#x-x-solaris2
In particular, use the recommended config shell and do not build in the source
directory. And --with-gnu-as=/usr/local/bin/as --with-gnu-ld=/usr/local/bin/ld
is not the correct syntax, please see
http://gcc.gnu.org/install/configure.html.
Also make sure to bootstrap ("gmake bootstrap") and not simply build the
compiler.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu dot
||org
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27127
[Bug ada/18818] ACATS cd10002 fails at runtime
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2006-04-12 09:09 --- Presumably fixed everywhere. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18818
[Bug c++/27129] New: [4.1/4.2 Regression] ICE in get_expr_operands
static const float a = 0.299f;
static const float b = 0.114f;
static const float c = 1 - a - c;
float
foo (void)
{
return a + b + c;
}
ICEs at -O and higher. There is a typo (should have been 1 - a - b of course),
but IMHO that just triggers undefined behavior.
G++ 4.0.x would initialize c in __static_initialization_and_destruction_0(int,
int) and compile it without ICE, where foo would be return 0.413f + c;
In 4.1.0+, apparently c is initialized to error_mark_node, although no error
nor even a warning is emitted at compile time, and obviously various later
optimizers are upset when seeing error_mark_node on unexpected places,
errorneous
input is not supposed to reach that far ever.
--
Summary: [4.1/4.2 Regression] ICE in get_expr_operands
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27129
[Bug c/27130] New: wrong long long elementary computations
This is a completetest file: 10 lines are enough,
with only 3 lines of actual code
#include
int main(void)
{
long long x;
long long y;
x=3;
y=5;
printf ("%Ld %Ld %Ld %Ld \n",x,y,x+y,x-y);
return 0;
}
gives the obviously absurd output
0 3 0 5
adding make no difference
The gcc version is
gcc (GCC) 4.1.1 20060331 (prerelease)
Compiled form sources on a SUN Blade 1000 Solaris 9
with the only configure option
--enable-languages=c
below is the .i file:
# 1 "longlong.c"
# 1 ""
# 1 ""
# 1 "longlong.c"
# 1 "/usr/include/stdio.h" 1 3 4
# 20 "/usr/include/stdio.h" 3 4
#pragma ident "@(#)stdio.h 1.7901/04/16 SMI"
# 1 "/usr/include/iso/stdio_iso.h" 1 3 4
# 32 "/usr/include/iso/stdio_iso.h" 3 4
#pragma ident "@(#)stdio_iso.h 1.2 99/10/25 SMI"
# 1 "/usr/include/sys/feature_tests.h" 1 3 4
# 13 "/usr/include/sys/feature_tests.h" 3 4
#pragma ident "@(#)feature_tests.h 1.1899/07/26 SMI"
# 1 "/usr/include/sys/isa_defs.h" 1 3 4
# 9 "/usr/include/sys/isa_defs.h" 3 4
#pragma ident "@(#)isa_defs.h 1.2099/05/04 SMI"
# 16 "/usr/include/sys/feature_tests.h" 2 3 4
# 36 "/usr/include/iso/stdio_iso.h" 2 3 4
# 1 "/usr/include/sys/va_list.h" 1 3 4
# 9 "/usr/include/sys/va_list.h" 3 4
#pragma ident "@(#)va_list.h1.1301/02/08 SMI"
# 26 "/usr/include/sys/va_list.h" 3 4
typedef void *__va_list;
# 37 "/usr/include/iso/stdio_iso.h" 2 3 4
# 1 "/usr/include/stdio_tag.h" 1 3 4
# 9 "/usr/include/stdio_tag.h" 3 4
#pragma ident "@(#)stdio_tag.h 1.3 98/04/20 SMI"
# 21 "/usr/include/stdio_tag.h" 3 4
typedef struct __FILE __FILE;
# 38 "/usr/include/iso/stdio_iso.h" 2 3 4
# 1 "/usr/include/stdio_impl.h" 1 3 4
# 9 "/usr/include/stdio_impl.h" 3 4
#pragma ident "@(#)stdio_impl.h 1.1301/11/16 SMI"
# 22 "/usr/include/stdio_impl.h" 3 4
typedef int ssize_t;
# 38 "/usr/include/stdio_impl.h" 3 4
struct __FILE
{
ssize_t _cnt;
unsigned char *_ptr;
unsigned char *_base;
unsigned char _flag;
unsigned char _file;
unsigned __orientation:2;
unsigned __ionolock:1;
unsigned __seekable:1;
unsigned __filler:4;
};
# 39 "/usr/include/iso/stdio_iso.h" 2 3 4
# 59 "/usr/include/iso/stdio_iso.h" 3 4
typedef long long __longlong_t;
# 75 "/usr/include/iso/stdio_iso.h" 3 4
typedef __FILE FILE;
typedef unsigned int size_t;
typedef long fpos_t;
# 147 "/usr/include/iso/stdio_iso.h" 3 4
extern __FILE __iob[20];
# 164 "/usr/include/iso/stdio_iso.h" 3 4
extern int remove(const char *);
extern int rename(const char *, const char *);
extern FILE *tmpfile(void);
extern char *tmpnam(char *);
extern int fclose(FILE *);
extern int fflush(FILE *);
extern FILE *fopen(const char *, const char *);
extern FILE *freopen(const char *, const char *, FILE *);
extern void setbuf(FILE *, char *);
extern int setvbuf(FILE *, char *, int, size_t);
extern int fprintf(FILE *, const char *, ...);
extern int fscanf(FILE *, const char *, ...);
extern int printf(const char *, ...);
extern int scanf(const char *, ...);
extern int sprintf(char *, const char *, ...);
extern int sscanf(const char *, const char *, ...);
extern int vfprintf(FILE *, const char *, __va_list);
extern int vprintf(const char *, __va_list);
extern int vsprintf(char *, const char *, __va_list);
extern int fgetc(FILE *);
extern char *fgets(char *, int, FILE *);
extern int fputc(int, FILE *);
extern int fputs(const char *, FILE *);
extern int getc(FILE *);
extern int putc(int, FILE *);
extern int getchar(void);
extern int putchar(int);
extern char *gets(char *);
extern int puts(const char *);
extern int ungetc(int, FILE *);
extern size_t fread(void *, size_t, size_t, FILE *);
extern size_t fwrite(const void *, size_t, size_t, FILE *);
extern int fgetpos(FILE *, fpos_t *);
extern int fseek(FILE *, long, int);
extern int fsetpos(FILE *, const fpos_t *);
extern long ftell(FILE *);
extern void rewind(FILE *);
extern void clearerr(FILE *);
extern int feof(FILE *);
extern int ferror(FILE *);
extern void perror(const char *);
extern int __filbuf(FILE *);
extern int __flsbuf(int, FILE *);
# 23 "/usr/include/stdio.h" 2 3 4
# 91 "/usr/include/stdio.h" 3 4
typedef long off_t;
typedef __longlong_t off64_t;
# 109 "/usr/include/stdio.h" 3 4
typedef __longlong_t fpos64_t;
# 137 "/usr/include/stdio.h" 3 4
extern unsigned char _sibuf[], _sobuf[];
# 179 "/usr/include/stdio.h" 3 4
extern unsigned char *_bufendtab[];
extern FILE *_lastbuf;
# 215 "/usr/include/stdio.h" 3 4
extern void setbuffer(FILE *, char *, size_t);
extern int setlinebuf(FILE *);
extern int vfscanf(FILE *, const char *, __va_list);
extern int vscanf(const char *, __va_list);
extern int vsscanf(const char *, const char *, __va_list);
extern int snprintf(char *, size_t, const char *, ...);
extern int vsnprintf(char *, size_t, const char *, __va_list);
# 244 "/usr/include/stdio.h" 3 4
extern FILE *fdopen(int, const char *);
extern char *ctermid(char *);
extern int fileno(FILE *);
# 270 "/usr/include/stdio.h" 3 4
extern FILE *popen(const char *, const char *);
exter
[Bug c/27130] wrong long long elementary computations
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-12 10:14 --- Use %lld, the L length modifier is for floating point formats to enable long double. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27130
[Bug c/27126] -Wswitch-enums doesn't detect impossible cases in switch()
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-12 10:17 --- Confirmed. But this is unlikely to be fixed as it would require moving the diagnostic to the middle-end where this information is available. And diagosticts from the middle-end are notoriously frowned upon. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement 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| Keywords||diagnostic Priority|P3 |P5 Last reconfirmed|-00-00 00:00:00 |2006-04-12 10:17:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27126
[Bug c++/27129] [4.1/4.2 Regression] ICE in get_expr_operands
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-04-12 11:17 --- Confirmed. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||reichelt at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code, monitored Last reconfirmed|-00-00 00:00:00 |2006-04-12 11:17:02 date|| Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27129
[Bug c++/27115] [4.0/4.1/4.2 Regression] ICE in cp_expr_size or miscompilation
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-04-12 11:34
---
Confirmed.
Shorter testcase that crashes at -O0:
struct A
{
A (const A&);
A& operator= (const A&);
};
void foo(A a)
{
A b = ({ a; });
}
bug.cc: In function 'void foo(A)':
bug.cc:9: internal compiler error: in cp_expr_size, at cp/cp-objcp-common.c:101
Please submit a full bug report, [etc.]
The problem seems to be the statement-expression.
Just initializing "A b = a;" makes the ICE go away.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||monitored
Last reconfirmed|-00-00 00:00:00 |2006-04-12 11:34:16
date||
Target Milestone|4.0.4 |4.1.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27115
[Bug c++/27094] [4.0/4.1/4.2 Regression] tree check: expected tree_list, have omp_return in build_call
--- Comment #6 from jakub at gcc dot gnu dot org 2006-04-12 11:46 ---
It is a GC problem, when build_over_call calls mark_used, it certainly doesn't
expect mark_used to do a gcc_collect underneath it, as it has several tree
pointers stored in local variables. I guess build_over_call isn't the only
place that trusts mark_used doesn't do that, e.g. build_call,
build_op_delete_call, finish_eh_spec_block etc. likely suffer from the same
problem.
The call chain that leads to ggc_collect is mark_used ->
{synthetize_method,instantiate_decl} -> expand_or_defer_fn ->
cgraph_finalize_function -> ggc_collect.
So, either we change mark_used to never trigger GC from underneath us
(e.g. by function_depth++; synthetise_method (...); function_depth--; and
probably similarly for instantiate_decl), or we add an argument to mark_used
if it is ok to ggc_collect (similarly to cgraph_finalize_function's NESTED
argument), or we change all mark_used callers that might suffer from this
(either by adding function_depth++/function_depth-- around the call, or by
registering its temporaries with GC before calling mark_used).
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||jason at redhat dot com,
||mark at codesourcery dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27094
[Bug c++/27115] [4.0/4.1/4.2 Regression] ICE in cp_expr_size or miscompilation
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-04-12 12:11
---
Here's a shorter testcase for the wrong-code problem (using "-O"):
It should return 0, but returns something else since GCC 4.0.2.
The compiler crashes on this testcase with GCC 3.3 - 4.0.1.
=
struct A
{
int i;
A (int j) : i(j) {}
A (const A &j) : i(j.i) {}
A& operator= (const A &j) { i = j.i; return *this; }
};
A foo(int j)
{
return ({ j ? A(1) : A(0); });
}
int main()
{
return foo(1).i-1;
}
=
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27115
[Bug tree-optimization/26830] [4.2 Regression] Repeated SSA update during loop header copying
--- Comment #33 from rakdver at gcc dot gnu dot org 2006-04-12 12:20 --- Created an attachment (id=11248) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11248&action=view) Patch to speed up update_ssa This patch makes update_ssa significantly faster in cases like this (when update_ssa is called often), by ensuring that we do not perform unnecessary expensive tasks (walking all statements or ssa names) each time update_ssa is called. Several more improvements are possible, especially in the phi insertion phase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
[Bug middle-end/27132] New: Fold does not canonicalize i - -1
Fold does not canonicalize i - -1 to i + 1 where allowed. It has /* A - B -> A + (-B) if B is easily negatable. */ if (negate_expr_p (arg1) && ((FLOAT_TYPE_P (type) /* Avoid this transformation if B is a positive REAL_CST. */ && (TREE_CODE (arg1) != REAL_CST || REAL_VALUE_NEGATIVE (TREE_REAL_CST (arg1 || (INTEGRAL_TYPE_P (type) && flag_wrapv && !flag_trapv))) return fold_build2 (PLUS_EXPR, type, fold_convert (type, arg0), fold_convert (type, negate_expr (arg1))); but that doesn't trigger if !flag_wrapv. -- Summary: Fold does not canonicalize i - -1 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27132
[Bug bootstrap/27133] New: Fails to build because of funny version of makeinfo
This may actually be several distinct minor bugs. On my Sparc machine, I have what I think is a strang version of makeinfo, installed by TeX (or at least, in the tex tree) -- makeinfo --version returns: makeinfo (GNU texinfo 3.12) 1.68 This results in the compiler system (most specifically fastjar) failing to build. I will apply the obvious fix in my case -- install a correct version of makeinfo from sources. However... The makeinfo pages say that "all GNU distributions should come with prebuilt info files, thus makeinfo should not be needed. If you notice a distribution that does not come with *.info files, please report it as a bug." Whence this bug report. Two possible improvements while I'm at it: there really could be an error message (or a warning) in configure, where you check the version, and (more a question) is there a simple way to build without building the documentation -- I've already got it from the Linux build anyway? -- Summary: Fails to build because of funny version of makeinfo Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jkanze at cheuvreux dot com GCC build triplet: sparc-sun-solaris2.8 GCC host triplet: sparc-sun-solaris2.8 GCC target triplet: sparc-sun-solaris2.8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27133
[Bug c++/27134] New: ICE when compiling vtk-5.0
When compiling vtk-5.0 with gcc-4.1.0 there occurs an ICE.. preprocessed sourcefile attached. -- Summary: ICE when compiling vtk-5.0 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: xtv at tveith dot homelinux dot com GCC host triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27134
[Bug middle-end/27132] Fold does not canonicalize i - -1
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-12 12:53 ---
Testcase:
/* { dg-do compile } */
/* { dg-options "-fdump-tree-gimple" } */
int foo(int i)
{
return i - -1;
}
/* { dg-final { scan-tree-dump "i \\+ 1" "gimple" } } */
/* { dg-final { cleanup-tree-dump "gimple" } } */
I have a patch. But that conflicts with negate_expr_p - see
http://gcc.gnu.org/ml/gcc/2006-04/msg00063.html
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-04-12 12:53:29
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27132
[Bug c++/27134] ICE when compiling vtk-5.0
--- Comment #1 from xtv at tveith dot homelinux dot com 2006-04-12 12:54 --- Created an attachment (id=11249) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11249&action=view) preprocessed source file preprocessed sourcefile compressed with gzip to meet the size requirements for submitting non-patches to bugzilla -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27134
[Bug c++/27135] New: parser.c:10895: warning: 'is_parenthesized_init' may be used uninitialized in this function
/home/dave/gnu/gcc-4.2/objdir/./prev-gcc/xgcc -B/home/dave/gnu/gcc-4.2/objdir/./ prev-gcc/ -B/home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/bin/ -c -g -O2 -DIN_GC C -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definiti on -Wmissing-format-attribute -Werror -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -Icp -I../../gcc/gcc -I../../gcc/gcc/cp -I../../gcc/gcc/../include -I../../ gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../libdecnumber ../../gcc/gcc/cp/parser.c -o cp/parser.o cc1: warnings being treated as errors ../../gcc/gcc/cp/parser.c: In function 'cp_parser_init_declarator': ../../gcc/gcc/cp/parser.c:10895: warning: 'is_parenthesized_init' may be used un initialized in this function make[3]: *** [cp/parser.o] Error 1 make[3]: Leaving directory `/home/dave/gnu/gcc-4.2/objdir/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/home/dave/gnu/gcc-4.2/objdir' make[1]: *** [stage2-bubble] Error 2 -- Summary: parser.c:10895: warning: 'is_parenthesized_init' may be used uninitialized in this function Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa-unknown-linux-gnu GCC host triplet: hppa-unknown-linux-gnu GCC target triplet: hppa-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27135
[Bug c++/27084] Does not propagate memory load base through useless type conversion
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-04-12 13:35 --- PASS: g++.old-deja/g++.mike/dyncast7.C (test for excess errors) FAIL: g++.old-deja/g++.mike/dyncast7.C execution test const Foo* and Foo* are really not compatible. We can just exchange Foo* for const Foo* for loads. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27084
[Bug c++/27084] Does not propagate memory load base through useless type conversion
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-04-12 13:37 --- Created an attachment (id=11250) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11250&action=view) updated patch Patch I will clean and test instead. Also fixes 27090. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Attachment #11227|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27084
[Bug target/27117] [4.2 Regression] gcc fails to build on sh64-elf targets
--- Comment #3 from amylaar at gcc dot gnu dot org 2006-04-12 13:46 --- sh64 has indexed addressing, but the addition is always done as 64 bit, and there are currently no implemenmtations that allow the 64 bit logical address space to be re-mapped into a 32 physical address space - instead they trap on any access to an address that does not fit into a 32 bit address space. This makes using indexed addressing with Pmode for -m5-32media (where Pmode is SImode) unsafe, since some optimizations can fold additions into indexed addressing and thus cause out-of-range addresses. Therefore, INDEX_REG_CLASS is NO_REGS for -m5-32media. The division code produces an address with a DImode plus of two registers - this is safe, since we exactly describe what the hardware does. However, find_reloads_address_1 sees a plus and recurses with CONTEXT set to 1, and then uses INDEX_REG_CLASS; it does not take into account that the mode is not Pmode. I think the best solution is to have an INDEX_REG_CLASS_FOR_MODE macro, which defaults to INDEX_REG_CLASS. Then this macro can be defined for the SH to return GENERAL_REGS for DImode when compiling SHmedia code. A kludgy solution would be to make reload reload the sum into a base register (to cover the general case), and make the SH LEGITIMIZE_RELOAD_ADDRESS recognize a sum with a non-pmode PLUS, and only reload pseudos inside into GENERAL_REGS. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27117
[Bug c++/27129] [4.1/4.2 Regression] ICE in get_expr_operands
--- Comment #2 from prigault at oricom dot ca 2006-04-12 14:00 ---
IMO, the line defining c should trigger an error message because it needs to
use c before creating the variable, or else undefined behaviour occurs.
This message could be:
error: ‘c’ was not declared in this scope
or:
error: 'c' is used uninitialized
Consider:
$ more test.cc
#include
static const float f = 1 - a;
int main(void)
{
printf("%f\n", f);
return 0;
}
$ g++ -Wall -O2 -o test test.cc
test.cc:3: error: ‘a’ was not declared in this scope
$ more test1.cc
#include
static const float f = 1 - f;
int main(void)
{
printf("%f\n", f);
return 0;
}
$ g++ -Wall -O2 -o test1 test1.cc
$
There should be an error message there as well.
--
prigault at oricom dot ca changed:
What|Removed |Added
CC||prigault at oricom dot ca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27129
[Bug tree-optimization/26830] [4.2 Regression] Repeated SSA update during loop header copying
--- Comment #34 from dnovillo at redhat dot com 2006-04-12 14:09 --- Subject: Re: [4.2 Regression] Repeated SSA update during loop header copying -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/12/06 08:20, rakdver at gcc dot gnu dot org wrote: > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11248&action=view) > Patch to speed up update_ssa > Fails building libgcc with checking disabled on x86. Starting program: /notnfs/dnovillo/BLD-gcc-native/gcc/cc1 -fpreprocessed libgcov.i -quiet -dumpbase libgcov.c -mtune=generic -auxbase-strip libgcc/./_gcov.o -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes - -Wmissing-prototypes -Wold-style-definition -version -fPIC -o libgcov.s Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0xb000 GNU C version 4.2.0 20060412 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.1.0 20060304 (Red Hat 4.1.0-3). GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128991 Compiler executable checksum: 3c4ee7023c10209f81749c69d1323e23 Program received signal SIGSEGV, Segmentation fault. 0x0813d8f4 in bitmap_first_set_bit (a=0x86ec974) at /home/dnovillo/gcc/src/gcc/bitmap.c:595 595 bit_no = elt->indx * BITMAP_ELEMENT_ALL_BITS; (gdb) up #1 0x080da1da in set_livein_block (var=0xb7ce9034, bb=0xb7cc0d20) at /home/dnovillo/gcc/src/gcc/tree-into-ssa.c:486 486 int def_block_index = bitmap_first_set_bit (db_p->def_blocks); (gdb) up #2 0x080ddd3b in mark_use_interesting (var=0xb7ce9034, stmt=0xb7cd8f50, bb=0xb7cc0d20, blocks=0x86ec8c0, insert_phi_p=1 '\001') at /home/dnovillo/gcc/src/gcc/tree-into-ssa.c:1924 1924set_livein_block (var, bb); (gdb) #3 0x080dde71 in prepare_use_sites_for (name=0xb7ce9034, blocks=0x86ec8c0, insert_phi_p=1 '\001') at /home/dnovillo/gcc/src/gcc/tree-into-ssa.c:2045 2045 mark_use_interesting (name, stmt, bb, blocks, insert_phi_p); (gdb) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEPQooUTa2oAUaiwQRAkAIAKCE4Sy7b0HCuZXv2M6a0OP0EBrQWgCgg5CT 7er5u0KdZhzL7y6sHsLVZts= =B10i -END PGP SIGNATURE- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
[Bug target/27117] [4.2 Regression] gcc fails to build on sh64-elf targets
--- Comment #4 from paolo dot bonzini at lu dot unisi dot ch 2006-04-12 14:09 --- Subject: Re: [4.2 Regression] gcc fails to build on sh64-elf targets > I think the best solution is to have an INDEX_REG_CLASS_FOR_MODE macro, > which defaults to INDEX_REG_CLASS. Then this macro can be defined for the > SH to return GENERAL_REGS for DImode when compiling SHmedia code. > Thanks for the analysis. I quickly tested that your approach works for Kaz's testcase. However I don't feel confident enough to write this patch though -- and even less to document it. Are you going to do it, or should I go on and revert the regclass.c change? This is what I tested BTW: Index: reload.c === --- reload.c(revision 112658) +++ reload.c(working copy) @@ -5316,7 +5316,7 @@ find_reloads_address_1 (enum machine_mod RTX_CODE code = GET_CODE (x); if (context == 1) -context_reg_class = INDEX_REG_CLASS; +context_reg_class = GET_MODE (x) == DImode ? GENERAL_REGS : INDEX_REG_CLASS; else context_reg_class = base_reg_class (mode, outer_code, index_code); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27117
[Bug tree-optimization/26830] [4.2 Regression] Repeated SSA update during loop header copying
--- Comment #35 from rakdver at atrey dot karlin dot mff dot cuni dot cz 2006-04-12 14:20 --- Subject: Re: [4.2 Regression] Repeated SSA update during loop header copying > > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11248&action=view) > > Patch to speed up update_ssa > > > Fails building libgcc with checking disabled on x86. forgot to say: mostly untested patch, still work in progress :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
[Bug tree-optimization/26830] [4.2 Regression] Repeated SSA update during loop header copying
--- Comment #36 from dnovillo at redhat dot com 2006-04-12 14:23 --- Subject: Re: [4.2 Regression] Repeated SSA update during loop header copying -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/12/06 10:20, rakdver at atrey dot karlin dot mff dot cuni dot cz wrote: > forgot to say: mostly untested patch, still work in progress :-) > Oh, OK. I got the impression you were submitting it. I'll wait for your final version then. Thanks. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEPQ1sUTa2oAUaiwQRApY5AJ4v+ve2Yl2mkv8+nMVSo0XvOBEF0wCeOLKr aojItQJu1BeKQcMIwzfLKSM= =5Ole -END PGP SIGNATURE- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
[Bug fortran/26834] gfc_todo: Not Implemented: Unable to determine rank of expression
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-04-12
14:32 ---
(In reply to comment #1)
> Confirmed, PR 25669 and bug 18003 are very closely related (it might turn out
> this is a dup of one of them).
They are indeed the same. Attached below is a patch that fixes all three and a
testcase that demonstrates that this is so. The patch is still testing but I
am pretty sure it is OK (ie. this is a path that ICEd previously). I will
submit tonight, if all is well.
Paul
Index: gcc/fortran/trans-array.c
===
--- gcc/fortran/trans-array.c (révision 112853)
+++ gcc/fortran/trans-array.c (copie de travail)
@@ -2393,6 +2393,19 @@
loop->dimen = ss->data.info.dimen;
break;
+ /* Cope with the likes of PRINT *, lbound (a), where nothing
+ better is available. */
+ case GFC_SS_INTRINSIC:
+ switch (ss->expr->value.function.isym->generic_id)
+ {
+ case GFC_ISYM_LBOUND:
+ case GFC_ISYM_UBOUND:
+ loop->dimen = ss->data.info.dimen;
+
+ default:
+ break;
+ }
+
default:
break;
}
@@ -2418,6 +2431,15 @@
gfc_conv_section_startstride (loop, ss, n);
break;
+ case GFC_SS_INTRINSIC:
+ switch (ss->expr->value.function.isym->generic_id)
+ {
+ case GFC_ISYM_LBOUND:
+ case GFC_ISYM_UBOUND:
+ break;
+ default:
+ continue;
+ }
case GFC_SS_CONSTRUCTOR:
case GFC_SS_FUNCTION:
for (n = 0; n < ss->data.info.dimen; n++)
Index: gcc/fortran/trans-intrinsic.c
===
--- gcc/fortran/trans-intrinsic.c (révision 112853)
+++ gcc/fortran/trans-intrinsic.c (copie de travail)
@@ -3710,6 +3710,7 @@
newss->type = GFC_SS_INTRINSIC;
newss->expr = expr;
newss->next = ss;
+ newss->data.info.dimen = 1;
return newss;
}
! { dg-do compile }
! This tests the fix for PRs 26834, 25669 and 18803, in which
! shape information for the lbound and ubound intrinsics was not
! transferred to the scalarizer. For this reason, an ICE would
! ensue, whenever these functions were used in temporaries.
!
! The tests are lifted from the PRs and some further checks are
! done to make sure that nothing is broken.
!
! This is PR26834
subroutine gfcbug34 ()
implicit none
type t
integer, pointer :: i (:) => NULL ()
end type t
type(t), save :: gf
allocate (gf%i(20))
write(*,*) 'ubound:', ubound (gf% i)
write(*,*) 'lbound:', lbound (gf% i)
end subroutine gfcbug34
! This is PR25669
subroutine foo (a)
real a(*)
call bar (a, LBOUND(a),2)
end subroutine foo
subroutine bar (b, i, j)
real b(i:j)
print *, i, j
print *, b(i:j)
end subroutine bar
! This is PR18003
subroutine io_bug()
integer :: a(10)
print *, ubound(a)
end subroutine io_bug
! This checks that lbound and ubound are OK in temporary
! expressions.
subroutine io_bug_plus()
integer :: a(10, 10), b(2)
print *, ubound(a)*(/1,2/)
print *, (/1,2/)*ubound(a)
end subroutine io_bug_plus
character(4) :: ch(2), ech(2) = (/'ABCD', 'EFGH'/)
real(4) :: a(2)
equivalence (ech,a)
integer(1) :: i(8) = (/(j, j = 1,8)/)
! Check that the bugs have gone
call io_bug ()
call io_bug_plus ()
call foo ((/1.0,2.0,3.0/))
call gfcbug34 ()
! Check that we have not broken other intrinsics.
print *, cos ((/1.0,2.0/))
print *, transfer (a, ch)
print *, i(1:4) * transfer (a, i, 4) * 2
end
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26834
[Bug fortran/27124] Incorrect dependency for assignment from function with array section actual arg.
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-04-12
14:34 ---
I have a fix for it, which is regtesting right now. Even if it fails in this
form, it is along the right lines and there will be a version that is pukkah. I
hope to submit the patch tonight.
Quite simply, the fix consists of gathering up all the argument post_blocks,
which contain the unpacking and freeing of argument temporaries, and putting
them into a separate block. Once the function call is translated, it either
goes in the se->pre block or becomes the se expression, depending on how the
value is returned. Depending on this same choice, we now add the argument post
block to se->pre or to se->post. This ensures that the results of byref calls
that produce temporaries are transferred to the destination array AFTER the
unpacking of the argument. The reduced testcase below now runs correctly.
The patch and testcase appear below.
Paul
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(révision 112853)
+++ gcc/fortran/trans-expr.c(copie de travail)
@@ -1832,6 +1832,7 @@
gfc_charlen cl;
gfc_expr *e;
gfc_symbol *fsym;
+ stmtblock_t post;
arglist = NULL_TREE;
retargs = NULL_TREE;
@@ -1861,6 +1862,7 @@
else
info = NULL;
+ gfc_init_block (&post);
gfc_init_interface_mapping (&mapping);
need_interface_mapping = ((sym->ts.type == BT_CHARACTER
&& sym->ts.cl->length
@@ -1970,7 +1972,7 @@
gfc_add_interface_mapping (&mapping, fsym, &parmse);
gfc_add_block_to_block (&se->pre, &parmse.pre);
- gfc_add_block_to_block (&se->post, &parmse.post);
+ gfc_add_block_to_block (&post, &parmse.post);
/* Character strings are passed as two parameters, a length and a
pointer. */
@@ -2177,6 +2179,11 @@
}
}
+ if (byref)
+gfc_add_block_to_block (&se->pre, &post);
+ else
+gfc_add_block_to_block (&se->post, &post);
+
return has_alternate_specifier;
}
! { dg-do run }
! Tests the fix for PR27124 in which the unpacking of argument
! temporaries and of array result temporaries occurred in the
! incorrect order.
!
! Test is based on the original example, provided by
! Philippe Schaffnit <[EMAIL PROTECTED]>
!
PROGRAM Test
INTEGER :: Array(2, 3) = reshape ((/1,4,2,5,3,6/),(/2,3/))
integer :: Brray(2, 3) = 0
Brray(1,:) = Function_Test (Array(1,:))
if (any(reshape (Brray, (/6/)) .ne. (/11, 0, 12, 0, 13, 0/))) call abort ()
Array(1,:) = Function_Test (Array(1,:))
if (any(reshape (Array, (/6/)) .ne. (/11, 4, 12, 5, 13, 6/))) call abort ()
contains
FUNCTION Function_Test (Input)
INTEGER, INTENT(IN) :: Input(1:3)
INTEGER :: Function_Test(1:3)
Function_Test = Input + 10
END FUNCTION Function_Test
END PROGRAM Test
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27124
[Bug middle-end/27134] [4.1/4.2 regression] ICE with floor and -ffast-math
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-04-12 14:59
---
Confirmed.
Reduced testcase (compile with -O -ffast-math):
==
double floor(double);
inline int bar(double x) { return (int)floor(x); }
int foo(int i) { return bar(i); }
==
bug.c: In function 'foo':
bug.c:3: internal compiler error: in get_callee_fndecl, at tree.c:5809
Please submit a full bug report, [etc.]
Happens with C and C++ frontend.
There seems to be something wrong with -ffast-math and floor.
Renaming floor to something else in the above testcase makes things
work again.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Component|c++ |middle-end
Ever Confirmed|0 |1
Keywords||ice-on-valid-code, monitored
Last reconfirmed|-00-00 00:00:00 |2006-04-12 14:59:12
date||
Summary|ICE when compiling vtk-5.0 |[4.1/4.2 regression] ICE
||with floor and -ffast-math
Target Milestone|--- |4.1.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27134
[Bug fortran/27124] Incorrect dependency for assignment from function with array section actual arg.
--- Comment #3 from P dot Schaffnit at access dot rwth-aachen dot de
2006-04-12 15:02 ---
Subject: Re: Incorrect dependency for assignment from
functionwith array section actual arg.
Merci!
Philippe
paul dot richard dot thomas at cea dot fr wrote:
>
> --- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-04-12
> 14:34 ---
> I have a fix for it, which is regtesting right now. Even if it fails in this
> form, it is along the right lines and there will be a version that is pukkah.
> I
> hope to submit the patch tonight.
>
> Quite simply, the fix consists of gathering up all the argument post_blocks,
> which contain the unpacking and freeing of argument temporaries, and putting
> them into a separate block. Once the function call is translated, it either
> goes in the se->pre block or becomes the se expression, depending on how the
> value is returned. Depending on this same choice, we now add the argument
> post
> block to se->pre or to se->post. This ensures that the results of byref calls
> that produce temporaries are transferred to the destination array AFTER the
> unpacking of the argument. The reduced testcase below now runs correctly.
>
> The patch and testcase appear below.
>
> Paul
>
> Index: gcc/fortran/trans-expr.c
> ===
> --- gcc/fortran/trans-expr.c(révision 112853)
> +++ gcc/fortran/trans-expr.c(copie de travail)
> @@ -1832,6 +1832,7 @@
>gfc_charlen cl;
>gfc_expr *e;
>gfc_symbol *fsym;
> + stmtblock_t post;
>
>arglist = NULL_TREE;
>retargs = NULL_TREE;
> @@ -1861,6 +1862,7 @@
>else
> info = NULL;
>
> + gfc_init_block (&post);
>gfc_init_interface_mapping (&mapping);
>need_interface_mapping = ((sym->ts.type == BT_CHARACTER
> && sym->ts.cl->length
> @@ -1970,7 +1972,7 @@
> gfc_add_interface_mapping (&mapping, fsym, &parmse);
>
>gfc_add_block_to_block (&se->pre, &parmse.pre);
> - gfc_add_block_to_block (&se->post, &parmse.post);
> + gfc_add_block_to_block (&post, &parmse.post);
>
>/* Character strings are passed as two parameters, a length and a
> pointer. */
> @@ -2177,6 +2179,11 @@
> }
> }
>
> + if (byref)
> +gfc_add_block_to_block (&se->pre, &post);
> + else
> +gfc_add_block_to_block (&se->post, &post);
> +
>return has_alternate_specifier;
> }
>
> ! { dg-do run }
> ! Tests the fix for PR27124 in which the unpacking of argument
> ! temporaries and of array result temporaries occurred in the
> ! incorrect order.
> !
> ! Test is based on the original example, provided by
> ! Philippe Schaffnit <[EMAIL PROTECTED]>
> !
> PROGRAM Test
> INTEGER :: Array(2, 3) = reshape ((/1,4,2,5,3,6/),(/2,3/))
> integer :: Brray(2, 3) = 0
> Brray(1,:) = Function_Test (Array(1,:))
> if (any(reshape (Brray, (/6/)) .ne. (/11, 0, 12, 0, 13, 0/))) call abort
> ()
> Array(1,:) = Function_Test (Array(1,:))
> if (any(reshape (Array, (/6/)) .ne. (/11, 4, 12, 5, 13, 6/))) call abort
> ()
>
> contains
> FUNCTION Function_Test (Input)
> INTEGER, INTENT(IN) :: Input(1:3)
> INTEGER :: Function_Test(1:3)
> Function_Test = Input + 10
> END FUNCTION Function_Test
> END PROGRAM Test
>
> --
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27124
>
> --- You are receiving this mail because: ---
> You are on the CC list for the bug, or are watching someone who is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27124
[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets
--- Comment #28 from edmar at freescale dot com 2006-04-12 15:36 --- I double checked everything. The sources I checked out last night has the patches of comments 17, 21, and 25. This time I got a failure just like the on comment 7. The insn is the same The original attachment: floatformat.i, still good. I can reproduce the error with it. /local/gnu_toolchain/build_area/obj_gcc-trunk_e500v1/obj_gcc-trunk_e500v2/powerpc-unknown-linux-gnuspe/libiberty> /local/gnu_toolchain/build_area/obj_gcc-trunk_e500v1/obj_gcc-trunk_e500v2/./gcc/xgcc -B/local/gnu_toolchain/build_area/obj_gcc-trunk_e500v1/obj_gcc-trunk_e500v2/./gcc/ -B/local/gnu_toolchain/install_area/gcc-trunk-20060411-e500v2/powerpc-unknown-linux-gnuspe/bin/ -B/local/gnu_toolchain/install_area/gcc-trunk-20060411-e500v2/powerpc-unknown-linux-gnuspe/lib/ -isystem /local/gnu_toolchain/install_area/gcc-trunk-20060411-e500v2/powerpc-unknown-linux-gnuspe/include -isystem /local/gnu_toolchain/install_area/gcc-trunk-20060411-e500v2/powerpc-unknown-linux-gnuspe/sys-include -c -DHAVE_CONFIG_H -O2 -g -O2 -I. -I../../../gcc-trunk/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat ../../../gcc-trunk/libiberty/floatformat.c -o floatformat.o -v --save-temps Reading specs from /local/gnu_toolchain/build_area/obj_gcc-trunk_e500v1/obj_gcc-trunk_e500v2/./gcc/specs Target: powerpc-unknown-linux-gnuspe Configured with: ../gcc-trunk/configure --prefix=/local/gnu_toolchain/install_area/gcc-trunk-20060411-e500v2 --with-local-prefix=/local/gnu_toolchain/install_area/gcc-trunk-20060411-e500v2 --enable-languages=c,c++ --enable-threads --target=powerpc-unknown-linux-gnuspe --disable-shared --disable-multilib --disable-linux-futex --enable-e500_double Thread model: posix gcc version 4.2.0 20060411 (experimental) /local/gnu_toolchain/build_area/obj_gcc-trunk_e500v1/obj_gcc-trunk_e500v2/./gcc/cc1 -E -quiet -v -I. -I../../../gcc-trunk/libiberty/../include -iprefix /temp/gnu_toolchain/build_area/obj_gcc-trunk_e500v1/obj_gcc-trunk_e500v2/gcc/../lib/gcc/powerpc-unknown-linux-gnuspe/4.2.0/ -isystem /local/gnu_toolchain/build_area/obj_gcc-trunk_e500v1/obj_gcc-trunk_e500v2/./gcc/include -D__unix__ -D__gnu_linux__ -D__linux__ -Dunix -D__unix -Dlinux -D__linux -Asystem=linux -Asystem=unix -Asystem=posix -DHAVE_CONFIG_H -isystem /local/gnu_toolchain/install_area/gcc-trunk-20060411-e500v2/powerpc-unknown-linux-gnuspe/include -isystem /local/gnu_toolchain/install_area/gcc-trunk-20060411-e500v2/powerpc-unknown-linux-gnuspe/sys-include ../../../gcc-trunk/libiberty/floatformat.c -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat -fworking-directory -O2 -O2 -fpch-preprocess -o floatformat.i ignoring nonexistent directory "/local/gnu_toolchain/install_area/gcc-trunk-20060411-e500v2/powerpc-unknown-linux-gnuspe/include" ignoring nonexistent directory "/temp/gnu_toolchain/build_area/obj_gcc-trunk_e500v1/obj_gcc-trunk_e500v2/gcc/../lib/gcc/powerpc-unknown-linux-gnuspe/4.2.0/include" ignoring nonexistent directory "/temp/gnu_toolchain/build_area/obj_gcc-trunk_e500v1/obj_gcc-trunk_e500v2/gcc/../lib/gcc/powerpc-unknown-linux-gnuspe/4.2.0/../../../../powerpc-unknown-linux-gnuspe/sys-include" ignoring nonexistent directory "/temp/gnu_toolchain/build_area/obj_gcc-trunk_e500v1/obj_gcc-trunk_e500v2/gcc/../lib/gcc/powerpc-unknown-linux-gnuspe/4.2.0/../../../../powerpc-unknown-linux-gnuspe/include" ignoring duplicate directory "/local/gnu_toolchain/install_area/gcc-trunk-20060411-e500v2/lib/gcc/powerpc-unknown-linux-gnuspe/4.2.0/../../../../powerpc-unknown-linux-gnuspe/sys-include" ignoring nonexistent directory "/local/gnu_toolchain/install_area/gcc-trunk-20060411-e500v2/lib/gcc/powerpc-unknown-linux-gnuspe/4.2.0/../../../../powerpc-unknown-linux-gnuspe/include" #include "..." search starts here: #include <...> search starts here: . ../../../gcc-trunk/libiberty/../include /local/gnu_toolchain/build_area/obj_gcc-trunk_e500v1/obj_gcc-trunk_e500v2/./gcc/include /local/gnu_toolchain/install_area/gcc-trunk-20060411-e500v2/powerpc-unknown-linux-gnuspe/sys-include /local/gnu_toolchain/install_area/gcc-trunk-20060411-e500v2/lib/gcc/powerpc-unknown-linux-gnuspe/4.2.0/include End of search list. /local/gnu_toolchain/build_area/obj_gcc-trunk_e500v1/obj_gcc-trunk_e500v2/./gcc/cc1 -fpreprocessed floatformat.i -quiet -dumpbase floatformat.c -auxbase-strip floatformat.o -g -O2 -O2 -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes -Wc++-compat -version -o floatformat.s GNU C version 4.2.0 20060411 (experimental) (powerpc-unknown-linux-gnuspe) compiled by GNU C version 3.4.3. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 46d139d3138e283288bcfc291691aee0 ../../../gcc-trunk/libiberty/floatformat.c: In function 'floatformat_to_double': ../../../gcc-trunk/libiberty/floatformat.c:415: error: unrecognizable insn: (insn 342 340 128 14 ../../../gcc-trunk/libiberty/floatformat.c:383 (set (re
[Bug classpath/24481] SecureRandom.setSeed has no impact
--- Comment #10 from cvs-commit at developer dot classpath dot org 2006-04-12 16:39 --- Subject: Bug 24481 CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Casey Marshall <[EMAIL PROTECTED]> 06/04/12 16:38:50 Modified files: . : ChangeLog gnu/java/security/jce/prng: SecureRandomAdapter.java gnu/java/security/prng: MDGenerator.java Log message: 2006-04-12 Casey Marshall <[EMAIL PROTECTED]> Fixes PR classpath/24481. * gnu/java/security/jce/prng/SecureRandomAdapter.java (): initialize the adaptee. (setSeed): call `addRandomBytes;' don't re-initialize the adaptee. * gnu/java/security/prng/MDGenerator.java (addRandomByte, addRandomBytes): new methods. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.7086&tr2=1.7087&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/gnu/java/security/jce/prng/SecureRandomAdapter.java.diff?tr1=1.1&tr2=1.2&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/gnu/java/security/prng/MDGenerator.java.diff?tr1=1.2&tr2=1.3&r1=text&r2=text -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24481
[Bug rtl-optimization/26961] [4.0/4.1/4.2 Regression] ICE simplify_subreg:3813
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-04-12 17:24
---
Even shorter testcase:
===
int foo(int i, int j)
{
return i ? (long long)(!j) : 0;
}
===
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Keywords||monitored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26961
[Bug c/27136] New: Compile failure with -O -ffast-math
This program, compiled -O -ffast-math, seems to consume infinite stack space
/* -O -ffast-math */
void foo()
{
double x;
for (x = 2; x < 10; x *= x)
;
}
--
Summary: Compile failure with -O -ffast-math
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: trt at acm dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27136
[Bug middle-end/27132] Fold does not canonicalize i - -1
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-12 17:34 --- Yes I already filed a couple bugs about turning this on for the !flag_wrapv case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27132
[Bug java/27101] GCJ rejects valid code (for Sun's measure of "valid')
--- Comment #4 from tromey at gcc dot gnu dot org 2006-04-12 17:38 --- I thought this looked like a dup, but I can't find the original. In any case, ISTR looking at the logic here in gcj at one point, and finding that it was all screwed up. Pinski: you can do: sed 's/^.//d' > File.java and then cut and paste... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27101
[Bug middle-end/27132] Fold does not canonicalize i - -1
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-12 17:39 --- You need to fix PR 25148 first before fixing this bug really otherwise you will get a testsuite failure as I got before. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||25148 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27132
[Bug c++/27084] Does not propagate memory load base through useless type conversion
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-04-12 17:40 --- (In reply to comment #9) > PASS: g++.old-deja/g++.mike/dyncast7.C (test for excess errors) > FAIL: g++.old-deja/g++.mike/dyncast7.C execution test I did not get that failure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27084
[Bug java/13021] GCJ Boehm descriptor may be incorrect if alignment != sizeof(void*)
--- Comment #2 from tromey at gcc dot gnu dot org 2006-04-12 17:42 --- I don't have a convenient way to test a fix for this. But it does not look very hard to fix... just adding an extra check in boehm.c:mark_reference_fields. Note that the corresponding code in libgcj already seems to handle this case: // If we run into a weird situation, we bail. if (off % sizeof (void *) != 0) return (void *) (GCJ_DEFAULT_DESCR); -- 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=13021
[Bug middle-end/27134] [4.1/4.2 regression] ICE with floor and -ffast-math
--- Comment #3 from uros at kss-loka dot si 2006-04-12 17:54 ---
> There seems to be something wrong with -ffast-math and floor.
I have done some analysis on this. Start from expand_builtin_int_roundingfn()
in builtins.c source, where we fallback to FP rounding optab.
fallback_fndecl from mathfn_builtin looks like:
unit size
align 64 symtab 0 alias set -1 precision 64
pointer_to_this >
QI
size
unit size
align 8 symtab 0 alias set -1
arg-types
chain >>
pointer_to_this >
readonly used nothrow public external built-in decl_6 QI file
line 0
built-in BUILT_IN_NORMAL:BUILT_IN_FLOOR attributes
(mem:QI (symbol_ref:DI ("floor") [flags 0x41] ) [0 S1 A8]) chain >
After that, build_function_call_expr() is called, with an argument list:
unit size
align 64 symtab 0 alias set -1 precision 64
pointer_to_this >
arg 0
used SI file pr27134.c line 5
size
unit size
align 32 context initial
(reg/v:SI 59 [ i ]) arg-type
This is simplified in fold_build3() to:
unit size
align 64 symtab 0 alias set -1 precision 64
pointer_to_this >
arg 0
arg 0
used SI file pr27134.c line 5
size
unit size
align 32 context initial
(reg/v:SI 59 [ i ]) arg-type
incoming-rtl (reg:SI 5 di [ i ])>>>
It looks to me, that fold_convert3() is trying to kill
(int) __builtin_lfloor ((double) i), where i is an integer argument.
Uros.
--
uros at kss-loka dot si changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |uros at kss-loka dot si
|dot org |
Status|NEW |ASSIGNED
Last reconfirmed|2006-04-12 14:59:12 |2006-04-12 17:54:41
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27134
[Bug middle-end/27132] Fold does not canonicalize i - -1
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-12 18:06 --- This is basicially PR 23295. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||23295 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27132
[Bug middle-end/23295] fold does not simplify -a - (5) to (-5) - a
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-04-12 18:10 --- Didn't we have the canonicalization to put the constant in operand2 if possible? A lot of transformations rely on that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23295
[Bug bootstrap/27133] Fails to build because of funny version of makeinfo
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-12 18:18 --- Are you building from a release version, correct? Otherwise you do need makeinfo as explained by: http://gcc.gnu.org/install/prerequisites.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27133
[Bug classpath/24481] SecureRandom.setSeed has no impact
--- Comment #11 from csm at gnu dot org 2006-04-12 18:19 --- Fixed for message digest-based PRNGs. -- csm at gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |0.91 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24481
[Bug bootstrap/27135] [4.2 Regression] parser.c:10895: warning: 'is_parenthesized_init' may be used uninitialized in this function
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-12 18:20 --- Fixed by: http://gcc.gnu.org/ml/gcc-cvs/2006-04/msg00302.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c++ |bootstrap Resolution||FIXED Summary|parser.c:10895: warning:|[4.2 Regression] |'is_parenthesized_init' may |parser.c:10895: warning: |be used uninitialized in|'is_parenthesized_init' may |this function |be used uninitialized in ||this function Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27135
[Bug tree-optimization/24609] [4.1/4.2 regression] Same value duplicated in two different registers
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24609
[Bug libgcj/27066] libgcj native socket code does not support IPv6
--- Comment #5 from cjw at daneel dot dyndns dot org 2006-04-12 19:08 --- There are probably disadvantages: it doesn't seem possible to bind to 127.0.0.1 this way. So choosing the socket domain that matches the address to bind/connect to is probably a good idea. I thought other java implementations use the IPv4-in-IPv6 system but now I'm not so sure about that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27066
[Bug preprocessor/27137] New: Without -I- gcc needs another way to defer source dir. search
The -I option inhibits the use of the current file directory as the first search directory for #include "file". This is important for software development which uses partially populated source trees for which the build "looks through" other trees to find the missing pieces. Without -I- gcc should offer something like the IBM xlc -qidirfirst option: Specifies the search order for files included with the '#include' directive. Use -qidirfirst with the -I option. If -qidirfirst is specified, the directories specified by the -I option are searched before the directory where the current file resides. The default is -qnoidirfirst. This is all we need, but over the last 10 years we have instead pushed vendors to support the -I- option. It is sadly ironic that gcc deprecates it. My employer does not use `nmake', but `nmake' has noticed this too: http://www.bell-labs.com/project/nmake/newsletters/issue021.html -- Summary: Without -I- gcc needs another way to defer source dir. search Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: trt at acm dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27137
[Bug fortran/25597] ICE with allocate on the return value of a function, character array with a len of an argument
--- Comment #7 from patchapp at dberlin dot org 2006-04-12 19:28 --- Subject: Bug number PR25597 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/2006-04/msg00350.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25597
[Bug fortran/27124] Incorrect dependency for assignment from function with array section actual arg.
--- Comment #4 from patchapp at dberlin dot org 2006-04-12 19:30 --- Subject: Bug number PR27124 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/2006-04/msg00468.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27124
[Bug fortran/26834] gfc_todo: Not Implemented: Unable to determine rank of expression
--- Comment #3 from patchapp at dberlin dot org 2006-04-12 19:55 --- Subject: Bug number PR26834 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/2006-04/msg00469.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26834
[Bug libgcj/23829] FreeBSD 5 support for libjava
--- Comment #7 from gerald at gcc dot gnu dot org 2006-04-12 19:57 --- Subject: Bug 23829 Author: gerald Date: Wed Apr 12 19:57:02 2006 New Revision: 112897 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112897 Log: PR libgcj/23829 * configure.ac: Link against -lpthread rather than -lc_r on FreeBSD 5 and above. * configure: Regenerate. Modified: trunk/libjava/ChangeLog trunk/libjava/configure trunk/libjava/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23829
[Bug libgcj/23829] FreeBSD 5 support for libjava
--- Comment #8 from gerald at pfeifer dot com 2006-04-12 19:59 --- I committed this to HEAD and the 4.1-branch now. Thanks to everyone who helped review this, and of course the original submitter! -- gerald at pfeifer dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23829
[Bug target/27117] [4.2 Regression] gcc fails to build on sh64-elf targets
--- Comment #5 from amylaar at gcc dot gnu dot org 2006-04-12 19:59 --- Created an attachment (id=11251) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11251&action=view) proposed patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27117
[Bug libgomp/25938] [4.2 regression] libgomp installs header files in version and target independent location
--- Comment #7 from gerald at pfeifer dot com 2006-04-12 20:01 --- RTH, Jakub, would you mind having a look at this regression? -- gerald at pfeifer dot com changed: What|Removed |Added CC||rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25938
[Bug target/27060] divide libcall size has increased
--- Comment #2 from amylaar at gcc dot gnu dot org 2006-04-12 20:09 --- Subject: Bug 27060 Author: amylaar Date: Wed Apr 12 20:09:41 2006 New Revision: 112898 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112898 Log: 2006-04-12 J"orn Rennecke <[EMAIL PROTECTED]> PR target/27060 * config/sh/lib1funcs.h: New file, broken out of: * config/sh/lib1funcs.asm. * config/sh/lib1funcs.h (DR00, DR01, DR20, DR21, DR40, DR41): New macros. * config/sh/lib1funcs.asm (udivsi3_i4): Use them. * config/sh/lib1funcs-Os-4-200.asm: New file. * config/sh/embed-elf.h (LIBGCC_SPEC): Use -lgcc-Os-4-200. * config/sh/t-sh (OPT_EXTRA_PARTS): New variable. (EXTRA_MULTILIB_PARTS): Include it. ($(T)sdivsi3_i4i-Os-4-200.o): New rule. ($(T)udivsi3_i4i-Os-4-200.o, $(T)libgcc-Os-4-200.a): Likewise. * config/sh/t-superh (EXTRA_MULTILIB_PARTS): Include OPT_EXTRA_PARTS. * config/sh/sh.h (OVERRIDE_OPTIONS): Recognize -mdiv=call-table for TARGET_SH2. Added: trunk/gcc/config/sh/lib1funcs-Os-4-200.asm trunk/gcc/config/sh/lib1funcs.h Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/embed-elf.h trunk/gcc/config/sh/lib1funcs.asm trunk/gcc/config/sh/sh.h trunk/gcc/config/sh/t-sh trunk/gcc/config/sh/t-superh -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27060
[Bug crypto/27111] SecureRandom isn't seeded on creation
--- Comment #3 from csm at gnu dot org 2006-04-12 20:17 --- *** This bug has been marked as a duplicate of 24642 *** -- csm at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27111
[Bug classpath/24642] Failure to produce random values.
--- Comment #3 from csm at gnu dot org 2006-04-12 20:17 --- *** Bug 27111 has been marked as a duplicate of this bug. *** -- csm at gnu dot org changed: What|Removed |Added CC||csm at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24642
[Bug preprocessor/27137] Without -I- gcc needs another way to defer source dir. search
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-12 20:18 --- What do you need exactly that -iquote or any of the -i* options provide? Or even what this patch should provide: http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01197.html That adds an option to do what exactly -I- did except for not change the behavior of -I* after -I-. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27137
[Bug classpath/24642] Failure to produce random values.
--- Comment #4 from csm at gnu dot org 2006-04-12 20:18 --- Testing a patch. -- csm at gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |csm at gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24642
[Bug preprocessor/19541] deprecation of -I- makes precompiled headers less usable
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-12 20:19 --- Patch posted here: http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01197.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||03/msg01197.html Status|UNCONFIRMED |NEW Component|pch |preprocessor Ever Confirmed|0 |1 Keywords||patch Last reconfirmed|-00-00 00:00:00 |2006-04-12 20:19:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19541
[Bug preprocessor/27137] Without -I- gcc needs another way to defer source dir. search
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-12 20:19 --- If that patch does the trick for you, then this is a dup of bug 19541. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27137
[Bug fortran/27138] New: gfortran: Fails to
-- Summary: gfortran: Fails to Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27138
[Bug fortran/27138] gfortran: Fails to
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de 2006-04-12 20:45 --- Created an attachment (id=11252) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11252&action=view) test.tar.gz containing inp-test and test.F This is SUSE's gcc-fortran-4.1.0-15, "Merge[d] up to rev 112748 for gfortran changes on the branch." The attached program "test.F" reads an inputfile (also attached), which contains three lines: 1| igrd=1,lwb=F,ndvgrd=6,idsprs=0,chng=-0.100D-11 2| 3| 12 This file is read by three "READ (5,*,END=,ERR=) ntype" lines. With Ifort, the first READ has an error and the second read gets the "12". With gfortran, all three reads get an error. Expected: Either the second or the third read picks up the 12. The attached program prints with the Intel Fortran Compiler 9.0.033: Second read: ntype = 12 whereas with gfortran it only shows: Error glancing at inp-file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27138
[Bug middle-end/27139] New: Optimize double INT->FP->INT conversions
This testcase:
int test (int a)
{
return (double) a;
}
Produces:
cvtsi2sd%edi, %xmm0
cvttsd2si %xmm0, %eax
ret
However, following code does the same (at least for -ffast-math):
movl%edi, %eax
ret
--
Summary: Optimize double INT->FP->INT conversions
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uros at kss-loka dot si
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27139
[Bug fortran/25619] temporary array of constant size character type goes wrong
--- Comment #8 from hjl at gcc dot gnu dot org 2006-04-12 20:58 --- Subject: Bug 25619 Author: hjl Date: Wed Apr 12 20:58:04 2006 New Revision: 112899 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112899 Log: gcc/fortran/ 2006-04-12 H.J. Lu <[EMAIL PROTECTED]> PR fortran/25619 Backport from mainline 2006-04-04 H.J. Lu <[EMAIL PROTECTED]> * trans-array.c (gfc_conv_expr_descriptor): Only dereference character pointer when copying temporary. PR fortran/23634 Backport from mainline 2006-04-04 H.J. Lu <[EMAIL PROTECTED]> * trans-array.c (gfc_conv_expr_descriptor): Properly copy temporary character with non constant size. gcc/testsuite/ 2006-04-12 H.J. Lu <[EMAIL PROTECTED]> PR fortran/23634 PR fortran/25619 Backport from mainline 2006-04-04 Paul Thomas <[EMAIL PROTECTED]> * gfortran.dg/actual_array_constructor_1.f90: New testcase. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/actual_array_constructor_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/trans-array.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25619
[Bug fortran/23634] temporary array of character ICE with non constant size
--- Comment #8 from hjl at gcc dot gnu dot org 2006-04-12 20:58 --- Subject: Bug 23634 Author: hjl Date: Wed Apr 12 20:58:04 2006 New Revision: 112899 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112899 Log: gcc/fortran/ 2006-04-12 H.J. Lu <[EMAIL PROTECTED]> PR fortran/25619 Backport from mainline 2006-04-04 H.J. Lu <[EMAIL PROTECTED]> * trans-array.c (gfc_conv_expr_descriptor): Only dereference character pointer when copying temporary. PR fortran/23634 Backport from mainline 2006-04-04 H.J. Lu <[EMAIL PROTECTED]> * trans-array.c (gfc_conv_expr_descriptor): Properly copy temporary character with non constant size. gcc/testsuite/ 2006-04-12 H.J. Lu <[EMAIL PROTECTED]> PR fortran/23634 PR fortran/25619 Backport from mainline 2006-04-04 Paul Thomas <[EMAIL PROTECTED]> * gfortran.dg/actual_array_constructor_1.f90: New testcase. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/actual_array_constructor_1.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/trans-array.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23634
[Bug fortran/27138] gfortran: read(*,*) myInt advances only one character on error
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de
2006-04-12 21:05 ---
If one replaces the third read by
character(len=300) :: str
READ (5,*,END=100,ERR=99) str
WRITE(*,*) trim(str)
one sees that the first two failing READs advance by one character each
('i','g').
The third (string) read then reads up to the comma ('td=1')
I would expect (as well as the program writer) that after the failed read one
is still in the next line (as ADVANCE=YES is implied).
Why the read(5,*) str only reads up to the comma and not the whole line, is
also an enigma for me.
G95 (GCC 4.0.3 (g95!) Apr 4 2006,
pgf95 6.0-5
PathScale EKOPath Version 2.1
(and as mentioned) Intel Fortran Compiler 9.0.033
all read the "12" with the second read.
--
tobias dot burnus at physik dot fu-berlin dot de changed:
What|Removed |Added
Summary|gfortran: Fails to |gfortran: read(*,*) myInt
||advances only one character
||on error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27138
[Bug middle-end/26729] [4.0/4.1/4.2 regression] bad bitops folding
--- Comment #12 from steven at gcc dot gnu dot org 2006-04-12 21:28 --- fold_truthop is called with this input: Breakpoint 11, fold_truthop (code=TRUTH_ANDIF_EXPR, truth_type=0x2adff4d0, lhs=0x2adf64b0, rhs=0x2adf6690) at fold-const.c:4820 4820 if (TREE_SIDE_EFFECTS (lhs) || TREE_SIDE_EFFECTS (rhs)) (gdb) p debug_generic_expr(lhs) (intD.0) wordD.1878 & 1 $50 = void (gdb) p debug_generic_expr(rhs) ((intD.0) wordD.1878 & 08000) == 32768 $51 = void (gdb) And it folds this input to 0, which is wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26729
[Bug target/27117] [4.2 Regression] gcc fails to build on sh64-elf targets
--- Comment #6 from kkojima at gcc dot gnu dot org 2006-04-12 21:43 --- > -#define INDEX_REG_CLASS \ > - (!ALLOW_INDEXED_ADDRESS ? NO_REGS : TARGET_SHMEDIA ? GENERAL_REGS : > R0_REGS) > +#define INDEX_REG_CLASS_FOR_MODE(MODE) \ > + ((MODE) == DImode && TARGET_SHMEDIA ? 1 \ Should this last 1 be GENERAL_REGS? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27117
[Bug libgcj/26483] Wrong parsing of doubles when interpreted on ia64
--- Comment #18 from wilson at gcc dot gnu dot org 2006-04-12 22:10 --- Subject: Bug 26483 Author: wilson Date: Wed Apr 12 22:10:49 2006 New Revision: 112900 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112900 Log: Fix IA-64 problems with denorms getting clobbered by type conversions. PR libgcj/26483 * src/ia64/ffi.c (stf_spill, ldf_fill): Rewrite as macros. (hfa_type_load): Call stf_spill. (hfa_type_store): Call ldf_fill. (ffi_call): Adjust calls to above routines. Add local temps for macro result. Modified: trunk/libffi/ChangeLog trunk/libffi/src/ia64/ffi.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26483
[Bug libgcj/26483] Wrong parsing of doubles when interpreted on ia64
--- Comment #19 from wilson at gcc dot gnu dot org 2006-04-12 22:21 --- IA-64. Mine. -- wilson at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |wilson at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-12 22:21:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26483
[Bug libgcj/26483] Wrong parsing of doubles when interpreted on ia64
--- Comment #20 from wilson at gcc dot gnu dot org 2006-04-12 22:22 --- Fixed on mainline. Testcase added to mainline. The fix should probably be backported to one or more active release branches. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC|wilson at gcc dot gnu dot | |org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26483
[Bug middle-end/26823] ICE with OpenMP in add_stmt_to_eh_region_fn, at tree-eh.c:100
--- Comment #2 from giovannibajo at libero dot it 2006-04-12 22:25 --- RTH, this bug is very serious for OpenMP and C++. Can you please have a look? -- giovannibajo at libero dot it changed: What|Removed |Added CC||rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26823
[Bug c/26751] [4.2 Regression] Some OpenMP semantics are caught too late (in the gimplifier)
-- steven at gcc dot gnu dot org changed: What|Removed |Added CC||rth at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-12 22:41:46 date|| Summary|Some OpenMP semantics are |[4.2 Regression] Some OpenMP |caught too late (in the |semantics are caught too |gimplifier) |late (in the gimplifier) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26751
[Bug middle-end/27139] Optimize double INT->FP->INT conversions with -ffast-math
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-12 23:59 --- Confirmed, I doubt this shows up that much anyways. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet|x86_64-unknown-linux-gnu| Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2006-04-12 23:59:25 date|| Summary|Optimize double INT->FP->INT|Optimize double INT->FP->INT |conversions |conversions with -ffast-math http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27139
[Bug fortran/27138] gfortran: read(*,*) myInt advances only one character on error
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-04-13 00:22 --- I will investigate. -- 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 |2006-04-13 00:22:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27138
[Bug middle-end/26729] [4.0/4.1/4.2 regression] bad bitops folding
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-04-13 00:54 --- It has to be the: /* See if the comparisons can be merged. Then get all the parameters for each side. */ which gets it wrong for some reason. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26729
[Bug middle-end/23295] fold does not simplify -a - (5) to (-5) - a
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-04-13 01:01 --- (In reply to comment #7) > Didn't we have the canonicalization to put the constant in operand2 if > possible? A lot of transformations rely on that. Why should they in this case, they only rely on that for operations that are comunitive and minus is not. "(-5) - a" is simplier than -a - 5 in reality. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23295
[Bug target/26961] [4.0/4.1/4.2 Regression] ICE simplify_subreg:3813
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-13 01:05 --- the TRUTH_AND_EXPR is long long here and we produce an ICE while expanding to RTL so this is a middle-end issue. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|rtl-optimization|target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26961
[Bug c++/27115] [4.0/4.1/4.2 Regression] ICE in cp_expr_size or miscompilation with statement expressions and constructors (and ?: )
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-13 01:17 --- for the orginal expample: 3.3.3 ICE 3.4.0 worked 3.2.2 ICE 3.0.4 ICE 2.95.3 ICE I don't think we should call this critical as this is using an extension in the first place and it only ICEs with the extension in fact. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Summary|[4.0/4.1/4.2 Regression] ICE|[4.0/4.1/4.2 Regression] ICE |in cp_expr_size or |in cp_expr_size or |miscompilation with |miscompilation with |statement expressions and |statement expressions and |constructors|constructors (and ?: ) Target Milestone|4.1.1 |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27115
[Bug c/27126] -Wswitch-enums doesn't detect impossible cases in switch()
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-13 01:27 --- *** This bug has been marked as a duplicate of 23577 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27126
[Bug c/23577] suprious warnings about unhanled cases in switches
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-13 01:27 --- *** Bug 27126 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||ramune+gcc at net-ronin dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23577
[Bug middle-end/27136] [4.0/4.1/4.2 Regression] Compile failure with -O -ffast-math
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-13 01:37 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c |middle-end Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.0.0 4.1.0 4.2.0 Known to work||3.4.0 Last reconfirmed|-00-00 00:00:00 |2006-04-13 01:37:35 date|| Summary|Compile failure with -O - |[4.0/4.1/4.2 Regression] |ffast-math |Compile failure with -O - ||ffast-math Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27136
[Bug bootstrap/27133] Fails to build because of funny version of makeinfo
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-13 01:41 --- Can you show how it fails also because this is not enough information really. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27133
[Bug other/27063] Fail to build gcc-core-4.2 snapshots
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-13 01:44 --- The thread starts: http://gcc.gnu.org/ml/gcc/2006-03/msg00192.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-13 01:44:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27063
[Bug target/27055] Structures are copied byte by byte into function arguments
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-13 01:52 --- This works on most targets I tried, ppc-linux-gnu and x86_64-linux-gnu both work, only i?86-linux-gnu (32bit) did not. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|middle-end |target Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-13 01:52:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27055
[Bug debug/27057] [4.0 Regression] ICE with -feliminate-dwarf2-dups and using namespace
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Known to fail||4.0.3 Known to work||3.4.0 4.1.0 4.2.0 Summary|[4.0/4.1/4.2 Regression] ICE|[4.0 Regression] ICE with - |with -feliminate-dwarf2-dups|feliminate-dwarf2-dups and |and using namespace |using namespace Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27057
[Bug c++/27061] instantiation of template functions for locally defined classes
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-13 01:56 --- The diagnostic issue is PR 15672. *** This bug has been marked as a duplicate of 15672 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27061
[Bug c++/15672] local function causes werid warning
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-04-13 01:56 --- *** Bug 27061 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||mmirzaza at cs dot uwaterloo ||dot ca http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15672
[Bug fortran/27138] gfortran: read(*,*) myInt advances only one character on error
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2006-04-13 04:26 --- I have looked this over. Its a matter of what behavior is acceptable for each type of error we get. My interpretation of your testcase is that we should do a next_record when we detect the error before we do the generate_error if we are in ADVANCE_YES. So if its an error due to an I/O problem such as hardware failure we will just fail out like now. If its a "content of the file" error we do a next_record before going into th error handling code. This will presumably take us past the current line, ready for another read. I just wonder if this is the universal behavior we should have. Regardless, I will see if I can work up a patch and give it a spin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27138
[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets
--- Comment #29 from amodra at gcc dot gnu dot org 2006-04-13 05:10 --- Subject: Bug 26459 Author: amodra Date: Thu Apr 13 05:10:00 2006 New Revision: 112912 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112912 Log: PR target/26459 * config/rs6000/rs6000.c (rs6000_legitimize_reload_address): Don't optimize to lo_sum for DFmode if !TARGET_FPRS. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459
[Bug target/26459] [4.1/4.2 Regression] gcc fails to build on powerpc e500-double targets
--- Comment #30 from amodra at gcc dot gnu dot org 2006-04-13 05:46 --- Subject: Bug 26459 Author: amodra Date: Thu Apr 13 05:46:01 2006 New Revision: 112913 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112913 Log: PR target/26459 * config/rs6000/rs6000.c (rs6000_legitimize_reload_address): Don't optimize to lo_sum for DFmode if !TARGET_FPRS. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/rs6000/rs6000.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26459
[Bug fortran/26766] [F2003] Recursive I/O still (again) broken
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-04-13 06:25 --- Subject: Bug 26766 Author: jvdelisle Date: Thu Apr 13 06:24:58 2006 New Revision: 112914 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112914 Log: 2006-04-12 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/26766 * io/io.h: Add bit to identify associated unit as internal. * io/unit.c (get_external_unit): Renamed the find_unit_1 function to reflect the external unit functionality vs internal unit. (get_internal_unit): New function to allocate and initialize an internal unit structure. (get_unit): Use get_internal_unit and get_external_unit. (is_internal_unit): Revised to use new bit added in io.h. * io/transfer.c (data_transfer_init): Fix line width. (st_read_done): Free memory allocated for internal unit. (st_write_done): Add test to only flush and truncate when not an internal unit. Free memory allocated for internal unit. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/io.h trunk/libgfortran/io/transfer.c trunk/libgfortran/io/unit.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26766
[Bug fortran/26766] [F2003] Recursive I/O still (again) broken
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-04-13 06:30 --- Subject: Bug 26766 Author: jvdelisle Date: Thu Apr 13 06:30:04 2006 New Revision: 112915 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112915 Log: 2006-04-12 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/26766 * gfortran.dg/write_recursive.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/write_recursive.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26766
