[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not "inline" the static const double
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/20912] C++ FE emitting assignments to read-only global symbols
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20912
[Bug testsuite/23069] libmudflap.cth timeouts too short
--- Comment #2 from belyshev at depni dot sinp dot msu dot ru 2005-10-11 07:30 --- *** This bug has been marked as a duplicate of 20003 *** -- belyshev at depni dot sinp dot msu dot ru changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23069
[Bug libmudflap/20003] libmudflap.cth
--- Comment #4 from belyshev at depni dot sinp dot msu dot ru 2005-10-11 07:30 --- *** Bug 23069 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20003
[Bug middle-end/21766] [4.1 Regression] Bootstrap failure on i686-pc-cygwin
--- Comment #29 from dannysmith at users dot sourceforge dot net 2005-10-11 08:01 --- Updated patch here. http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00565.html Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21766
[Bug target/24257] [4.1 Regression] ICE: in extract_insn, at recog.c:2084 with -O -fgcse -fgcse-sm
--- Comment #5 from uros at kss-loka dot si 2005-10-11 08:55 --- (In reply to comment #4) > > gcse-sm blindly converted valid insn pattern into unrecognized insn pattern. The problem is in gcse.c, function replace_store_insn(), line 6294: 6293 mem = smexpr->pattern; 6294 insn = gen_move_insn (reg, SET_SRC (single_set (del))); 6295 insn = emit_insn_after (insn, del); This code does not handle parallels and replaces only destination of an insn pattern. "ashlsi3" pattern, as defined in i386.md also requires operand 0 and operand 1 to match (via ix86_expand_binary_operator ()). -- uros at kss-loka dot si changed: What|Removed |Added CC||uros at kss-loka dot si http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24257
[Bug fortran/24261] gfortran ALLOCATE statement does not align objects on 16-byte boundary
--- Comment #3 from mick at nag dot co dot uk 2005-10-11 09:26 --- Thanks - the problem is now fixed in 64-bit compilations. However, if I compile try.f and sub.c with the -m32 flag, I still get memory allocated on 8-byte boundaries rather than 16-byte. As Andrew said, this is down to the way glibc malloc behaves. I see that the glibc folks have discussed this before, also in relation to the use of SSE instructions, but don't intend to change the way malloc works: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795 After reading that discussion it's not entirely clear to me why there is so much objection to 16-byte alignment, but whatever, it leaves me in the position of having lots of SSE assembly code that I can only use from Fortran by kludges like this: allocate(workspace(1000)) if (is_on_16_byte_boundary(workspace)) then call assembly_routine(workspace) else if (is_on_8_byte_boundary(workspace)) then call assembly_routine(workspace(3)) end if Personally I think that the malloc in glibc should align to 16 bytes, but given that it sounds like that's not likely to happen, another way might be for gfortran to use memalign instead of malloc in its ALLOCATE routine. -- mick at nag dot co dot uk changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24261
[Bug libstdc++/24244] Problem with tr1::shared_ptr and pthreads_mutex_lock
--- Comment #4 from pcarlini at suse dot de 2005-10-11 09:55 --- The problem is confirmed, should be fixable. -- pcarlini at suse dot de changed: What|Removed |Added Last reconfirmed|2005-10-06 20:38:42 |2005-10-11 09:55:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24244
[Bug target/23585] [4.0 regression] mem_fun* code fine with -O1, bus error with -O2
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2005-10-11 10:42 --- Really interesting: it's a combination of TARGET_PTRMEMFUNC_VBIT_LOCATION, inlining, efficient stack slot allocation and delay slot scheduling! SPARC doesn't define TARGET_PTRMEMFUNC_VBIT_LOCATION so the compiler selects ptrmemfunc_vbit_in_pfn. This means typechk.c:get_member_function_from_ptrfunc will be building an expression of the form: __pfn & 1 ? *(*(p + __delta) + __pfn - 1) : __pfn (p + __delta) Now for the minimal class "Class" in the testcase, the function is not virtual and the alignment of p is 1. Thanks to inlining, the above expression boils down to: func & 1 ? *(*p + func - 1) : func (p) Of course func is a multiple of 4 so the first branch will not be executed, although it is compiled. Then delay slot scheduling kicks in: it hoists *p in the delay slot of the ? branch because register liveness analysis allows it to do so (the register set in the insn is dead in the second branch): sethi %hi(_ZNK5Class4vf0cEv), %l5 or %l5, %lo(_ZNK5Class4vf0cEv), %l0 andcc %l0, 1, %l3 bne .LL6 ld [%fp-17], %g1 mov %l0, %g1 and the game is over. The only approach to fixing this I can think of is to modify the selection logic of TARGET_PTRMEMFUNC_VBIT_LOCATION: if the target has strict alignment and delay slots, the macro should be set to ptrmemfunc_vbit_in_delta. What do you think, Mark? Thanks in advance. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||mark at codesourcery dot com Component|middle-end |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23585
[Bug rtl-optimization/23585] [4.0 regression] mem_fun* code fine with -O1, bus error with -O2
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2005-10-11 10:54 --- > The only approach to fixing this I can think of is to modify the selection > logic of TARGET_PTRMEMFUNC_VBIT_LOCATION: if the target has strict alignment > and delay slots, the macro should be set to ptrmemfunc_vbit_in_delta. Hum, no, I'm afraid this won't change anything. I guess the culprit is delay slot scheduling then. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Component|target |rtl-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23585
[Bug fortran/24261] gfortran ALLOCATE statement does not align objects on 16-byte boundary
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-11 11:19 --- This is really a glibc bug and needs to be fixed. The C standard says that malloc allocates that the right alignment so this is a glibc bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24261
Error at compiling linux-2.6.13.4
Hi, compiling linux-2.6.13.4 (vanilla) on my PC (linux-2.6.13.1, gcc-3.3.6, glibc-2.3.5). Problem (make): ... LD drivers/scsi/qla2xxx/built-in.o CC drivers/serial/serial_core.o *** glibc detected *** double free or corruption (!prev): 0x084dd188 *** drivers/serial/serial_core.c: In function `uart_set_info': drivers/serial/serial_core.c:799: internal compiler error: Neúspěšně ukončen (SIGABRT) Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[2]: *** [drivers/serial/serial_core.o] Error 1 make[1]: *** [drivers/serial] Error 2 make: *** [drivers] Error 2 thank -- Antonín Kolísek http://linuxx.hyperlinx.cz
[Bug debug/24304] Test suite file 20010209-1.c with -g1 gives gen_subprogram_die, at dwarf2out.c:10857
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-11 11:25 --- *** This bug has been marked as a duplicate of 16676 *** -- 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=24304
[Bug c/16676] [3.4 Regression] ICE with nested functions and -g1, blocks glibc
--- Comment #22 from pinskia at gcc dot gnu dot org 2005-10-11 11:25 --- *** Bug 24304 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||flash at pobox dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16676
[Bug middle-end/24303] Compiling results in internal comiler error: Bus error
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-11 11:26 --- Can you attach the preprocessed source? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24303
[Bug target/24230] [4.1 Regression] [altivec] ICE in extract_insn, at recog.c:2084
--- Comment #10 from bonzini at gcc dot gnu dot org 2005-10-11 11:38
---
This is as small as I could make it. Any other attempt to hoist something
causes it not to fail anymore (at -maltivec -O2). Interesting, given that GCSE
*does* the hoisting...
It's a reload problem.
typedef __attribute__((vector_size (16))) unsigned char vec;
void H_Pass_16_Altivec_C(vec vec_src, vec firs, vec sums1, vec sums2,
vec *FIR_Tab_16, unsigned char *Src)
{
vec tmp, spltb3, spltb4, spltb5, spltb6, mrghb3, mrglb3, mrghb4, mrglb4,
mrghb5, mrglb5, mrghb6, mrglb6, firs0, firs1, firs2, firs3, upkhb0, upklb0,
upkhb1, upklb1, upkhb2, upklb2, upkhb3, upklb3, upkhb4, spltb7, mrghb7,
mrglb7, firs4, spltb8, mrghb8, mrglb8, upklb4;
spltb3 = __builtin_altivec_vspltb (vec_src, 3);
spltb4 = __builtin_altivec_vspltb (vec_src, 4);
spltb5 = __builtin_altivec_vspltb (vec_src, 5);
spltb6 = __builtin_altivec_vspltb (vec_src, 6);
mrghb3 = __builtin_altivec_vmrghb (spltb3, spltb3);
mrglb3 = __builtin_altivec_vmrglb (spltb3, spltb3);
mrghb4 = __builtin_altivec_vmrghb (spltb4, spltb4);
mrglb4 = __builtin_altivec_vmrglb (spltb4, spltb4);
mrghb5 = __builtin_altivec_vmrghb (spltb5, spltb5);
mrglb5 = __builtin_altivec_vmrglb (spltb5, spltb5);
mrghb6 = __builtin_altivec_vmrghb (spltb6, spltb6);
mrglb6 = __builtin_altivec_vmrglb (spltb6, spltb6);
firs0 = FIR_Tab_16[0];
firs1 = FIR_Tab_16[1];
firs2 = FIR_Tab_16[2];
firs3 = FIR_Tab_16[3];
upkhb0 = __builtin_altivec_vupkhsb (firs0);
upklb0 = __builtin_altivec_vupklsb (firs0);
upkhb1 = __builtin_altivec_vupkhsb (firs1);
upklb1 = __builtin_altivec_vupklsb (firs1);
upkhb2 = __builtin_altivec_vupkhsb (firs2);
upklb2 = __builtin_altivec_vupklsb (firs2);
upkhb3 = __builtin_altivec_vupkhsb (firs3);
upklb3 = __builtin_altivec_vupklsb (firs3);
upkhb4 = __builtin_altivec_vupkhsb (firs);
*(char *) &tmp = (char) *(Src + 16);
L0:
sums1 = __builtin_altivec_vmladduhm (mrghb3, upkhb4, sums1);
sums2 = __builtin_altivec_vmladduhm (mrglb3, upkhb4, sums2);
sums1 = __builtin_altivec_vmladduhm (mrghb4, upkhb0, sums1);
sums2 = __builtin_altivec_vmladduhm (mrglb4, upklb0, sums2);
sums1 = __builtin_altivec_vmladduhm (mrghb5, upkhb1, sums1);
sums2 = __builtin_altivec_vmladduhm (mrglb5, upklb1, sums2);
sums1 = __builtin_altivec_vmladduhm (mrghb6, upkhb2, sums1);
sums2 = __builtin_altivec_vmladduhm (mrglb6, upklb2, sums2);
spltb7 = __builtin_altivec_vspltb (vec_src, 7);
mrghb7 = __builtin_altivec_vmrghb (spltb7, spltb7);
sums1 = __builtin_altivec_vmladduhm (mrghb7, upkhb3, sums1);
mrglb7 = __builtin_altivec_vmrglb (spltb7, spltb7);
sums2 = __builtin_altivec_vmladduhm (mrglb7, upklb3, sums2);
firs4 = FIR_Tab_16[4];
spltb8 = __builtin_altivec_vspltb (vec_src, 8);
mrghb8 = __builtin_altivec_vmrghb (spltb8, spltb8);
upkhb4 = __builtin_altivec_vupkhsb (firs4);
sums1 = __builtin_altivec_vmladduhm (mrghb8, upkhb4, sums1);
mrglb8 = __builtin_altivec_vmrglb ((vec)tmp, spltb8);
upklb4 = __builtin_altivec_vupklsb (firs4);
sums2 = __builtin_altivec_vmladduhm (mrglb8, upklb4, sums2);
tmp = __builtin_altivec_vspltish (5);
sums1 = __builtin_altivec_vsrah (sums1, tmp);
__builtin_altivec_vpkshus (sums1, sums2);
goto L0;
}
--
bonzini at gcc dot gnu dot org changed:
What|Removed |Added
GCC target triplet|powerpc-*-linux-gnu |powerpc-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24230
[Bug target/12098] gcc build fails without gas on ia64-hpux: error: invalid switch '-x'
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-10-11 11:48 --- This is now fixed by preventing to build with the HP's as. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12098
[Bug target/24306] New: va_arg gets confused when skipping over certain zero-sized types
va_arg seems to mess up the va_list when variadic variables have size 0, but
when have large alignment requirements. When the alignment is small, this
seems to work by chance.
$ gcc foo.c -o foo && ./foo
3 0
#include
#include
typedef int __attribute__ ((vector_size (16))) foo_t;
struct s
{
foo_t f[0];
} s1;
void
check (int x, ...)
{
int y;
va_list ap;
va_start (ap, x);
va_arg (ap, struct s);
y = va_arg (ap, int);
/* Expect output: 3 7 */
printf ("%d %d\n", x, y);
}
int main()
{
check (3, s1, 7);
return 0;
}
--
Summary: va_arg gets confused when skipping over certain zero-
sized types
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: major
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bje at gcc dot gnu dot org
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24306
[Bug middle-end/24239] spurious warning about clobbered variables w.r.t. longjmp
--- Comment #2 from dvilleneuve at kronos dot com 2005-10-11 12:28 ---
Indeed, in gcc-4.0.1, the previous code chunk does not elicit a warning.
However, a slightly modified version still gets a warning (tested
on RHEL-4, with ).
#include
extern int f(void);
extern int g(int);
extern jmp_buf jb;
extern int i;
int f(void)
{
int j;
if( i > 10 ) j = i;
else j = i + 10;
if( !setjmp(jb) ) {
g(j);
}
else {
j = -1;
}
return j;
}
--
dvilleneuve at kronos dot com changed:
What|Removed |Added
Version|3.4.4 |4.0.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24239
[Bug middle-end/24303] Compiling results in internal comiler error: Bus error
--- Comment #2 from mconstant at hancocklumber dot com 2005-10-11 12:33 --- I actually solved the problem. I had to just reinstall the kernel-headers and kernel-modules off of the slackware discs again and it works now. The files that were giving errors were corrupted somehow. I tried to close the case yesterday but it said I didn't have permission to change the Assigned to Field. -- mconstant at hancocklumber dot com changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24303
[Bug fortran/23815] Add -byteswapio flag
--- Comment #3 from tobi at gcc dot gnu dot org 2005-10-11 13:25 --- (In reply to comment #2) > In case anybody wants to work on this, I have an old unfinished patch lying > around that adds builtins and RTL codes for byteswap operation. This allows > to use platform specific tricks that almost any platform has. This would have to be implemented in the library, so the effects of such a patch would only matter in the code GCC generates when compiling the library. IOW, I don't think this would be of much benefit here. -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23815
[Bug tree-optimization/24307] New: ICE in early_tree_profile
/space/rguenther/obj/gcc-libgfortran/gcc/f951
/space/rguenther/src/gcc-libgfortran/gcc/testsuite/gfortran.fortran-torture/execute/character_select_1.f90
-quiet -dumpbase character_select_1.f90 -mtune=pentiumpro -auxbase
character_select_1 -O0 -w -version -fprofile-generate -o character_select_1.s
/space/rguenther/src/gcc-libgfortran/gcc/testsuite/gfortran.fortran-torture/execute/character_select_1.f90:
In function MAIN__:
/space/rguenther/src/gcc-libgfortran/gcc/testsuite/gfortran.fortran-torture/execute/character_select_1.f90:3:
internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
(gdb) bt
#0 0x080b94c6 in is_gimple_variable (t=0x0) at tree-gimple.c:239
#1 0x080b963e in is_gimple_val (t=0x0) at tree-gimple.c:366
#2 0x083ab6cc in tree_find_edge_insert_loc (e=,
bsi=0xbfa5e524, new_bb=0x0) at tree-cfg.c:2973
#3 0x083ab950 in bsi_commit_one_edge_insert (e=0x401cb2f8, new_bb=0x0)
at tree-cfg.c:3026
#4 0x083ae44f in bsi_commit_edge_inserts () at tree-cfg.c:3007
#5 0x082d2452 in branch_prob () at profile.c:1129
#6 0x0834c90a in tree_profiling () at tree-profile.c:246
#7 0x0834c22c in execute_one_pass (pass=0x855d3a0) at passes.c:832
Testcase from the gfortran.fortran-torture/execute suite:
CHARACTER(LEN=6) :: C = "STEVEN"
SELECT CASE (C)
CASE ("AAA":"EEE")
CALL abort
CASE ("R":"T")
CONTINUE
CASE DEFAULT
CALL abort
END SELECT
END
--
Summary: ICE in early_tree_profile
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P2
Component: tree-optimization
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=24307
[Bug middle-end/24303] Compiling results in internal comiler error: Bus error
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-11 13:28 --- Closing as invalid for now. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24303
[Bug target/24306] va_arg gets confused when skipping over certain zero-sized types
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-11 13:34 --- Hmm, this works for me with todays' compiler: earth:~>gcc t.c -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /home/peshtigo/pinskia/src/gnu/gcc/src/configure --target=i686-pc-linux-gnu --host=i686-pc-linux-gnu --enable-__cxa_atexit --enable-languages=c++,objc,java,f95 --prefix=/home/gates/pinskia/linux --enable-threads=posix --enable-shared Thread model: posix gcc version 4.1.0 20051011 (experimental) /home/gates/pinskia/linux/libexec/gcc/i686-pc-linux-gnu/4.1.0/cc1 -quiet -v t.c -quiet -dumpbase t.c -mtune=pentiumpro -auxbase t -version -o /tmp/ccyK6uLf.s #include "..." search starts here: #include <...> search starts here: /usr/local/include /home/gates/pinskia/linux/include /home/gates/pinskia/linux/lib/gcc/i686-pc-linux-gnu/4.1.0/include /home/gates/pinskia/linux/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../i686-pc-linux-gnu/include /usr/include End of search list. GNU C version 4.1.0 20051011 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.1.0 20051011 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 4eb5c7164a4d9c2ecd7466e6212b1162 /home/gates/pinskia/linux/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../i686-pc-linux-gnu/bin/as -V -Qy -o /tmp/ccOwBdYl.o /tmp/ccyK6uLf.s GNU assembler version 2.15.94 (i686-pc-linux-gnu) using BFD version 2.15.94 20041104 /home/gates/pinskia/linux/libexec/gcc/i686-pc-linux-gnu/4.1.0/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o /home/gates/pinskia/linux/lib/gcc/i686-pc-linux-gnu/4.1.0/crtbegin.o -L/home/gates/pinskia/linux/lib/gcc/i686-pc-linux-gnu/4.1.0 -L/home/gates/pinskia/linux/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../i686-pc-linux-gnu/lib -L/home/gates/pinskia/linux/lib/gcc/i686-pc-linux-gnu/4.1.0/../../.. /tmp/ccOwBdYl.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /home/gates/pinskia/linux/lib/gcc/i686-pc-linux-gnu/4.1.0/crtend.o /usr/lib/crtn.o earth:~>./a.out 3 7 - Can you suply the ouput of gcc -v? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24306
[Bug tree-optimization/24307] [4.1 regression] ICE in early_tree_profile
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Summary|ICE in early_tree_profile |[4.1 regression] ICE in ||early_tree_profile Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24307
[Bug rtl-optimization/23585] [4.0 regression] mem_fun* code fine with -O1, bus error with -O2
--- Comment #7 from giovannibajo at libero dot it 2005-10-11 13:43 --- Yes, I think the problem is in delay slot scheduling too. COND_EXPR means that either branch must not be evaluated because it could be illegal; if you hoist a mem from a branch into the delay slot of the condition, you are effectively partially evaluting the branch. -- giovannibajo at libero dot it changed: What|Removed |Added CC||giovannibajo at libero dot ||it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23585
[Bug tree-optimization/24307] [4.1 regression] ICE in early_tree_profile
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-11 13:44 ---
Confirmed, here is a C testcase:
struct a
{
void *l;
char *k;
};
void *f(struct a*, int len, char*);
void fgg(void)
{
void * gotovar;
struct a jmp[] = {{&&L1, ""}, {&&L2, "EEE"}, {&&L3, "T"}};
gotovar = f(jmp, 3, "STEVEN");
goto *gotovar;
L1:
__builtin_abort();
L2:
__builtin_abort();
L3:
goto L4;
L4:
;
}
--
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 |2005-10-11 13:44:20
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24307
[Bug rtl-optimization/23585] [4.0 regression] mem_fun* code fine with -O1, bus error with -O2
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2005-10-11 13:51 --- > Yes, I think the problem is in delay slot scheduling too. COND_EXPR means that > either branch must not be evaluated because it could be illegal; if you hoist > a > mem from a branch into the delay slot of the condition, you are effectively > partially evaluting the branch. Yes, that makes sense. At the moment the predicate used in reorg.c is may_trap_p so we would need to detect faulting instructions too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23585
Re: [Bug rtl-optimization/23585] [4.0 regression] mem_fun* code fine with -O1, bus error with -O2
On Oct 11, 2005, at 9:51 AM, ebotcazou at gcc dot gnu dot org wrote: --- Comment #8 from ebotcazou at gcc dot gnu dot org 2005-10-11 13:51 --- Yes, I think the problem is in delay slot scheduling too. COND_EXPR means that either branch must not be evaluated because it could be illegal; if you hoist a mem from a branch into the delay slot of the condition, you are effectively partially evaluting the branch. Yes, that makes sense. At the moment the predicate used in reorg.c is may_trap_p so we would need to detect faulting instructions too. may_trap_p is the correct thing as it should detect this instruction as trapping: /* Memory ref can trap unless it's a static var or a stack slot. */ case MEM: if (MEM_NOTRAP_P (x)) return 0; return rtx_addr_can_trap_p (XEXP (x, 0)); -- Pinski
[Bug rtl-optimization/23585] [4.0 regression] mem_fun* code fine with -O1, bus error with -O2
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-10-11 13:55 --- Subject: Re: [4.0 regression] mem_fun* code fine with -O1, bus error with -O2 On Oct 11, 2005, at 9:51 AM, ebotcazou at gcc dot gnu dot org wrote: > > > --- Comment #8 from ebotcazou at gcc dot gnu dot org 2005-10-11 > 13:51 --- >> Yes, I think the problem is in delay slot scheduling too. COND_EXPR >> means that >> either branch must not be evaluated because it could be illegal; if >> you hoist a >> mem from a branch into the delay slot of the condition, you are >> effectively >> partially evaluting the branch. > > Yes, that makes sense. At the moment the predicate used in reorg.c is > may_trap_p so we would need to detect faulting instructions too. may_trap_p is the correct thing as it should detect this instruction as trapping: /* Memory ref can trap unless it's a static var or a stack slot. */ case MEM: if (MEM_NOTRAP_P (x)) return 0; return rtx_addr_can_trap_p (XEXP (x, 0)); -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23585
[Bug target/24308] New: endless looping and memory allocation in i386.c:classify_argument
../../obj34/gcc/cc1plus -w -quiet -o /dev/null pr24278.min1.ii Killed Program received signal SIGINT, Interrupt. 0x006cd5c7 in classify_argument (mode=QImode, type=0x2a95a058f0, classes=0x7fbfffe050, bit_offset=0) at i386.c:2054 2054 if (TREE_CODE (field) == FIELD_DECL) (gdb) bt #0 0x006cd5c7 in classify_argument (mode=QImode, type=0x2a95a058f0, classes=0x7fbfffe050, bit_offset=0) at i386.c:2054 #1 0x006cd540 in classify_argument (mode=Variable "mode" is not available. ) at i386.c:2038 #2 0x006cd986 in examine_argument (mode=Variable "mode" is not available. ) at i386.c:2302 #3 0x006ce1af in ix86_return_in_memory (type=Variable "type" is not available. ) at i386.c:2870 #4 0x00723d69 in default_return_in_memory (type=Variable "type" is not available. ) at targhooks.c:152 #5 0x0053be73 in aggregate_value_p (exp=Variable "exp" is not available. ) at function.c:4269 #6 0x0053c091 in allocate_struct_function (fndecl=0x2a95a05270) at function.c:6464 #7 0x0041d67b in start_function (declspecs=Variable "declspecs" is not available. ) at decl.c:10354 #8 0x0046f264 in begin_function_definition (decl_specs=Variable "decl_specs" is not available. ) at semantics.c:1900 #9 0x00452d00 in cp_parser_init_declarator (parser=0x2a9590ffa0, decl_specifiers=0x2a95a02b40, prefix_attributes=0x0, ... (btw., source was reduced from valid code from PR24278 -- Summary: endless looping and memory allocation in i386.c:classify_argument Product: gcc Version: 3.4.5 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org GCC host triplet: x86_64-*-linux-gnu GCC target triplet: x86_64-*-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24308
[Bug target/24308] endless looping and memory allocation in i386.c:classify_argument
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-10-11 13:58 --- Created an attachment (id=9964) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9964&action=view) testcase testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24308
[Bug rtl-optimization/23585] [4.0 regression] mem_fun* code fine with -O1, bus error with -O2
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2005-10-11 13:59 --- > may_trap_p is the correct thing as it should detect this instruction as > trapping: > > /* Memory ref can trap unless it's a static var or a stack slot. */ > case MEM: >if (MEM_NOTRAP_P (x)) > return 0; >return rtx_addr_can_trap_p (XEXP (x, 0)); No, it's the other way around. The MEM is a stack slot so may_trap_p returns 0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23585
[Bug target/24306] va_arg gets confused when skipping over certain zero-sized types
--- Comment #2 from bje at gcc dot gnu dot org 2005-10-11 14:02 --- gcc version 4.1.0 20051010 (experimental) I managed to work out that you need to add -msse to trigger the bug. -- bje at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-10-11 14:02:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24306
[Bug rtl-optimization/22509] [4.1 regression] elemental.f90 testsuite failure (-fweb)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22509
[Bug rtl-optimization/22509] [4.1 regression] elemental.f90 testsuite failure (-fweb)
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-10-11 14:06 --- I am changing the target milestone back to 4.1 as this is most likely fortran specific, just nobody has found a C/C++ testcase for this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22509
[Bug rtl-optimization/22509] [4.1 regression] elemental.f90 testsuite failure (-fweb)
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-10-11 14:07 --- (In reply to comment #10) > I am changing the target milestone back to 4.1 as this is most likely fortran > specific, just nobody has found a C/C++ testcase for this bug. I mean this is most likely ___NOT___ fortran specific. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22509
[Bug target/24306] [3.4/4.0/4.1 Regression] va_arg gets confused when skipping over certain zero-sized types with -msse
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-11 14:09 --- Confirmed, a regression from 3.3.3. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||3.4.0 4.0.0 4.1.0 Known to work||3.3.3 Summary|va_arg gets confused when |[3.4/4.0/4.1 Regression] |skipping over certain zero- |va_arg gets confused when |sized types |skipping over certain zero- ||sized types with -msse Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24306
[Bug target/24308] endless looping and memory allocation in i386.c:classify_argument
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-11 14:10 --- Works for me with 3.4.0, 4.0.0, and 4.1.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work||3.4.0 4.0.0 4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24308
[Bug tree-optimization/24309] New: [4.1 Regression] ICE with -O3 -ftree-loop-linear
The example (attached below), when compiled by following gcc --- $ gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../../../gcc-CVS-20051011/gcc-CVS-20051011/configure --host=i686-pc-linux-gnu --prefix=/usr/local/opt/gcc-4.1 --exec-prefix=/usr/local/opt/gcc-4.1 --sysconfdir=/etc --libdir=/usr/local/opt/gcc-4.1/lib --libexecdir=/usr/local/opt/gcc-4.1/libexec --sharedstatedir=/var --localstatedir=/var --program-suffix=-4.1 --with-x-includes=/usr/X11R6/include --with-x-libraries=/usr/X11R6/lib --enable-shared --enable-static --with-gnu-as --with-gnu-ld --with-stabs --enable-threads=posix --enable-version-specific-runtime-libs --disable-coverage --disable-libgcj --disable-checking --enable-multilib --with-x --enable-cmath --enable-libstdcxx-debug --enable-fast-character --enable-hash-synchronization --with-system-zlib --with-libbanshee --with-demangler-in-ld --with-arch=athlon-xp --disable-libada --enable-languages=c,c++,f95,objc Thread model: posix gcc version 4.1.0 20051010 (experimental) --- with --- gcc -O3 -ftree-loop-linear -c quant_lsp.c -o quant_lsp.o --- results in this: --- quant_lsp.c: In function âlsp_quant_48kâ: quant_lsp.c:103: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. --- This fails on both i686-pc-linux-gnu and x86_64-pc-linux-gnu. It seems that the regression was introduced somewhere between CVS-20050723 (which works) and CVS-20050812 (which doesn't). -- Summary: [4.1 Regression] ICE with -O3 -ftree-loop-linear Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: drab at kepler dot fjfi dot cvut dot cz GCC target triplet: i?86-*-*, x86_64-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24309
[Bug target/24308] endless looping and memory allocation in i386.c:classify_argument
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-11 14:11 --- (In reply to comment #2) > Works for me with 3.4.0, 4.0.0, and 4.1.0. Except that was 32bit. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work|3.4.0 4.0.0 4.1.0 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24308
[Bug tree-optimization/24309] [4.1 Regression] ICE with -O3 -ftree-loop-linear
--- Comment #1 from drab at kepler dot fjfi dot cvut dot cz 2005-10-11 14:11 --- Created an attachment (id=9965) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9965&action=view) Triggers the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24309
[Bug tree-optimization/24309] [4.1 Regression] ICE with -O3 -ftree-loop-linear
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24309
[Bug rtl-optimization/23585] [4.0 regression] mem_fun* code fine with -O1, bus error with -O2
--- Comment #11 from mark at codesourcery dot com 2005-10-11 14:22 --- Subject: Re: [4.0 regression] mem_fun* code fine with -O1, bus error with -O2 ebotcazou at gcc dot gnu dot org wrote: > --- Comment #10 from ebotcazou at gcc dot gnu dot org 2005-10-11 13:59 > --- > >>may_trap_p is the correct thing as it should detect this instruction as >>trapping: >> >> /* Memory ref can trap unless it's a static var or a stack slot. */ >> case MEM: >> if (MEM_NOTRAP_P (x)) >> return 0; >> return rtx_addr_can_trap_p (XEXP (x, 0)); > > > No, it's the other way around. The MEM is a stack slot so may_trap_p returns > 0. This certainly is a bug in the back-end, not a bug in the default location of the v-bit. You shouldn't need to break the C++ ABI on SPARC to fix this bug. However, I'm not sure why you're seeing a 4-byte load from an unaligned address. One possibility is that in rtx_addr_can_trap_p: case PLUS: /* An address is assumed not to trap if it is an address that can't trap plus a constant integer or it is the pic register plus a constant. */ return ! ((! rtx_addr_can_trap_p (XEXP (x, 0)) && GET_CODE (XEXP (x, 1)) == CONST_INT) || (XEXP (x, 0) == pic_offset_table_rtx && CONSTANT_P (XEXP (x, 1; we should consider the address as unsafe if the CONST_INT is not a multiple of the size of the mode, on a STRICT_ALIGNMENT target. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23585
[Bug other/4] Test PR
--- Comment #4 from dberlin at gcc dot gnu dot org 2005-10-11 14:25 --- Subject: Bug 4 Author: dberlin Date: Tue Oct 11 14:15:11 2005 New Revision: 83801 URL: http://gcc.gnu.org/viewcvs?root=gccrepo&view=rev&rev=83801 Log: Fixing bug 4 Modified: branches/improved-aliasing-branch/gcc/version.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
[Bug target/24119] gcc-4.x fails to build on AIX 5.2.0.0-ML04
--- Comment #17 from h dot m dot brand at xs4all dot nl 2005-10-11 14:37 --- Subject: Re: gcc-4.x fails to build on AIX 5.2.0.0-ML04 On 6 Oct 2005 17:24:10 -, "dje at gcc dot gnu dot org" <[EMAIL PROTECTED]> wrote: Now that all seems to be in more or less working order, and gcc-4.1-20051008 is built from 4.0.2, (no problems with bigtoc), I've got a new question for AIX 4.3.3: build/genattrtab ../../src/gcc/config/rs6000/rs6000.md > tmp-attrtab.c out of memory allocating 80016 bytes after a total of 4161651484 bytes I'm the only user, and no more processes can be killed. i2 AIX 4.3.3.0/ML11 IBM,7043-150 PowerPC_604e 640 Mb > --- Comment #16 from dje at gcc dot gnu dot org 2005-10-06 17:24 > --- I do not know where the extra -B is entering, but GCC configure and > build process does not insert it. You might look for it in other > environment variables, if it still exists after you have deleted the build > directory. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24119
[Bug rtl-optimization/23585] [4.0 regression] mem_fun* code fine with -O1, bus error with -O2
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2005-10-11 14:41 --- > This certainly is a bug in the back-end, not a bug in the default > location of the v-bit. You shouldn't need to break the C++ ABI on SPARC > to fix this bug. Right, I was confused, I thought __pfn was dereferenced itself. > However, I'm not sure why you're seeing a 4-byte load from an unaligned > address. Because p is a pointer to Class and Class has alignment 1. I guess the first branch of the expression works when Class contains a pointer to the vtable, hence has alignment 4. > One possibility is that in rtx_addr_can_trap_p: > > case PLUS: > /* An address is assumed not to trap if it is an address that > can't > trap plus a constant integer or it is the pic register plus a > > constant. */ > return ! ((! rtx_addr_can_trap_p (XEXP (x, 0)) > && GET_CODE (XEXP (x, 1)) == CONST_INT) > || (XEXP (x, 0) == pic_offset_table_rtx > && CONSTANT_P (XEXP (x, 1; > > we should consider the address as unsafe if the CONST_INT is not a > multiple of the size of the mode, on a STRICT_ALIGNMENT target. Yes, but that's not enough, as MEM_NO_TRAP_P might come into play. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23585
[Bug target/24308] endless looping and memory allocation in i386.c:classify_argument
--- Comment #4 from rguenth at gcc dot gnu dot org 2005-10-11 14:41 --- It looks like only checking-enabled 3.4.5 allocates memory until it get's killed by the kernel. A checking-disabled 3.4.5 build just endlessly loops (in the same place). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24308
[Bug target/24308] endless looping and memory allocation in i386.c:classify_argument
--- Comment #5 from rguenth at gcc dot gnu dot org 2005-10-11 14:45 --- Also fails with 3.3.3 (SuSE Linux) - which is really hammer-branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24308
[Bug rtl-optimization/23585] [4.0 regression] mem_fun* code fine with -O1, bus error with -O2
--- Comment #13 from mark at codesourcery dot com 2005-10-11 14:47 --- Subject: Re: [4.0 regression] mem_fun* code fine with -O1, bus error with -O2 ebotcazou at gcc dot gnu dot org wrote: > --- Comment #12 from ebotcazou at gcc dot gnu dot org 2005-10-11 14:41 > --- > >>This certainly is a bug in the back-end, not a bug in the default >>location of the v-bit. You shouldn't need to break the C++ ABI on SPARC >>to fix this bug. > > > Right, I was confused, I thought __pfn was dereferenced itself. > > >>However, I'm not sure why you're seeing a 4-byte load from an unaligned >>address. > > > Because p is a pointer to Class and Class has alignment 1. I guess the first > branch of the expression works when Class contains a pointer to the vtable, > hence has alignment 4. Ah. I think that would best be fixed in the front-end, then. If the class doesn't have a virtual pointer, then there's no need to generate the conditional expression; avoiding that will not only fix this bug, but make the code generated by the front-end easier for the middle end to process. Please re-assign to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23585
[Bug tree-optimization/24309] [4.1 Regression] ICE with -O3 -ftree-loop-linear
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-11 14:48 ---
Confirmed, reduced testcase:
float weight[10];
void lsp_weight_quant(float *x, char *cdbk)
{
int i,j;
float dist;
int best_id=0;
for (i=0;i<16;i++)
{
for (j=0;j<10;j++)
dist=dist+weight[j];
if (dist<0)
best_id=i;
}
x[j] = cdbk[best_id*10+j];
}
--
but this is just a latent bug as the above also ICEs in 4.0.0.
Related to PR 23820.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||dberlin at gcc dot gnu dot
||org
BugsThisDependsOn||23820
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2005-10-11 14:48:46
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24309
[Bug target/24119] gcc-4.x fails to build on AIX 5.2.0.0-ML04
--- Comment #18 from h dot m dot brand at xs4all dot nl 2005-10-11 14:52 --- Subject: Re: gcc-4.x fails to build on AIX 5.2.0.0-ML04 On 11 Oct 2005 14:37:31 -, "h dot m dot brand at xs4all dot nl" <[EMAIL PROTECTED]> wrote: Ignore the AIX 4.3 question: I've raised the limits to unlimited for my person (how nice if you can be root) and then all worked I think you can now close this bug. > --- Comment #17 from h dot m dot brand at xs4all dot nl 2005-10-11 > 14:37 --- Subject: Re: gcc-4.x fails to build on AIX 5.2.0.0-ML04 > > On 6 Oct 2005 17:24:10 -, "dje at gcc dot gnu dot org" > <[EMAIL PROTECTED]> wrote: > > Now that all seems to be in more or less working order, and gcc-4.1-20051008 > is built from 4.0.2, (no problems with bigtoc), I've got a new question for > AIX 4.3.3: > > build/genattrtab ../../src/gcc/config/rs6000/rs6000.md > tmp-attrtab.c > > out of memory allocating 80016 bytes after a total of 4161651484 bytes > > I'm the only user, and no more processes can be killed. > > i2 AIX 4.3.3.0/ML11 IBM,7043-150 PowerPC_604e 640 Mb > > > --- Comment #16 from dje at gcc dot gnu dot org 2005-10-06 17:24 > > --- I do not know where the extra -B is entering, but GCC configure > > and build process does not insert it. You might look for it in other > > environment variables, if it still exists after you have deleted the build > > directory. > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24119
[Bug target/24308] endless looping and memory allocation in i386.c:classify_argument
--- Comment #6 from rguenth at gcc dot gnu dot org 2005-10-11 14:55 --- Oh, and make it hang-on-valid by adding a closing brace at EOF. Also fails with unpatched FSF 3.3.6, so not a regression. So WONTFIX probably, unless latent somehow. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords|ice-on-invalid-code |ice-on-valid-code Known to fail||3.3.6 3.4.5 Known to work||4.0.3 4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24308
[Bug tree-optimization/24309] [4.1 Regression] ICE with -O3 -ftree-loop-linear
--- Comment #3 from drab at kepler dot fjfi dot cvut dot cz 2005-10-11 14:56 --- (In reply to comment #2) > -- > but this is just a latent bug as the above also ICEs in 4.0.0. > Related to PR 23820. No! Both the reduced and my original testcase work for me on 4.0.x. At least on this one: gcc version 4.0.2 20050827 (prerelease) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24309
[Bug tree-optimization/24309] [4.1 Regression] ICE with -O3 -ftree-loop-linear
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-11 14:58 --- (In reply to comment #3) > No! Both the reduced and my original testcase work for me on 4.0.x. > At least on this one: That is with checking disabled so ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24309
[Bug tree-optimization/23946] [4.1 regression] ICE: verify_ssa failed ("definition ... follows the use")
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-10-11 15:03 --- 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=23946
[Bug tree-optimization/23946] [4.1 regression] ICE: verify_ssa failed ("definition ... follows the use")
--- Comment #10 from cvs-commit at gcc dot gnu dot org 2005-10-11 15:11 --- Subject: Bug 23946 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-10-11 15:11:02 Modified files: gcc: ChangeLog tree-ssa-ccp.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/compile: pr23946.c Log message: 2005-10-11 Andrew Pinski <[EMAIL PROTECTED]> PR tree-opt/23946 * gcc.c-torture/compile/pr23946.c: New test. 2005-10-11 Andrew Pinski <[EMAIL PROTECTED]> PR tree-opt/23946 * tree-ssa-ccp.c (execute_fold_all_builtins): Call mark_new_vars_to_rename instead of update_stmt. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.10136&r2=2.10137 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-ccp.c.diff?cvsroot=gcc&r1=2.88&r2=2.89 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6163&r2=1.6164 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/pr23946.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23946
[Bug tree-optimization/24309] [4.1 Regression] ICE with -O3 -ftree-loop-linear
--- Comment #5 from drab at kepler dot fjfi dot cvut dot cz 2005-10-11 15:24 --- (In reply to comment #4) > That is with checking disabled so ... Yes. That's right. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24309
[Bug tree-optimization/24309] [4.1 Regression] ICE with -O3 -ftree-loop-linear
--- Comment #6 from dberlin at gcc dot gnu dot org 2005-10-11 15:27 --- Subject: Re: [4.1 Regression] ICE with -O3 -ftree-loop-linear On Tue, 2005-10-11 at 15:24 +, drab at kepler dot fjfi dot cvut dot cz wrote: > > --- Comment #5 from drab at kepler dot fjfi dot cvut dot cz 2005-10-11 > 15:24 --- > (In reply to comment #4) > > > That is with checking disabled so ... > Yes. That's right. With checking disabled, it won't ICE > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24309
[Bug c++/24310] New: ipa-inline dump reads from freed memory resulting in a corrupt dump file
Due to a design-mistake in the cxx_printable_name print ring buffer, we print out freed strings at ipa-inline.c:cgraph_decide_inlining_of_small_functions fprintf (dump_file, "\nConsidering %s with %i insns to be inlined into %s\n" " Estimated growth after inlined into all callees is %+i insns.\n" " Estimated badness is %i.\n", cgraph_node_name (edge->callee), edge->callee->global.insns, cgraph_node_name (edge->caller), cgraph_estimate_growth (edge->callee), cgraph_edge_badness (edge)); where cgraph_node_name calls back to the langhook which is implemented by cxx_printable_name. The print ring buffer should by design guarantee PRINT_RING_SIZE live strings. Remember we could be ICEing on this. -- Summary: ipa-inline dump reads from freed memory resulting in a corrupt dump file Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, patch Severity: normal Priority: P2 Component: c++ 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=24310
[Bug c++/24310] ipa-inline dump reads from freed memory resulting in a corrupt dump file
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-10-11 15:38 --- Patch was posted. Problem is latent since at least old-gcc. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||10/msg00220.html Known to fail||4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24310
[Bug c++/24310] ipa-inline dump reads from freed memory resulting in a corrupt dump file
--- Comment #2 from rguenth at gcc dot gnu dot org 2005-10-11 15:40 --- Created an attachment (id=9966) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9966&action=view) testcase (unincluded) Testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24310
[Bug target/24230] [4.1 Regression] [altivec] ICE in extract_insn, at recog.c:2084
--- Comment #11 from bonzini at gcc dot gnu dot org 2005-10-11 15:41 --- Created an attachment (id=9967) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9967&action=view) reduced testcase reduced testcase, but with uninitialized variables. top of tree: 2005-09-29 Paolo Bonzini <[EMAIL PROTECTED]> Revert this patch: 2005-09-15 Paolo Bonzini <[EMAIL PROTECTED]> * optabs.c (expand_binop): Use swap_commutative_operands_with_target to order operands. (swap_commutative_operands_with_target): New. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24230
[Bug c++/24310] ipa-inline dump reads from freed memory resulting in a corrupt dump file
--- Comment #3 from rguenth at gcc dot gnu dot org 2005-10-11 15:42 --- The patch causes diffs like the following in the ipa-inline-dump: -Considering int GuardLayers::lower(int) const [with int Dim = 2] with 0 in sns to be inlined into int UniformGridPartition::partition(const D&, std::v ector, Interval >*, std::allocator, I nterval >*> >&, const ContextMapper&) const [with D = Interval<2>, int Dim = 2] +Considering int GuardLayers::lower(int) const [with int Dim = 2] with 0 in sns to be inlined into [EMAIL PROTECTED]@ormGridPartition::partition(const D& , std::vector, Interval >*, std::allocator, Interval >*> >&, const ContextMapper&) const [with D = Interval <2>, int Dim = 2] there are 20 occourances of corruption. Oh, btw. compile with -O2 -fdump-ipa-inline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24310
[Bug target/18583] [3.4 Regression] error on valid code: const __attribute__((altivec(vector__))) doesn't work in arrays
--- Comment #6 from janis at gcc dot gnu dot org 2005-10-11 16:22 --- I forgot to add the PR information to the ChangeLog entry at first, but this is fixed in 3.4.5 by http://gcc.gnu.org/ml/gcc-cvs/2005-10/msg00274.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18583
[Bug fortran/24311] New: Regression: ICE when MERGE is used with character args in a PRINT/WRITE statement
>From the Meissner example Window (Ising model), this line
print '(" ", I6, 64 A1)', L**3, Merge ("+", "-", Ising(: 4, : 4, : 4) == 1)
causes
meissner10.f90: In function MAIN__:
meissner10.f90:18: internal compiler error: in gfc_conv_expr_descriptor, at
fortran/trans-array.c:3815
The ICE is due to this patch:
http://gcc.gnu.org/ml/gcc-cvs/2005-09/msg00961.html
I did not catch it because I had passed this patch by, working on trans-io.c,
as it does. *sigh*
Specifically, the call from trans-io.c(gfc_trans_transfer):
...snip
else
{
/* Pass the array descriptor to the library. */
gfc_conv_expr_descriptor (&se, expr, ss);
tmp = gfc_build_addr_expr (NULL, se.expr);
transfer_array_desc (&se, &expr->ts, tmp);
}
...snip
is the cause of the problem.
A potential patch (well it works!) is
*** gcc/gcc/fortran/trans-io.c.orig Tue Oct 11 14:18:51 2005
--- gcc/gcc/fortran/trans-io.c Tue Oct 11 14:18:31 2005
*** gfc_trans_transfer (gfc_code * code)
*** 1637,1643
gfc_conv_expr_reference (&se, expr);
transfer_expr (&se, &expr->ts, se.expr);
}
! else if (expr->ts.type == BT_DERIVED)
{
/* Initialize the scalarizer. */
gfc_init_loopinfo (&loop);
--- 1637,1643
gfc_conv_expr_reference (&se, expr);
transfer_expr (&se, &expr->ts, se.expr);
}
! else if (expr->ts.type == BT_DERIVED || (expr->ts.type == BT_CHARACTER &&
expr->ts.cl == NULL))
{
/* Initialize the scalarizer. */
gfc_init_loopinfo (&loop);
I am looking for a more elegant solution or, at least, a cleaner detection of
the error.
--
Summary: Regression: ICE when MERGE is used with character args
in a PRINT/WRITE statement
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pault at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24311
[Bug rtl-optimization/23585] [4.0 regression] mem_fun* code fine with -O1, bus error with -O2
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2005-10-11 16:24 --- > Ah. I think that would best be fixed in the front-end, then. If the > class doesn't have a virtual pointer, then there's no need to generate > the conditional expression; avoiding that will not only fix this bug, > but make the code generated by the front-end easier for the middle end > to process. Clever. :-) > Please re-assign to me. Thanks. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC|mark at codesourcery dot com|ebotcazou at gcc dot gnu dot ||org AssignedTo|ebotcazou at gcc dot gnu dot|mmitchel at gcc dot gnu dot |org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23585
[Bug c++/24052] [3.4/4.0/4.1 Regression] &#`label_decl' not supported by dump_expr#
-- bonzini at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-09-25 14:51:31 |2005-10-11 16:28:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24052
[Bug bootstrap/24297] [4.1 Regression] libtool: link: unable to infer tagged configuration
--- Comment #6 from bonzini at gcc dot gnu dot org 2005-10-11 16:30 --- Can somebody with a failing system remove all @'s from the toplevel Makefile and send me the log that results? That is, sed -i 's/^\t@/\t' Makefile make Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24297
[Bug testsuite/24281] [4.1 Regression] WARNING: Could not execute gcc.dg/compat/struct-layout-1 generator
--- Comment #3 from janis at gcc dot gnu dot org 2005-10-11 16:32 --- This is from Steve Ellcey's change on 2005-10-07, which I approved. I'll take a look. -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||janis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24281
[Bug c++/21369] [4.0/4.1 Regression] Template function definition rejected if function return type begins with 'struct'
--- Comment #5 from cvs-commit at gcc dot gnu dot org 2005-10-11 16:38 --- Subject: Bug 21369 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED]2005-10-11 16:38:00 Modified files: gcc/cp : parser.c ChangeLog gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/parse: ret-type3.C Log message: PR c++/21369 * parser.c (cp_parser_elaborated_type_specifier): Don't treat class types as templates if the type is not appearing as part of a type definition or declaration. PR c++/21369 * g++.dg/parse/ret-type3.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.319.2.21&r2=1.319.2.22 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.4648.2.123&r2=1.4648.2.124 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/ret-type3.C.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.442&r2=1.5084.2.443 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21369
[Bug c++/21369] [4.0/4.1 Regression] Template function definition rejected if function return type begins with 'struct'
--- Comment #6 from cvs-commit at gcc dot gnu dot org 2005-10-11 16:38 --- Subject: Bug 21369 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED]2005-10-11 16:38:52 Modified files: gcc/cp : parser.c ChangeLog gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/parse: ret-type3.C Log message: PR c++/21369 * parser.c (cp_parser_elaborated_type_specifier): Don't treat class types as templates if the type is not appearing as part of a type definition or declaration. PR c++/21369 * g++.dg/parse/ret-type3.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcc&r1=1.362&r2=1.363 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4918&r2=1.4919 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/ret-type3.C.diff?cvsroot=gcc&r1=1.1&r2=1.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6164&r2=1.6165 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21369
[Bug c++/21369] [4.0/4.1 Regression] Template function definition rejected if function return type begins with 'struct'
--- Comment #7 from mmitchel at gcc dot gnu dot org 2005-10-11 16:41 --- Fixed in 4.0.3. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21369
[Bug target/18583] [3.4 Regression] error on valid code: const __attribute__((altivec(vector__))) doesn't work in arrays
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-10-11 16:45 --- 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=18583
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not "inline" the static const double
--- Comment #18 from mmitchel at gcc dot gnu dot org 2005-10-11 16:49 --- The optimization question in Comment #11 was answered incorrectly. The C++ standard in fact requires that Y be initialized before the constructor is run; see [basic.start.init]. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug testsuite/24281] [4.1 Regression] WARNING: Could not execute gcc.dg/compat/struct-layout-1 generator
-- janis at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janis at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-10-09 01:55:55 |2005-10-11 16:56:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24281
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not "inline" the static const double
--- Comment #19 from sabre at nondot dot org 2005-10-11 16:58 --- To clarify: you are saying that the response in comment #12 is wrong? -Chris -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not "inline" the static const double
--- Comment #20 from mark at codesourcery dot com 2005-10-11 17:00 --- Subject: Re: [4.0/4.1 Regression] C++ front-end does not "inline" the static const double sabre at nondot dot org wrote: > --- Comment #19 from sabre at nondot dot org 2005-10-11 16:58 --- > To clarify: you are saying that the response in comment #12 is wrong? I don't understand Comment #12. However, Comment #13 says that "You are correct Chris, this was an invalid optimization"; that's incorrect, it is in fact a required optimization. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not "inline" the static const double
--- Comment #21 from sabre at nondot dot org 2005-10-11 17:03 --- "required optimization" doesn't make sense to me. To put it more clearly, do you agree that this: "In particular, I think the C++ standard specifies that memory is zero initialized and then ctors (within a translation unit) are run in order." statement is true, and that the code in comment 11 is valid? If so, an attempt to implement this optimization just needs to be careful not the break this sort of case. -Chris -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug testsuite/24281] [4.1 Regression] WARNING: Could not execute gcc.dg/compat/struct-layout-1 generator
--- Comment #4 from cvs-commit at gcc dot gnu dot org 2005-10-11 17:04 --- Subject: Bug 24281 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-10-11 17:04:45 Modified files: gcc/testsuite : ChangeLog gcc/testsuite/gcc.dg/compat: struct-layout-1_generate.c Log message: PR testsuite/24281 * gcc.dg/compat/struct-layout-1_generator.c (generate_fields): Check for null pointer. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6165&r2=1.6166 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/compat/struct-layout-1_generate.c.diff?cvsroot=gcc&r1=1.8&r2=1.9 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24281
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not "inline" the static const double
--- Comment #22 from mark at codesourcery dot com 2005-10-11 17:05 --- Subject: Re: [4.0/4.1 Regression] C++ front-end does not "inline" the static const double sabre at nondot dot org wrote: > --- Comment #21 from sabre at nondot dot org 2005-10-11 17:03 --- > "required optimization" doesn't make sense to me. To put it more clearly, do > you agree that this: > > "In particular, I think the C++ standard specifies that memory is zero > initialized and then ctors (within a translation unit) are run in order." > > statement is true, and that the code in comment 11 is valid? Initializers are not constructors. You'll have to go read the section of the standard I cited. The code in comment #11 is valid -- but it must print 3.0, which may not be what you expected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not "inline" the static const double
--- Comment #23 from sabre at nondot dot org 2005-10-11 17:10 --- Ah, very interesting. Thanks for the clarification. Should I file another PR about cases where this is mishandled? -Chris -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/24312] New: C++ front-end doesn't correctly handle distinction between global initializers and ctors
The following testcase is miscompiled:
#include
double foo() { return 1.0; }
static struct S { S(); } s;
static const double Y = foo()+2.0;
S::S() {
printf("%f\n", Y);
}
int main() {
printf("%f\n", Y);
}
Both printfs should print 3 based on Mark's insight in Comment #22 of bug
21089.
-Chris
--
Summary: C++ front-end doesn't correctly handle distinction
between global initializers and ctors
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sabre at nondot dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24312
[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not "inline" the static const double
--- Comment #24 from sabre at nondot dot org 2005-10-11 17:15 --- At pinskia's request, I filed Bug 24312 to show the miscompilation due to mishandling this. I thought it would be better to keep this PR focused on the missed-optimization aspect. -Chris -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089
[Bug c++/24312] C++ front-end doesn't correctly handle distinction between global initializers and ctors
--- Comment #1 from sabre at nondot dot org 2005-10-11 17:15 --- Note that this could be handled in a straight-forward way with init priorities. -- sabre at nondot dot org changed: What|Removed |Added Summary|C++ front-end doesn't |C++ front-end doesn't |correctly handle distinction|correctly handle distinction |between global initializers |between global initializers |and ctors |and ctors http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24312
[Bug rtl-optimization/23585] [4.0 regression] mem_fun* code fine with -O1, bus error with -O2
--- Comment #15 from giovannibajo at libero dot it 2005-10-11 17:16 --- Probably. But what if the problem with dereferencing p was that it is NULL, instead of a misalignment? Would that case be caught in reorg by something else? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23585
[Bug c++/24312] C++ front-end doesn't correctly handle distinction between global initializers and ctors
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-11 17:18 --- Confirmed, not a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Known to fail||2.95.3 3.0.4 3.2.2 3.2.3 ||3.3.1 4.0.0 3.4.0 4.1.0 Last reconfirmed|-00-00 00:00:00 |2005-10-11 17:18:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24312
[Bug libfortran/24313] New: complex sqrt function does not return principal value
This program demonstrates a bug in the complex sqrt function in gfortran. When complex number x = (0.0,-1.0), the result comes back as the negative of the expected result. Of course, the negative of the expected result is still a square root of the original number, but the f95 standard says that the principal square root should be returned, i.e. the real part of the result should be positive. complex x, y x = cmplx(0.0,-1.0) y = sqrt(x) write (*,*) x, y x = cmplx(0.0+1.0e-38,-1.0) y = sqrt(x) write (*,*) x, y x = cmplx(0.0-1.0e-38,-1.0) y = sqrt(x) write (*,*) x, y end The results I get are % gfortran -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/var/tmp/gfortran-20051007/irun --enable-languages=c,f95 Thread model: posix gcc version 4.1.0 20051007 (experimental) % gfortran sqrt.f % ./a.out ( 0.00, -1.00) (-0.7071068, 0.7071068) ( 9.994E-39, -1.00) ( 0.7071068,-0.7071068) (-9.994E-39, -1.00) ( 0.7071068,-0.7071068) Using a tiny number in place of the zero real part shows the correct results. This also affects the double complex version of sqrt. -- Summary: complex sqrt function does not return principal value Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mick at nag dot co dot uk GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24313
[Bug rtl-optimization/23585] [4.0 regression] mem_fun* code fine with -O1, bus error with -O2
--- Comment #16 from mark at codesourcery dot com 2005-10-11 17:31 --- Subject: Re: [4.0 regression] mem_fun* code fine with -O1, bus error with -O2 giovannibajo at libero dot it wrote: > --- Comment #15 from giovannibajo at libero dot it 2005-10-11 17:16 > --- > Probably. But what if the problem with dereferencing p was that it is NULL, > instead of a misalignment? Would that case be caught in reorg by something > else? Well, then the code would have undefined behavior, and the bus error would be OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23585
[Bug libfortran/24313] complex sqrt function does not return principal value
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-11 17:31 --- Hmm, I think this is a bug in glibc's csqrt. as I get the following on powerpc-darwin: ( 0.00, -1.00) ( 0.7071068,-0.7071068) ( 9.994E-39, -1.00) ( 0.7071068,-0.7071068) (-9.994E-39, -1.00) ( 0.7071068,-0.7071068) -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|x86_64-unknown-linux-gnu|x86_64-*-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24313
[Bug c++/22153] [3.4/4.0/4.1 regression] ICE on invalid template specialization
--- Comment #2 from jconner at apple dot com 2005-10-11 17:31 --- Patch submitted here: http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01274.html Awaiting review... -- jconner at apple dot com changed: What|Removed |Added CC||jconner at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22153
[Bug libfortran/24313] complex sqrt function does not return principal value
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-11 17:33 --- This is a bug in glibc's csqrt as gfortran just calls it. Please report it to them. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24313
[Bug testsuite/24281] [4.1 Regression] WARNING: Could not execute gcc.dg/compat/struct-layout-1 generator
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-10-11 17:36 --- 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=24281
[Bug java/24251] Segmentation fault using org.w3c.dom.
-- 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|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-10-11 17:58:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24251
[Bug fortran/24245] -fdump-parse-tree gives ICE for CONTAINED functions
--- Comment #3 from erik dot edelmann at iki dot fi 2005-10-11 18:11 --- Testing a patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24245
[Bug middle-end/24263] [4.1 Regression] gcc.dg/torture/builtin-convert-1.c fails
--- Comment #15 from cvs-commit at gcc dot gnu dot org 2005-10-11 18:15 --- Subject: Bug 24263 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-10-11 18:14:57 Modified files: gcc: ChangeLog convert.c Log message: PR middle-end/24263 * convert.c (convert_to_real): Revert 2005-10-05 patch. Only apply the optimization for rounding builtins if the inner cast is also an extension. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.10137&r2=2.10138 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/convert.c.diff?cvsroot=gcc&r1=1.70&r2=1.71 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24263
[Bug middle-end/24263] [4.1 Regression] gcc.dg/torture/builtin-convert-1.c fails
--- Comment #16 from ebotcazou at gcc dot gnu dot org 2005-10-11 18:16 --- See http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00578.html -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24263
[Bug c++/24314] New: Extra "template<>" in partial specialization is compiled successfuly.
This is the offending code, which gets compiled successfully.
--
// The base template.
template
struct A
{
int select() { return 0; }
};
//Extra "template<>"
template <>
template <>
template <>
template <>
template <>
template <>
template <>
template <>
template <>
template <>
template <>
template
struct A
{
int select() { return 1; }
};
int main()
{
return A().select();
}
--
Compiler and Environment Details:
=
Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/specs
Configured with: ./configure
Thread model: posix
gcc version 3.3.2
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/cc1plus -E -D__GNUG__=3 -quiet
-v -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=2 -D_GNU_SOURCE A.cpp
A.ii
ignoring nonexistent directory "NONE/include"
ignoring nonexistent directory "/usr/local/i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include/c++/3.3.2
/usr/local/include/c++/3.3.2/i686-pc-linux-gnu
/usr/local/include/c++/3.3.2/backward
/usr/local/include
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/include
/usr/include
End of search list.
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/cc1plus -fpreprocessed A.ii
-quiet -dumpbase A.cpp -auxbase A -version -o A.s
GNU C++ version 3.3.2 (i686-pc-linux-gnu)
compiled by GNU C version 3.2.3 20030502 (Red Hat Linux 3.2.3-20).
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128606
as -V -Qy -o A.o A.s
GNU assembler version 2.14.90.0.4 (i386-redhat-linux) using BFD version
2.14.90.0.4 20030523
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/collect2 --eh-frame-hdr -m
elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/crtbegin.o
-L/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.2
-L/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/../../.. A.o -lstdc++ -lm
-lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/crtend.o /usr/lib/crtn.o
--
Summary: Extra "template<>" in partial specialization is compiled
successfuly.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P4
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: shriram_vishwanathan at persistent dot co dot in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24314
[Bug c++/24314] Extra "template<>" in partial specialization is compiled successfuly.
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-11 18:25 --- Fixed in 3.4.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords||accepts-invalid Known to fail||2.95.3 3.0.4 3.3.3 3.2.3 Known to work||3.4.0 4.0.0 4.1.0 Resolution||FIXED Target Milestone|4.0.0 |3.4.0 Version|unknown |3.3.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24314
[Bug fortran/23815] Add -byteswapio flag
--- Comment #4 from tkoenig at gcc dot gnu dot org 2005-10-11 18:40 --- I'm trying to work on this. I would prefer a syntax "open(...,convert="little_endian") or something like that. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23815
