[Bug target/17608] [3.3.4/3.4/4.0 regression] -profile should prevent use of libgcc_s
--- Additional Comments From amodra at bigpond dot net dot au 2004-12-20 08:35 --- I suspect that -profile ought to always imply -static. For instance, you can get the same crash by linking with -profile and -lm, because libm.so needs libc.so. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17608
[Bug tree-optimization/19080] [4.0 regression] ICE while compiling linux kernel
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-20
09:10 ---
After alias2, we have this statement:
# NMT.24D.1619 = V_MAY_DEF NMT.24D.1619;
# NMT.25D.1620 = V_MAY_DEF NMT.25D.1620;
# NMT.26D.1621 = V_MAY_DEF NMT.26D.1621;
# NMT.27D.1622 = V_MAY_DEF NMT.27D.1622;
foo_int_int (D.1505_6, D.1506_5);
but in this loop:
/* Note that virtual definitions are irrelevant for computing KILLS
because a V_MAY_DEF does not constitute a killing definition of the
variable. However, the operand of a virtual definitions is a use
of the variable, so it may cause the variable to be considered
live-on-entry. */
FOR_EACH_SSA_MAYDEF_OPERAND (def_p, use_p, stmt, iter)
{
if (prepare_use_operand_for_rename (use_p, uid))
{
/* If we do not already have an SSA_NAME for our destination,
then set the destination to the source. */
if (TREE_CODE (DEF_FROM_PTR (def_p)) != SSA_NAME)
SET_DEF (def_p, USE_FROM_PTR (use_p));
set_livein_block (USE_FROM_PTR (use_p), bb);
set_def_block (DEF_FROM_PTR (def_p), bb, false, false);
REWRITE_THIS_STMT (stmt) = 1;
}
}
we never return true for any of the NMTs in prepare_use_operand_for_rename,
so we never mark this statement for renaming.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19080
[Bug tree-optimization/19080] [4.0 regression] ICE while compiling linux kernel
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-20
09:44 ---
At the start of the alias pass:
(gdb)
1593 invalidate_name_tags (vars_to_rename);
(gdb) p debug_bitmap (vars_to_rename)
first = 0xd73d10 current = 0xd73d10 indx = 0
0xd73d10 next = (nil) prev = (nil) indx = 0
bits = { 1 3 7 9 50 }
Then in prepare_use_operand_for_rename we have for the first V_MAY_DEF:
409 FOR_EACH_SSA_MAYDEF_OPERAND (def_p, use_p, stmt, iter)
(gdb)
411 if (prepare_use_operand_for_rename (use_p, uid))
(gdb) step
prepare_use_operand_for_rename (op_p={use = 0x2a95a358d0}, uid_p=0x7fbfffc608)
at tree-into-ssa.c:562
562 tree use = USE_FROM_PTR (op_p);
563 tree var = (TREE_CODE (use) != SSA_NAME) ? use : SSA_NAME_VAR (use);
564 *uid_p = var_ann (var)-uid;
(gdb) p debug_generic_expr (use)
NMT.24D.1619
(gdb) p debug_generic_expr (var)
NMT.24D.1619
$47 = void
(gdb) p *uid_p
$46 = 51
Then we have:
567 if (vars_to_rename !bitmap_bit_p (vars_to_rename, *uid_p))
So the bug seems to be in the alias pass, it just doesn't name the NMT
for renaming at all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19080
[Bug c/19087] New: Overflowed address in dwarf debug line information
The mapping between addresses and code locations is invalid in object files compiled for AVR targets that addresses code above 64K. This seems like a rollover bug because addresses immediately above 64K have values near 0. To reproduce this bug, generate a source file that uses more than 64K of program memory and try to parse the .debug_line section using libdwarf or by implementing the state machine described in section 6.2 of DWARF Debugging Information Format revision 2.0.0 This is probably a side-effect of the AVR usually only addressing 64K of program memory. http://reality.sgi.com/davea/ http://dwarf.freestandards.org/modules.php?name=Contentpa=showpagepid=6 -- Summary: Overflowed address in dwarf debug line information Product: gcc Version: 3.4.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tsandnes at atmel dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: mingw32 GCC host triplet: 386 GCC target triplet: AVR http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087
[Bug middle-end/18999] gimplify_init_ctor_eval does not support RANGE_EXPRs
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-20 11:27 --- Subject: Bug 18999 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-20 11:26:47 Modified files: gcc: ChangeLog expr.c gimplify.c tree.h gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: 20041219-1.c Log message: gcc/ PR middle-end/18191 PR middle-end/18965 PR middle-end/18999 * expr.c (categorize_ctor_elements_1): Count the total number of elements in the constructor. (categorize_ctor_elements): Return it in a new argument. * tree.h (categorize_ctor_elements): Adjust prototype. * gimplify.c (gimplify_init_ctor_eval_range): New. (gimplify_init_ctor_eval): Gimplify RANGE_EXPR. (gimplify_init_constructor): Block clear the object if the constructor has fewer elements than the object type. Only try to add assignments to individual elements when we have to. testsuite/ * gcc.dg/20041219-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.6897r2=2.6898 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/expr.c.diff?cvsroot=gccr1=1.761r2=1.762 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gimplify.c.diff?cvsroot=gccr1=2.93r2=2.94 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree.h.diff?cvsroot=gccr1=1.667r2=1.668 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4783r2=1.4784 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20041219-1.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18999
[Bug middle-end/18965] [4.0 regression] ICE in gimplify_init_ctor_eval
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-20 11:27 --- Subject: Bug 18965 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-20 11:26:47 Modified files: gcc: ChangeLog expr.c gimplify.c tree.h gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: 20041219-1.c Log message: gcc/ PR middle-end/18191 PR middle-end/18965 PR middle-end/18999 * expr.c (categorize_ctor_elements_1): Count the total number of elements in the constructor. (categorize_ctor_elements): Return it in a new argument. * tree.h (categorize_ctor_elements): Adjust prototype. * gimplify.c (gimplify_init_ctor_eval_range): New. (gimplify_init_ctor_eval): Gimplify RANGE_EXPR. (gimplify_init_constructor): Block clear the object if the constructor has fewer elements than the object type. Only try to add assignments to individual elements when we have to. testsuite/ * gcc.dg/20041219-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.6897r2=2.6898 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/expr.c.diff?cvsroot=gccr1=1.761r2=1.762 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gimplify.c.diff?cvsroot=gccr1=2.93r2=2.94 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree.h.diff?cvsroot=gccr1=1.667r2=1.668 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4783r2=1.4784 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20041219-1.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18965
[Bug middle-end/18191] [4.0 Regression] Struct member is not getting default-initialized
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-20 11:27 --- Subject: Bug 18191 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-20 11:26:47 Modified files: gcc: ChangeLog expr.c gimplify.c tree.h gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: 20041219-1.c Log message: gcc/ PR middle-end/18191 PR middle-end/18965 PR middle-end/18999 * expr.c (categorize_ctor_elements_1): Count the total number of elements in the constructor. (categorize_ctor_elements): Return it in a new argument. * tree.h (categorize_ctor_elements): Adjust prototype. * gimplify.c (gimplify_init_ctor_eval_range): New. (gimplify_init_ctor_eval): Gimplify RANGE_EXPR. (gimplify_init_constructor): Block clear the object if the constructor has fewer elements than the object type. Only try to add assignments to individual elements when we have to. testsuite/ * gcc.dg/20041219-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.6897r2=2.6898 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/expr.c.diff?cvsroot=gccr1=1.761r2=1.762 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gimplify.c.diff?cvsroot=gccr1=2.93r2=2.94 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree.h.diff?cvsroot=gccr1=1.667r2=1.668 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4783r2=1.4784 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20041219-1.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18191
[Bug middle-end/18191] [4.0 Regression] Struct member is not getting default-initialized
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-20 11:28 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18191
[Bug middle-end/18999] gimplify_init_ctor_eval does not support RANGE_EXPRs
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-20 11:29 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18999
[Bug middle-end/18965] [4.0 regression] ICE in gimplify_init_ctor_eval
-- Bug 18965 depends on bug 18999, which changed state. Bug 18999 Summary: gimplify_init_ctor_eval does not support RANGE_EXPRs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18999 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18965
[Bug middle-end/18191] [4.0 Regression] Struct member is not getting default-initialized
-- Bug 18191 depends on bug 18999, which changed state. Bug 18999 Summary: gimplify_init_ctor_eval does not support RANGE_EXPRs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18999 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18191
[Bug middle-end/18965] [4.0 regression] ICE in gimplify_init_ctor_eval
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-20 11:29 --- Fixed for real this time. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18965
[Bug target/18987] [4.0 regression] [ia64] Extra '.restore sp' in tail call
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-20 11:46 --- Jim, David, can one of you look at this, and maybe revert the patch for PR13158 because it causes this regression? -- What|Removed |Added CC||davidm at hpl dot hp dot ||com, wilson at specifixinc ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18987
[Bug rtl-optimization/19001] [3.4 Regression] Loops with power of two step and variable bounds not unrolled
--- Additional Comments From giovannibajo at libero dot it 2004-12-20 11:46 --- Notice that no testcase was added to 4.0 either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19001
[Bug tree-optimization/17949] [4.0 Regression] Tree loop optimization generates unaligned access (STRICT_ALIGNMENT is set)
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-20 11:50 --- Does this affect *all* STRICT_ALIGNMENT targets? If so, we should definitely get this one fixed soonish: alpha/alpha.h:#define STRICT_ALIGNMENT 1 arc/arc.h:#define STRICT_ALIGNMENT 1 arm/arm.h:#define STRICT_ALIGNMENT 1 fr30/fr30.h:#define STRICT_ALIGNMENT 1 frv/frv.h:#define STRICT_ALIGNMENT 1 h8300/h8300.h:#define STRICT_ALIGNMENT 1 i860/i860.h:#define STRICT_ALIGNMENT 1 ia64/ia64.h:#define STRICT_ALIGNMENT 1 iq2000/iq2000.h:#define STRICT_ALIGNMENT 1 m32r/m32r.h:#define STRICT_ALIGNMENT 1 mcore/mcore.h:#define STRICT_ALIGNMENT 1 mips/mips.h:#define STRICT_ALIGNMENT 1 mmix/mmix.h:#define STRICT_ALIGNMENT 1 mn10300/mn10300.h:#define STRICT_ALIGNMENT 1 ns32k/ns32k.h:#define STRICT_ALIGNMENT 1 pa/pa.h:#define STRICT_ALIGNMENT 1 pdp11/pdp11.h:#define STRICT_ALIGNMENT 1 sh/sh.h:#define STRICT_ALIGNMENT 1 sparc/sparc.h:#define STRICT_ALIGNMENT 1 stormy16/stormy16.h:#define STRICT_ALIGNMENT 1 xtensa/xtensa.h:#define STRICT_ALIGNMENT 1 -- What|Removed |Added Priority|P2 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17949
[Bug other/19088] New: volatile attr. doesn't work with pointers / wrong code
# testcase
typedef volatile unsigned mutex;
void lockMutex(mutex* m)
{
while (*m != 1);
*m = 0;
}
void unlockMutex(mutex* m)
{
*m = 0;
}
*** GCC 3.4.2-20040916 ***
lockMutex:
0: e5903000ldr r3, [r0]
4: e3530001cmp r3, #1 ; 0x1
8: 1afebne 8 lockMutex+0x8== should jump to 0x00.
c: e2433001sub r3, r3, #1 ; 0x1
10: e5803000str r3, [r0]
14: e1a0f00emov pc, lr
0018 unlockMutex:
18: e3a03000mov r3, #0 ; 0x0
1c: e5803000str r3, [r0]
20: e1a0f00emov pc, lr
*** IAR C compiler ***
lockMutex:
0x0180 E5901000 LDR R1, [R0, #+0]
0x0184 E3510001 CMP R1, #0x1
0x0188 1AFC BNE lockMutex ; 0x180=== this works fine.
0x018C E3A01000 MOV R1, #0x0
0x0190 E5801000 STR R1, [R0, #+0]
0x0194 E12FFF1E BX LR
unlockMutex:
0x0198 E3A01000 MOV R1, #0x0
0x019C E5801000 STR R1, [R0, #+0]
0x01A0 E12FFF1E BX LR
# arm-elf-gcc -v
Reading specs from c:/winarm/bin/../lib/gcc/arm-elf/3.4.2/specs
Configured with: ../../gcc-3.4.2-20040916-1/configure --enable-languages=c,c++
--enable-interwork --enable-multilib --with-gcc --with-gnu-ld --with-gnu-as
--with-stabs --disable-shared --disable-threads --disable-win32-registry
--disable-nls --target=arm-elf --with-newlib
--with-headers=/c/winarms/newlib-1.12.0/newlib/libc/include --prefix=c:/WinARM/
-v : (reconfigured) ../../gcc-3.4.2-20040916-1/configure
--enable-languages=c,c++ --enable-interwork --enable-multilib --with-gcc
--with-gnu-ld --with-gnu-as --with-stabs --disable-shared --disable-threads
--disable-win32-registry --disable-nls --target=arm-elf --with-newlib
--prefix=c:/WinARM/ -v
Thread model: single
gcc version 3.4.2 (mingw-special)
--
Summary: volatile attr. doesn't work with pointers / wrong code
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at pld-linux dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: mingw
GCC target triplet: arm-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19088
[Bug target/18967] [4.0 regression] type conflict for __v2di in xmmintrin.h
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-20 12:08 --- Andreas, can you confirm that this is fixed by Richard's patch http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01483.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18967
[Bug other/19088] volatile attr. doesn't work with pointers / wrong code
--- Additional Comments From pluto at pld-linux dot org 2004-12-20 12:11 --- oops, unlockMutex contains an error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19088
[Bug other/16513] Libiberty doesn't honor the multi-os-directory settings
-- What|Removed |Added CC||christian dot joensson at ||gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16513
[Bug c/18936] GCC gives internal error and uses all sytem ram before doing so.
-- What|Removed |Added CC||christian dot joensson at ||gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18936
[Bug c++/19076] Pointer to member function not matched to pointer to member template
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-20
12:29 ---
Here's an even simpler testcase:
typedef int F();
struct A { F f; };
templatetypename struct B;
templatetypename T struct BT A::* {};
BF A::* b;
--
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
GCC build triplet|Any |
GCC host triplet|Any |
GCC target triplet|Any |
Keywords||monitored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19076
[Bug target/18967] [4.0 regression] type conflict for __v2di in xmmintrin.h
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-20 12:36 --- Fixed by: * config/i386/i386.c (ix86_init_mmx_sse_builtins): Use long_long_integer_type_node in building V2DI_type_node. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18967
[Bug middle-end/18999] gimplify_init_ctor_eval does not support RANGE_EXPRs
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18999
[Bug c/19089] New: Environment variable TMP may yield gcc: abort with internal error
When a (bash) environment variable TMP is set to a file with execution
rights 0755, gcc aborts with an internal error. E.g.:
# -- bash shell --
$ uname -a
CYGWIN_NT-5.1 DF8JLP0J 1.5.5(0.94/3/2) 2003-09-20 16:31 i686 unknown unknown
Cygwin
$ gcc --version
gcc (GCC) 3.3.1 (cygming special)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ cat a.c
#include stdlib.h
#include stdio.h
int main(int argc , char *argv[]){
printf(Ok.\n);
return 0;
}
$ unset TMP
$ gcc -save-temps a.c
$ touch /tmp/file.txt
$ export TMP=/tmp/file.txt
$ gcc -save-temps a.c
$ chmod u+x /tmp/file.txt
$ gcc -save-temps a.c
$ chmod 0755 /tmp/file.txt
$ gcc -save-temps a.c
gcc: Internal error: Aborted (program collect2)
Please submit a full bug report.
See URL:http://gcc.gnu.org/bugs.html for instructions.
## --
The MAN page does not note a dependency to TMP (only TMPDIR) ist listed.
--
Summary: Environment variable TMP may yield gcc: abort with
internal error
Product: gcc
Version: 3.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: m at verified dot de
CC: gcc-bugs at gcc dot gnu dot org,m at verified dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19089
[Bug target/18371] [3.4 Regression] array subscript out of range in gcc sources
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-20 12:44 --- Fixed on the mainline: * config/i386/i386.c (ix86_split_to_parts): Use an array with four elements for decoding a CONST_DOUBLE on 64 bits targets. -- What|Removed |Added Known to work||4.0.0 Summary|[3.4/4.0 Regression] array |[3.4 Regression] array |subscript out of range in |subscript out of range in |gcc sources |gcc sources http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18371
[Bug other/19089] Environment variable TMP may yield gcc: abort with internal error
-- What|Removed |Added Component|c |other http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19089
[Bug tree-optimization/17949] [4.0 Regression] Tree loop optimization generates unaligned access (STRICT_ALIGNMENT is set)
--- Additional Comments From falk at debian dot org 2004-12-20 12:49 --- (In reply to comment #3) Does this affect *all* STRICT_ALIGNMENT targets? I can at least reproduce it on Alpha. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17949
[Bug other/19088] volatile attr. doesn't work with pointers / wrong code
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-20 12:52 --- This works for me on the mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19088
[Bug debug/19087] Overflowed address in dwarf debug line information
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-20 12:53 --- Can you attach a preprocessed source? -- What|Removed |Added Component|c |debug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087
[Bug other/19089] Environment variable TMP may yield gcc: abort with internal error
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-20 13:01 --- In a way this is not a bug: fd = mkstemps (temp_filename, suffix_len); /* If mkstemps failed, then something bad is happening. Maybe we should issue a message about a possible security attack in progress? */ if (fd == -1) abort (); /* Similarly if we can not close the file. */ if (close (fd)) abort (); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19089
[Bug other/19088] volatile attr. doesn't work with pointers / wrong code
--- Additional Comments From rearnsha at gcc dot gnu dot org 2004-12-20 13:03 --- Not a bug. You aren't showing the relocations that still need applying. You need to add the -r flag to objdump for this. Looking at the assembler output we see: lockMutex: @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. @ lr needed for prologue .L2: ldr r3, [r0, #0] cmp r3, #1 bne .L2 sub r3, r3, #1 str r3, [r0, #0] mov pc, lr -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19088
[Bug c/18936] GCC gives internal error and uses all sytem ram before doing so.
--- Additional Comments From falk at debian dot org 2004-12-20 13:08 --- Please provide the preprocessed source, as described on http://gcc.gnu.org/bugs.html. Also, it would be nice if you could retry with more swap and try to find out how much it actually uses. -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18936
[Bug target/10395] [x86] vector types are incorrectly aligned causing crash in multi-threaded apps or when using in main, plus other times
--- Additional Comments From uros at kss-loka dot si 2004-12-20 13:16 --- (In reply to comment #21) The default pthread library in RedHat 8.0 does align stack properly, as I am able to trigger the bug. Testcase shows: Uros, did you mean does *not* align the stack properly? If so, I would say yes, we should close the PR as WONTFIX, since we can't do anything about it. Ouch... RH 8.0 does _NOT_ align stack properly. However, on second thought, is it worth to add some kind of -mforce-stack-align parameter to gcc? Or maybe an attribute to the function? This way, one could add a stack alignment code, similar to main() stack alignment: pushl %ebp movl %esp, %ebp subl $8, %esp andl $-16, %esp - this subl $16, %esp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10395
[Bug c++/19076] Pointer to member function not matched to pointer to member template
--- Additional Comments From giovannibajo at libero dot it 2004-12-20 13:25 --- Does this require the member function to be *declared* through the typedef? Otherwise I think it looks easier to understand where the bug is if the testcase uses a normal declaration for the member function inside the class definition. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19076
[Bug tree-optimization/17949] [4.0 Regression] Tree loop optimization generates unaligned access (STRICT_ALIGNMENT is set)
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni dot cz 2004-12-20 13:35 --- Subject: Re: [4.0 Regression] Tree loop optimization generates unaligned access (STRICT_ALIGNMENT is set) Does this affect *all* STRICT_ALIGNMENT targets? Yes, it should. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17949
[Bug debug/19087] Overflowed address in dwarf debug line information
--- Additional Comments From tsandnes at atmel dot no 2004-12-20 13:40 --- Subject: Re: Overflowed address in dwarf debug line information pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-20 12:53 --- Can you attach a preprocessed source? Hmm, That will probably be a problem. I have just piled together a lot of generated code and a library to be able to create an object with this much program memory. Would the preprocessed source (of the file with main()) be of use anyway? The library is a trick to fool avr-gcc into creating the object without failing. If I just put it all in one file and try to compile it I get errors like these: avr-gcc -Wall -gdwarf-2 -mmcu=atmega128 -O0 largeandsimple.c -o largeandsimple.elf c:\DOCUME~1\tsandnes\LOCALS~1\Temp/ccew.s: Assembler messages: c:\DOCUME~1\tsandnes\LOCALS~1\Temp/ccew.s:55075: Error: value of 66702 too large for field of 2 bytes at 16 c:\DOCUME~1\tsandnes\LOCALS~1\Temp/ccew.s:92562: Error: value of 66702 too large for field of 2 bytes at 52828 c:\DOCUME~1\tsandnes\LOCALS~1\Temp/ccew.s:54188: Error: value of 65542 too large for field of 2 bytes at 10009 ... Hmm, come to think of it, maybe I should report this as a bug too? Torleif -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087
[Bug c++/19076] Pointer to member function not matched to pointer to member template
--- Additional Comments From pcarlini at suse dot de 2004-12-20 13:40
---
Hi Giovanni. Indeed, I don't think typedefs are directly involved and probably
we can further simplify like this:
===
struct A {};
templatetypename struct B;
templatetypename T struct BT A::* {};
Bvoid(A::*)() b;
===
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19076
[Bug rtl-optimization/19012] [4.0 Regression] ICE on testsuite/gcc.c-torture/execute/930208-1.c with -fpack-struct -Os
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-20 13:41 --- : Search converges between 2004-08-12-trunk (#511) and 2004-08-13-trunk (#512). Here is the backtrace: #0 0x0060a98c in memory_operand (op=0xabababab, mode=VOIDmode) at ../../gcc/recog.c:1279 #1 0x0049ef78 in get_attr_memory (insn=0x4165d8e8) at insn-attrtab.c:41391 #2 0x0042e1a0 in insn_default_latency (insn=0x4165d8e8) at insn-attrtab.c:7824 #3 0x007cdcbc in insn_cost (insn=0x4165d8e8, link=0x416d2e88, used=0x416cb64c) at ../../gcc/ haifa-sched.c:537 #4 0x007cdfc0 in priority (insn=0x4165d8e8) at ../../gcc/haifa-sched.c:610 #5 0x007d20c8 in set_priorities (head=0x4165ded8, tail=0x416cb64c) at ../../gcc/haifa-sched.c: 2210 #6 0x00837160 in schedule_region (rgn=0) at ../../gcc/sched-rgn.c:2253 #7 0x00837f00 in schedule_insns (dump_file=0x0) at ../../gcc/sched-rgn.c:2489 #8 0x006fd764 in rest_of_handle_sched2 () at ../../gcc/passes.c:681 #9 0x00700394 in rest_of_compilation () at ../../gcc/passes.c:1755 #10 0x00105ed4 in execute_one_pass (pass=0x8e5c98) at ../../gcc/tree-optimize.c:525 #11 0x00106038 in execute_pass_list (pass=0x8e5c98) at ../../gcc/tree-optimize.c:562 #12 0x00106474 in tree_rest_of_compilation (fndecl=0x416c84b0) at ../../gcc/tree-optimize.c:661 #13 0x0002f5b0 in c_expand_body (fndecl=0x416c84b0) at ../../gcc/c-decl.c:6412 #14 0x00753b74 in cgraph_expand_function (node=0x416c8618) at ../../gcc/cgraphunit.c:822 #15 0x007569ac in cgraph_expand_all_functions () at ../../gcc/cgraphunit.c:1689 #16 0x00756e58 in cgraph_optimize () at ../../gcc/cgraphunit.c:1786 #17 0x00032ee8 in c_write_global_declarations () at ../../gcc/c-decl.c:7390 #18 0x0069c0e0 in compile_file () at ../../gcc/toplev.c:1005 #19 0x0069ed5c in do_compile () at ../../gcc/toplev.c:2085 #20 0x0069edf8 in toplev_main (argc=6, argv=0xbd38) at ../../gcc/toplev.c:2117 #21 0x000c6b34 in main (argc=6, argv=0xbd38) at ../../gcc/main.c:35 -- What|Removed |Added GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | Summary|[4.0 Regression]ICE on |[4.0 Regression] ICE on |testsuite/gcc.c-|testsuite/gcc.c- |torture/execute/930208-1.c |torture/execute/930208-1.c |with -fpack-struct -Os |with -fpack-struct -Os http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19012
[Bug debug/19087] Overflowed address in dwarf debug line information
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-20 13:43 --- Just the preprocessed for largeandsimple.c will be fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087
[Bug c++/18370] [3.4/4.0 Regression] cp_parser_initializer_list uninit variable problems
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18370
[Bug tree-optimization/14638] [4.0 Regression] Variables disappear from debug info at -O1
-- What|Removed |Added Severity|normal |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14638
[Bug tree-optimization/18706] [4.0 Regression] ACATS ce2208b ICE expected ssa_name, have var_decl in verify_ssa, at tree-ssa.c:637
-- What|Removed |Added Severity|normal |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18706
[Bug tree-optimization/18828] [4.0 Regression] Extraneous warning with var_start and optimization
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-20 13:56 --- : Search converges between 2004-05-11-trunk (#454) and 2004-05-14-trunk (#455). : Search converges between 2003-07-16-ssa (#32) and 2003-07-17-ssa (#33). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18828
[Bug tree-optimization/19080] [4.0 regression] ICE while compiling linux kernel
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-20 13:59 --- Also I got a similar failure with the Ada front-end compiling the library. -- What|Removed |Added Severity|normal |critical GCC build triplet|x86_64-linux| GCC host triplet|x86_64-linux| GCC target triplet|x86_64-linux| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19080
[Bug tree-optimization/17949] [4.0 Regression] Tree loop optimization generates unaligned access (STRICT_ALIGNMENT is set)
-- What|Removed |Added Severity|normal |critical GCC target triplet|ia64-*-*, sparc*-*-*|ia64-*-*, sparc*-*-*, ||alpha*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17949
[Bug tree-optimization/16220] [4.0 Regression] Jump pessimization
-- What|Removed |Added Severity|normal |minor GCC build triplet|alphaev68-unknown-linux-gnu | GCC host triplet|alphaev68-unknown-linux-gnu | GCC target triplet|alphaev68-unknown-linux-gnu |alpha*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16220
[Bug debug/19087] Overflowed address in dwarf debug line information
--- Additional Comments From tsandnes at atmel dot com 2004-12-20 14:02 --- Created an attachment (id=7782) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7782action=view) Preprosessed source of a large object file that fails to build for atmega128 Trying to produce a simple and independent test case to reproduce this bug, I generated a lot of sourcecode and put it in one file. ( The goal was to get above 64K). When compiling this file, i get this output from avr-gcc: avr-gcc -Wall -gdwarf-2 -mmcu=atmega128 -O0 -save-temps largeandsimple.c -o largeandsimple.elf c:\DOCUME~1\tsandnes\LOCALS~1\Temp/ccUz.s: Assembler messages: c:\DOCUME~1\tsandnes\LOCALS~1\Temp/ccUz.s:55075: Error: value of 66702 too large for field of 2 bytes at 16 c:\DOCUME~1\tsandnes\LOCALS~1\Temp/ccUz.s:92562: Error: value of 66702 too large for field of 2 bytes at 52836 c:\DOCUME~1\tsandnes\LOCALS~1\Temp/ccUz.s:54188: Error: value of 65542 too large for field of 2 bytes at 10009 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087
[Bug target/19087] Overflowed address in dwarf debug line information
-- What|Removed |Added Component|debug |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087
[Bug target/19087] Overflowed address in dwarf debug line information
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-20 14:05 --- Hmm, on the mainline I get an error about dwarf2 not being supported: t.c:1: error: target system does not support the dwarf-2 debug format -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087
[Bug target/19087] Overflowed address in dwarf debug line information
--- Additional Comments From tsandnes at atmel dot no 2004-12-20 14:15 --- Subject: Re: Overflowed address in dwarf debug line information pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-20 14:05 --- Hmm, on the mainline I get an error about dwarf2 not being supported: t.c:1: error: target system does not support the dwarf-2 debug format avr-gcc must be built with dwarf support to be able to produce objects with dwarf2 debugging information. It is probably nececssary to build the entire toolchain from scratch. Something like this. 1 cd binutils 2 ./configure --target=avr-elf --with-dwarf2 3 gmake 4 gmake install 5 cd ../gcc 6 ./configure --enable-languages=c,c++ --target=avr --with-dwarf2 7 gmake 8 gmake install 9 cd ../avr-libc 10 ./configure --prefix=/usr/local 11 gmake 12 gmake install Are you familiar with the AVR port? Thanks for looking into this! Torleif -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087
[Bug c/19090] New: Non-useful warnings included in -Wall
Warning about passing a signed int to a function that expects an unsigned int, or vice-versa does not seem like a useful warning to me. On a Linux kernel build, % zgrep -c 'differ in signedness' 2.6.10rc2-gcc4-warnings.gz 6809 This is quite high and drowns out many warnings that are more useful. My understanding is that these warnings only turn into actual bugs on machines that don't use 2's complement, and I'm not aware of a gcc port to any 1's complement or sign-magnitude machines. So could this warning be moved to -W please? -- Summary: Non-useful warnings included in -Wall Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: willy at debian dot org CC: ak at muc dot de,gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19090
[Bug c/19090] Non-useful warnings included in -Wall
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-20 14:46 --- This is useful warning as it is not really valid code without a cast. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19090
[Bug rtl-optimization/13366] ICE using MMX/SSE builtins with -O
--- Additional Comments From uros at kss-loka dot si 2004-12-20 14:55
---
The testcase from the description fails in the same way for current mainline:
gcc -O -msse pr13366.c
pr13366.c:1: warning: specifying vector types with __attribute__ ((mode)) is
deprecated
pr13366.c:1: warning: use __attribute__ ((vector_size)) instead
pr13366.c: In function 'f':
pr13366.c:9: error: unable to find a register to spill in class 'GENERAL_REGS'
pr13366.c:9: error: this is the insn:
(insn 15 13 17 0 (parallel [
(set (subreg:SI (reg/v:V4HI 29 mm0 [orig:59 vec ] [59]) 0)
(and:SI (subreg:SI (reg/v:V4HI 29 mm0 [orig:59 vec ] [59]) 0)
(const_int -65536 [0x])))
(clobber (reg:CC 17 flags))
]) 206 {*andsi_1} (insn_list:REG_DEP_TRUE 13 (nil))
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
pr13366.c:9: internal compiler error: in spill_failure, at reload1.c:1873
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
BTW: Changing 1 as suggested in report to 5, does not change the ICE.
--
What|Removed |Added
Known to fail||4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13366
[Bug c/19090] Non-useful warnings included in -Wall
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-20 14:56 --- http://gcc.gnu.org/ml/gcc/2003-10/msg00184.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19090
[Bug target/18371] [3.4 Regression] array subscript out of range in gcc sources
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-20 15:02 --- I'm going to test it for GCC 3.4 too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18371
[Bug rtl-optimization/19078] [4.0 Regression] Poor quality code after loop unrolling.
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-20 15:04 --- And, Paolo, when was the last time you looked at microbenchmarks? ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19078
[Bug rtl-optimization/13366] ICE using MMX/SSE builtins with -O
--- Additional Comments From uros at kss-loka dot si 2004-12-20 15:05 --- Could info at http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02453.html help to fix this bug? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13366
[Bug target/14631] common subexpression elimilation error with sse2 instrinsic _mm_insert_epi16
--- Additional Comments From uros at kss-loka dot si 2004-12-20 15:07 --- Prototype patch here: http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02450.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14631
[Bug tree-optimization/19080] [4.0 regression] ICE while compiling linux kernel
--- Additional Comments From dnovillo at gcc dot gnu dot org 2004-12-20 15:10 --- Working on a fix. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2004-12-19 17:28:51 |2004-12-20 15:10:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19080
[Bug rtl-optimization/13366] ICE using MMX/SSE builtins with -O
--- Additional Comments From lloyd at acm dot jhu dot edu 2004-12-20 15:11 --- Oops, my report on that was not clear. Change the 1 to a 0 to get a different ICE, at least in whatever random 3.4.0 snapshot I have installed (20040107). It's apparently a 0/!0 thing. I have not checked this on a 3.4 release or mainline, though. Here is the what I see after changing the 1 to a 0: ice.c: In function `f': ice.c:8: internal compiler error: in subreg_hard_regno, at emit-rtl.c:1026 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13366
[Bug target/10395] [x86] vector types are incorrectly aligned causing crash in multi-threaded apps or when using in main, plus other times
--- Additional Comments From bangerth at dealii dot org 2004-12-20 15:13 --- An attribute could work. I doubt that a general flag would be useful, since one in general doesn't know which functions are thread entry points, so the compiler would have to emit such stack alignment code into the prolog of each function it finds. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10395
[Bug rtl-optimization/19078] [4.0 Regression] Poor quality code after loop unrolling.
--- Additional Comments From pcarlini at suse dot de 2004-12-20 15:13 --- ;) Well, many people believe I look too *often* at microbenchmarks... ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19078
[Bug c++/19076] Pointer to member function not matched to pointer to member template
--- Additional Comments From bangerth at dealii dot org 2004-12-20 15:15 --- This last testcase indeed still shows the problem. It doesn't compile with gcc, but does with icc. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19076
[Bug libstdc++/19091] New: problem with string to double conversion (overflow situation)
Following conversion should overflow, and not return 8.02393e-308. Same
problem, although different output, when reading 4E308 from standard input.
#include iostream
#include sstream
using namespace std;
int main()
{
double r;
istringstream s(+4E308);
s r;
cout r endl;
}
--
Summary: problem with string to double conversion (overflow
situation)
Product: gcc
Version: 3.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stefan dot becuwe at ua dot ac dot be
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i386 linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19091
[Bug rtl-optimization/19078] [4.0 Regression] Poor quality code after loop unrolling.
--- Additional Comments From pcarlini at suse dot de 2004-12-20 15:22 --- More seriously, I think that we (the libstdc++-v3 people) should more carefully test the effect of the new optimizations on std::algorithm: indeed, we are talking about benchmarks, not pointless microbenchmarks: std:algorithm is *full* of small loops like this one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19078
[Bug other/19082] [4.0 Regression] build/genattrtab: out of memory allocating 151568 bytes after a total of 4161651196 bytes
-- What|Removed |Added CC||segher at kernel dot ||crashing dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19082
[Bug c++/19043] [3.3/3.4 regression] -fpermissive gives bad loop initializations
--- Additional Comments From bangerth at dealii dot org 2004-12-20 15:34 --- Confirmed. It works in 2.95 and mainline, but nothing in between (I tested 3.2.3, 3.3.4, 3.4.3). It is thus a regression, although I believe not a very serious one given that the code is in fact invalid and only compiles if you give the -fpermissive flag. W. -- What|Removed |Added Known to fail|3.3.2 |3.3.2 3.2.3 3.4.3 3.3.4 ||3.3.3 Known to work|4.0.0 |4.0.0 2.95 Summary|[3.4/3.3 only] -fpermissive |[3.3/3.4 regression] - |gives bad loop |fpermissive gives bad loop |initializations |initializations Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19043
[Bug libstdc++/19091] problem with string to double conversion (overflow situation)
--- Additional Comments From pcarlini at suse dot de 2004-12-20 15:35 --- Indeed, *it overflows*. Try changing you testcase like this: istringstream s(+4E308); s r; if (!s.fail()) cout r endl; What happens, is just that overflows and r is left unchanged; by chance, is a very small number. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19091
[Bug rtl-optimization/13366] ICE using MMX/SSE builtins with -O
--- Additional Comments From uros at kss-loka dot si 2004-12-20 15:39
---
Equivalent SSE2 version works OK:
typedef int v8hi __attribute__ ((mode (V8HI)));
int
f (unsigned short n)
{
v8hi vec = { 0, 0, 0, 0, 0, 0, 1, n };
v8hi hw = __builtin_ia32_pmulhw128 (vec, vec);
return (__builtin_ia32_pextrw128 (hw, 0));
}
SSE2 example produces following RTL:
(insn 13 11 15 1 (set (reg/v:V8HI 59 [ vec ])
(const_vector:V8HI [
(const_int 0 [0x0])
(const_int 0 [0x0])
(const_int 0 [0x0])
(const_int 0 [0x0])
(const_int 0 [0x0])
(const_int 0 [0x0])
(const_int 0 [0x0])
(const_int 0 [0x0])
])) -1 (nil)
(nil))
(insn 15 13 16 1 (parallel [
(set (subreg:SI (reg/v:V8HI 59 [ vec ]) 12)
(and:SI (subreg:SI (reg/v:V8HI 59 [ vec ]) 12)
(const_int -65536 [0x])))
(clobber (reg:CC 17 flags))
]) -1 (nil)
(nil))
...
and MMX version produces:
(insn 13 11 15 1 (clobber (reg/v:V4HI 59 [ vec ])) -1 (nil)
(nil))
(insn 15 13 17 1 (parallel [
(set (subreg:SI (reg/v:V4HI 59 [ vec ]) 0)
(and:SI (subreg:SI (reg/v:V4HI 59 [ vec ]) 0)
(const_int -65536 [0x])))
(clobber (reg:CC 17 flags))
]) -1 (nil)
(nil))
...
The trouble is in (insn 13). There is no setting of reg 59 to zero.
Also, mainline does not ICE for
v4hi vec = { 0, 0, 0, n };
and its SSE2 equivalent as suggested in comment #6 for both MMX and SSE2
versions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13366
[Bug libfortran/19071] complex formatted output has too many items
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-20 16:10:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19071
[Bug tree-optimization/13761] [tree-ssa] component refs to the same struct should not alias
--- Additional Comments From dberlin at gcc dot gnu dot org 2004-12-20 16:35 --- The structure-aliasing branch now has code (or will as soon as cvs finishes committing) that will fix dale's testcaes to the extent i can. We produce identical code for both loops, now. I haven't quite fixed dan n's testcase yet, because it involves indirect_refs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13761
[Bug tree-optimization/17617] Micro-optimize INTEGRAL_TYPE_P (or tree.def rather)
--- Additional Comments From bangerth at dealii dot org 2004-12-20 17:08 --- A patch (with following long discussion) has been proposed here: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01495.html W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17617
[Bug c++/17648] [3.3/3.4 Regression] template destructor was not called for inherited classes
--- Additional Comments From SWElef at post dot sk 2004-12-20 17:09 ---
(In reply to comment #13)
Here's a condensed version of Wolfgang's testcase:
int i=1;
class A;
templateint struct B
{
A *p;
~B()
{
--i;
p=0;
if(p) delete p;
}
};
class C : B0 {};
class A { C c; };
int main()
{
{ C c; }
return i;
}
This is not a condensed version of Wolfgang's testcase. While Wolfgang's
testcase is well-formed, your is ill-formed. The difference is that it uses
a pointer to object of _non-dependent_ incomplete type, i.e. it is invalid
according to tc1:14.6/7:
Knowing which names are type names allows the syntax of every template
definition to be checked. No diagnostic shall be issued for a template
definition for which a valid specialization can be generated. If no valid
specialization can be generated for a template definition, and that
template is not instantiated, the template definition is ill-formed,
no diagnostic required. If a type used in a non-dependent name is
incomplete at a point at which a template is defined but is complete
at the point at which an instantiation is done, and if the completeness
of that type affects whether or not the program is well-formed or affects
the semantics of the program, the program is ill-formed; no diagnostic
required. [Note: ...]
The details are very subtle because the template definition is not ill-formed
by itself. std:5.3.5/5 says
If the object being deleted has incomplete class type at the point of
deletion and the complete class has a non-trivial destructor or a
deallocation function, the behavior is undefined.
Thus, it would be well defined if the class A was later completed with
trivial destructor and no class specific deallocation function.
It is ill-formed because class A was incomplete at the point of definition
of Bint::~B(), it was later defined with non-trivial destructor _and_
B0::~B() (with delete p;) was instantiated. For example the snippet from
comment #14 _as short as it is_ is AFAICT well-formed.
In this context it might be important to note that starting from gcc3.4
we have the two phase lookup. gcc3.4+ should be able to issue the same
warning for the expression delete p; as for an ordinary delete expression
involving an incomplete type.
Regards,
Vladimir Marko
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17648
[Bug tree-optimization/17617] Micro-optimize INTEGRAL_TYPE_P (or tree.def rather)
--- Additional Comments From bangerth at dealii dot org 2004-12-20 17:14
---
The question raised in several of the messages in that discussion
is whether an enumeration of equality checks is converted into a
range check if the tested values are consecutive.
Here is the answer:
enum E
{
eins = 1,
zwei = 2,
drei = 3,
vier = 4,
fuenf= 5,
sechs= 6
};
bool test_range (E e)
{
return e==drei || e==vier || e==fuenf;
}
This is indeed compiled into a range check:
_Z10test_range1E:
pushl %ebp
movl%esp, %ebp
movl8(%ebp), %eax
popl%ebp
subl$3, %eax
cmpl$2, %eax
setbe %al
movzbl %al, %eax
ret
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17617
[Bug target/19087] Overflowed address in dwarf debug line information
--- Additional Comments From ericw at evcohs dot com 2004-12-20 17:44 --- (In reply to comment #5) Hmm, on the mainline I get an error about dwarf2 not being supported: t.c:1: error: target system does not support the dwarf-2 debug format If you're talking about HEAD/4.0, then a seperate bug report needs to be filed. The avr port needs to be able to be configured for DWARF2 debug info. (Yes, I know that the avr port of GDB only uses stabs, but other tools use DWARF2.) The OP is using 3.4.1. -- What|Removed |Added CC||ericw at evcohs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087
[Bug tree-optimization/19080] [4.0 regression] ICE while compiling linux kernel
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-20 18:18 --- Subject: Bug 19080 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-20 18:18:37 Modified files: gcc: ChangeLog tree-flow-inline.h tree-ssa-alias.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/compile: pr19080.c Log message: PR tree-optimization/19080 Merge from tree-cleanup-branch * tree-flow-inline.h (clear_call_clobbered): New function. * tree-ssa-alias.c (init_alias_info): Call it. testsuite/ChangeLog PR tree-optimization/19080 * gcc.c-torture/compile/pr19080.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.6899r2=2.6900 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-flow-inline.h.diff?cvsroot=gccr1=2.27r2=2.28 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-alias.c.diff?cvsroot=gccr1=2.63r2=2.64 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4784r2=1.4785 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/pr19080.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19080
[Bug tree-optimization/19080] [4.0 regression] ICE while compiling linux kernel
--- Additional Comments From dnovillo at gcc dot gnu dot org 2004-12-20 18:23 --- Fix: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01551.html -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19080
[Bug tree-optimization/19038] [4.0 Regression] out-of ssa causing loops to have more than one BB
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-20 18:25 --- After getting access to sixtrack sources, steven and I found this is a problem in out of ssa committing on a new BB, I almost have a patch but it has one issue in that we could be the new statement's results in the control flow statement as we insert before it. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|enhancement |minor Status|UNCONFIRMED |NEW Component|rtl-optimization|tree-optimization Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-20 18:25:23 date|| Summary|Loop header copying |[4.0 Regression] out-of ssa ||causing loops to have more ||than one BB Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19038
[Bug c++/19092] New: g++ accepts code that violates 14.6.4.2
The attached snippet should not compile, since foo() has internal linkage. Instead, g++ compiles it happily and without a warning even when given -Wall -W -pedantic. -- Summary: g++ accepts code that violates 14.6.4.2 Product: gcc Version: 3.4.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bagnara at cs dot unipr dot it CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19092
[Bug c++/19092] g++ accepts code that violates 14.6.4.2
--- Additional Comments From bagnara at cs dot unipr dot it 2004-12-20 18:32 --- Created an attachment (id=7784) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7784action=view) Small program that allows to reproduce the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19092
[Bug rtl-optimization/19078] [4.0 Regression] Poor quality code after loop unrolling.
--- Additional Comments From rakdver at gcc dot gnu dot org 2004-12-20 18:44 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01554.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19078
[Bug c++/19092] g++ accepts code that violates 14.6.4.2
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-20 18:50 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||accepts-invalid Last reconfirmed|-00-00 00:00:00 |2004-12-20 18:50:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19092
[Bug tree-optimization/19038] [4.0 Regression] out-of ssa causing loops to have more than one BB
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-20
19:04 ---
The reduced testcase (well heavely modified) looks like:
int
f (int temp2, int temp3, int xlvj_, int zlvj_, int yv1j_, int yv2j_)
{
int temp1, temp5;
for(;;) {
temp1 = temp2*xlvj_ - temp3*zlvj_;
temp3 = temp2*zlvj_ + temp3*xlvj_;
temp5 = temp2;
temp2 = temp1;
if (temp3)
break;
}
return yv1j_ * yv2j_;
}
Before the tree-ssa we would produce one BB when creating RTL but after out of
ssa produces an extra
BB to hold temp2 = temp1;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19038
[Bug libfortran/19032] modulo generates wrong result for divisor 1 and -1
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2004-12-16 14:30:16 |2004-12-20 19:08:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19032
[Bug tree-optimization/19038] [4.0 Regression] out-of ssa causing loops to have more than one BB
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-20 19:23 --- This also causes a compile time issue as the RTL optimizers and the register allocator have to do more work. -- What|Removed |Added Keywords||compile-time-hog http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19038
[Bug tree-optimization/19038] [4.0 Regression] out-of ssa causing loops to have more than one BB
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-20 19:47 --- (In reply to comment #8) The reduced testcase (well heavely modified) looks like: Here is the resulting loop asm (on x86 where shows up worse than ppc which is the same because the RA does its work better there): .L7: movl%edx, %ecx .L3: movl%ecx, %edx movl%ebx, %eax imull %edi, %edx imull %esi, %eax imull %esi, %ecx subl%eax, %edx movl%ebx, %eax movl%ecx, %ebx imull %edi, %eax addl%eax, %ebx je .L7 Compared to 3.4.0: .L2: movl16(%ebp), %ebx movl%eax, %ecx movl%esi, %edx imull 16(%ebp), %eax imull %edi, %ecx imull %esi, %ebx imull %edi, %edx movl%ebx, %esi subl%ecx, %esi addl%edx, %eax je .L2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19038
[Bug middle-end/19068] [3.3 only] Wrong code for MIN_EXPR and MAX_EXPR
--- Additional Comments From hjl at lucon dot org 2004-12-20 19:54 --- g++.dg/opt/max1.C still failed on both Linux/ia64 and Linux/x86_64: http://gcc.gnu.org/ml/gcc-testresults/2004-12/msg00919.html http://gcc.gnu.org/ml/gcc-testresults/2004-12/msg00923.html They are both 64bit targets. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19068
[Bug middle-end/19093] New: g++.dg/opt/max1.C fails on ia64 and x86_64
g++.dg/opt/max1.C still failed on both Linux/ia64 and Linux/x86_64: http://gcc.gnu.org/ml/gcc-testresults/2004-12/msg00919.html http://gcc.gnu.org/ml/gcc-testresults/2004-12/msg00923.html They are both 64bit targets. -- Summary: g++.dg/opt/max1.C fails on ia64 and x86_64 Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P2 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19093
[Bug middle-end/19068] [3.3 only] Wrong code for MIN_EXPR and MAX_EXPR
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-20 19:56 --- Please next time file a new bug since the orginal bug was fixed, I filed PR 19093 for the new bug. -- What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19068
[Bug libfortran/19032] modulo generates wrong result for divisor 1 and -1
--- Additional Comments From tobi at gcc dot gnu dot org 2004-12-20 19:56 --- Updated patch here: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01563.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19032
[Bug other/19093] g++.dg/opt/max1.C fails on ia64 and x86_64
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-20
20:00 ---
Actually it is just the testcase is invalid for 64bit targets (woops, my fault
since I made it).
This patch should fix the problem:
Index: g++.dg/opt/max1.C
===
RCS file: /cvs/gcc/gcc/gcc/testsuite/g++.dg/opt/max1.C,v
retrieving revision 1.2
diff -u -p -r1.2 max1.C
--- g++.dg/opt/max1.C 19 Dec 2004 20:11:15 - 1.2
+++ g++.dg/opt/max1.C 20 Dec 2004 19:59:13 -
@@ -10,7 +10,7 @@ long fff[10];
void f(long a)
{
int i;
- a = *((long*)(a+5)) ? *((long*)(a+1));
+ a = *((long*)(a+1+sizeof(long))) ? *((long*)(a+1));
for(i=0;i10;i++)
fff[i] = a;
I will apply it to all the branches where this is effected, 3.3, 3.4, and the
mainline when I get home later
today.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
Component|middle-end |other
Ever Confirmed||1
Keywords|wrong-code |
Last reconfirmed|-00-00 00:00:00 |2004-12-20 20:00:59
date||
Target Milestone|--- |3.3.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19093
[Bug libstdc++/19086] libstdc++ testsuite fails due to missing C99 functions
--- Additional Comments From pcarlini at suse dot de 2004-12-20 20:02 --- *** This bug has been marked as a duplicate of 17243 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19086
[Bug libstdc++/17243] Test failures due to missing C99 symbols
--- Additional Comments From pcarlini at suse dot de 2004-12-20 20:02 --- *** Bug 19086 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17243
[Bug tree-optimization/19067] ICE in tree-if-conv
--- Additional Comments From dpatel at apple dot com 2004-12-20 20:05 --- Subject: Re: ICE in tree-if-conv I'll verify whether TCB patch works here or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19067
[Bug c++/19044] Alternate asm name for atan ignored when calling __builtin_atan
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-20 20:11 --- Subject: Bug 19044 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-20 20:11:42 Modified files: gcc: ChangeLog c-common.c c-common.h c-decl.c gcc/cp : ChangeLog decl.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/ext: builtin6.C Log message: PR c++/19044 * c-common.c (set_builtin_user_assembler_name): New. * c-common.h (set_builtin_user_assembler_name): Declare. * c-decl.c (finish_decl): Use set_builtin_user_assembler_name * decl.c (make_rtl_for_nonlocal_decl): Use set_builtin_user_assembler_name * g++.dg/ext/builtin6.C: New Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.6900r2=2.6901 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-common.c.diff?cvsroot=gccr1=1.594r2=1.595 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-common.h.diff?cvsroot=gccr1=1.272r2=1.273 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-decl.c.diff?cvsroot=gccr1=1.616r2=1.617 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4543r2=1.4544 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gccr1=1.1342r2=1.1343 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4785r2=1.4786 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/builtin6.C.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19044
[Bug target/18987] [4.0 regression] [ia64] Extra '.restore sp' in tail call
--- Additional Comments From davidm at hpl dot hp dot com 2004-12-20 20:12 --- (In reply to comment #6) Jim, David, can one of you look at this, and maybe revert the patch for PR13158 because it causes this regression? Reverting the patch doesn't sound like a good idea, because it will only replace a noticable code-generation bug with a hard to notice one. The real question is why anyone would use -fno-omit-frame-pointer on ia64. That sounds like a bug. Is the code coming from pine? If so, we should see about getting that fixed. In any case, I'll attach a patch that fixes the problem for the test-case. Jim is in a better position to say whether that's a reasonable way of solving the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18987
[Bug bootstrap/19094] New: bootstrap errors
2 questions: during make bootstrap, on RedHat 3.3.3-7, there errors occur at the end: make[3]: Entering directory `/usr/local/bin/gcc-3.2.3/gcc/ada' gcc -c -g -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -W -Wall -gnatpg -gnata -g -O1 -fno-inline \ -I- -I. -I. a-except.adb a-except.adb:109:04: warning: named number Address_Image_Length is not referenced make[3]: *** [a-except.o] Error 1 make[3]: Leaving directory `/usr/local/bin/gcc-3.2.3/gcc/ada' make[2]: *** [gnat1] Error 2 make[2]: Leaving directory `/usr/local/bin/gcc-3.2.3/gcc' make[1]: *** [stage1_build] Error 2 make[1]: Leaving directory `/usr/local/bin/gcc-3.2.3/gcc' make: *** [bootstrap] Error 2 Also, I'm trying to install this 3.2.3 version of gcc on this Linux OS that came with gcc 3.3.3 (I need an older version). Once 3.2.3 is installed, how do I make it the default compiler? Right now, it looks like this: gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) thanks for the help - nick -- Summary: bootstrap errors Product: gcc Version: 3.2.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: niorio19 at yahoo dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19094
[Bug tree-optimization/19067] ICE in tree-if-conv
--- Additional Comments From dpatel at apple dot com 2004-12-20 20:32 --- Subject: Re: ICE in tree-if-conv On Dec 18, 2004, at 10:28 AM, pinskia at gcc dot gnu dot org wrote: I don't know but could possible the patch in here: http://gcc.gnu.org/ml/gcc-patches/2004-12/ msg00514.html which is already on the tcb branch help here? Yes, this patch helps. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19067
[Bug ada/19094] bootstrap errors
-- What|Removed |Added Component|bootstrap |ada http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19094
[Bug c++/19044] Alternate asm name for atan ignored when calling __builtin_atan
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-20 20:40 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19044
