[Bug target/16185] ICE: in spill_failure, at reload1.c:1892, global registers and long long

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-27 03:32 --- x86 is known to be register stared and global registers just makes it worse because they make the registers fixed. -- What|Removed |Added --

[Bug target/16185] ICE: in spill_failure, at reload1.c:1892

-- What|Removed |Added Priority|P2 |P1 Last reconfirmed|-00-00 00:00:00 |2004-12-27 03:15:48 date|

[Bug target/17643] [3.3 Regression] ICE in propagate_one_insn, at flow.c:1582

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-27 02:55 --- Subject: Bug 17643 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_3-branch Changes by: [EMAIL PROTECTED] 2004-12-27 02:55:49 Modified files: gcc: Change

[Bug target/17643] [3.3 Regression] ICE in propagate_one_insn, at flow.c:1582

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-27 02:42 --- Fixed now in 3.4.4 and 4.0.0. -- What|Removed |Added Known to fail|3.4.2 3.4.4 3.3.4 3.

[Bug bootstrap/19135] [4.0 Regression] build failure in libiberty multilibs

--- Additional Comments From hjl at lucon dot org 2004-12-27 02:41 --- There is no need for testing libiberty-multilib-2.patch. Libliberty doesn't build a shared library. It just builds an archive with PIC objects. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19135

[Bug target/17643] [3.3/3.4/4.0 Regression] ICE in propagate_one_insn, at flow.c:1582

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-27 01:08 --- Subject: Bug 17643 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-27 01:08:09 Modified files: gcc: ChangeLog gcc/config/pa : p

[Bug regression/19120] [4.0 Regression] ICE: in ten_to_ptwo, at real.c:2007

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-27 01:07 --- The reason why I added the "wrong-code" keyword is because it is after stage2 where the ICE occurs. But then again we need the exact version used, and how you configured to build the compiler too. --

[Bug c/18936] GCC gives internal error and uses all sytem ram before doing so.

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-27 01:04 --- (In reply to comment #3) > Subject: Re: GCC gives internal error and uses all sytem ram before doing so. > > I told you where to get the source. But that does not help us here because your system headers

[Bug target/19009] Loading of FP constants into FP reg via SSE reg

-- What|Removed |Added Severity|normal |minor Status|WAITING |NEW Ever Confirmed||1

[Bug target/19129] [3.4 Regression] gcc-3.4.4 ICE while building libobjc

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-27 00:47 --- Note I would not doubt that the reduced testcase is: int *f(void) { return __builtin_apply (0,0,0); } -- What|Removed |Added -

[Bug bootstrap/19151] [4.0 Regression] configure: Could not load module ../libiberty/libiberty.a(libiberty.so.0)

-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-

[Bug target/19116] -fno-finite-math-only does not override -ffast-math

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-27 00:41 --- Can you try just -funsafe-math-optimizations and see what happens I think you will get the same results as "-ffast-math -fno-finite-math-only" as I think an instruction in the .md file checks the wrong f

[Bug target/14149] [3.3 Regression] libgcc2.c:731: internal compiler error: in extract_constrain_insn_cached, at recog.c:2090

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-27 00:38 --- *** Bug 19160 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug target/19160] error when building gcc-3.3.5 for target avr

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-27 00:38 --- Fixed in 3.4.0 and will not fix for 3.3.5, see PR 14149 which this is a dup of. *** This bug has been marked as a duplicate of 14149 *** -- What|Removed |Added -

[Bug target/19161] No emms or femms emitted between MMX and FP instructions

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-27 00:26 --- Found the bug finnally, see PR 14801 for an example. Also PR 16872 is another example. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19161

[Bug target/19161] No emms or femms emitted between MMX and FP instructions

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-27 00:24 --- *** Bug 14801 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug rtl-optimization/14801] wrong-code, gcc -O2 mixed FPU and MMX instructions

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-27 00:24 --- *** This bug has been marked as a duplicate of 19161 *** -- What|Removed |Added

[Bug target/17643] [3.3/3.4/4.0 Regression] ICE in propagate_one_insn, at flow.c:1582

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-27 00:21 --- Subject: Bug 17643 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2004-12-27 00:20:59 Modified files: gcc: Change

[Bug target/19162] [4.0 regression] ICE while building libobjc's sendmsg.c

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-27 00:18 --- Could you test the patch in and report back the results so I send in the patch since I don't have access to arm-linux and arm-elf will doe

[Bug bootstrap/19135] [4.0 Regression] build failure in libiberty multilibs

--- Additional Comments From janis187 at us dot ibm dot com 2004-12-26 23:39 --- A build with the patch libiberty-multilib-3.patch applied to 20041222 sources succeeds, although it doesn't attempt to build libiberty as a shared object. I haven't tried libiberty-multilib-2.patch; is that

[Bug c++/19156] cpp to c conversion

--- Additional Comments From pentek_imre at mailbox dot hu 2004-12-26 23:14 --- okay. then sorry -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19156

[Bug target/19162] [4.0 regression] ICE while building libobjc's sendmsg.c

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-26 22:47 --- The problem is that there is no movxf. So this is definitely a target problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19162

[Bug target/19162] [4.0 regression] ICE while building libobjc's sendmsg.c

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-26 22:26 --- We are trying to emit the following RTL: (Set (reg:XF 115) (reg:XF 16 f0)) So maybe this bug is in the middle-end and related to the subreg work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19162

[Bug target/19162] [4.0 regression] ICE while building libobjc's sendmsg.c

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-26 22:21 --- The bug is in untyped_call. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19162

[Bug target/19162] [4.0 regression] ICE while building libobjc's sendmsg.c

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-26 22:19 --- Here is the reduced testcase: int *f(void) { return __builtin_apply (0,0,0); } We are just going into an infinite loop: #254 0x002d6c04 in operand_subword_force (op=0x4167a020, offset=0, mode=XFmode) at

[Bug target/19162] [4.0 regression] ICE while building libobjc's sendmsg.c

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-26 21:36 --- Confirmed, this bug is related to __builtin_apply, I was waiting for this to be filed. I wonder if there is something which can be done without disabling libobjc for arm-linux or just using libffi. --

[Bug target/19162] [4.0 regression] ICE while building libobjc's sendmsg.c

--- Additional Comments From debian-gcc at lists dot debian dot org 2004-12-26 21:28 --- Created an attachment (id=7826) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7826&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19162

[Bug target/19162] [4.0 regression] ICE while building libobjc's sendmsg.c

-- What|Removed |Added Keywords||ice-on-valid-code Known to fail||4.0.0 Known to work|

[Bug target/19162] New: [4.0 regression] ICE while building libobjc's sendmsg.c

CVS 20041223, no other working HEAD version known. Matthias /home/doko/gcc/gcc-4.0-4.0ds2/build/gcc/xgcc -B/home/doko/gcc/gcc-4.0-4.0ds2/bui ld/gcc/ -B/usr/arm-linux/bin/ -B/usr/arm-linux/lib/ -isystem /usr/arm-linux/incl ude -isystem /usr/arm-linux/sys-include -c -I. -I/home/doko/gcc/gcc-4.0

[Bug target/19161] No emms or femms emitted between MMX and FP instructions

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-26 21:20 --- Confirmed, there is a dup of this filed already. -- What|Removed |Added Status|U

[Bug target/19160] error when building gcc-3.3.5 for target avr

-- What|Removed |Added Component|c |target Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug

[Bug tree-optimization/17578] Missed optimization--failure of gcc.c-torture/execute/ieee/compare-fp-3.c at -O1 and above

--- Additional Comments From danglin at gcc dot gnu dot org 2004-12-26 21:00 --- Fixed by patch. -- What|Removed |Added Status|NEW |RESO

[Bug tree-optimization/17578] Missed optimization--failure of gcc.c-torture/execute/ieee/compare-fp-3.c at -O1 and above

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-26 20:49 --- Subject: Bug 17578 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-26 20:49:15 Modified files: gcc/testsuite : ChangeLog gcc/testsuite/gcc.

[Bug target/19161] New: No emms or femms emitted between MMX and FP instructions

Curse Intel and their modal register sets. Today I caught the x86-64 compiler using %mm0 just because the datatype it wanted to move fit nicely in that register. Except that after an MMX register is touched, one must leave MMX mode before (1) the nest FPU instruction or (2) at a call boundary, si

[Bug libfortran/19155] blanks not treated as zeros in 'E' format read

--- Additional Comments From sgk at troutmask dot apl dot washington dot edu 2004-12-26 19:45 --- Looks like you've found a bug in g77, and if you're reduction of NIST's 110 test is correct, then NIST also has the same bug. Here follows my digging into this problem. >From the Fortran

[Bug c/19160] New: error when building gcc-3.3.5 for target avr

when I compile gcc 3.3.5 for target 'avr' i get the following error: libgcc2.c:731: error: insn does not satisfy its constraints: FULL LISTING: make[2]: Entering directory `/root/avr/gcc-3.3.5/gcc' for d in libgcc avr3 libgcc/avr3 avr4 libgcc/avr4 avr5 libgcc/avr5; do \ if [ -d $d ];

[Bug c++/19159] [4.0 Regression] Undefined symbol: vtable for __cxxabiv1::__vmi_class_type_info

-- What|Removed |Added Keywords||wrong-code Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=

[Bug tree-optimization/17949] [4.0 Regression] Tree loop optimization generates unaligned access (STRICT_ALIGNMENT is set)

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-26 17:17 --- This also effects hppa*-*-*. -- What|Removed |Added GCC target triplet|ia64-*-*, sparc*-*-*,

[Bug tree-optimization/17949] [4.0 Regression] Tree loop optimization generates unaligned access (STRICT_ALIGNMENT is set)

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-26 17:16 --- *** Bug 19083 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug middle-end/19083] [4.0 Regression] FAIL: gcc.c-torture/execute/strct-pack-3.c execution, -O1

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-26 17:16 --- This is a dup of bug 17949. *** This bug has been marked as a duplicate of 17949 *** -- What|Removed |Added -

[Bug middle-end/19083] [4.0 Regression] FAIL: gcc.c-torture/execute/strct-pack-3.c execution, -O1

--- Additional Comments From danglin at gcc dot gnu dot org 2004-12-26 17:03 --- This test fails on all hppa-hpux targets. -- What|Removed |Added GCC build triplet|hppa2.0

[Bug c++/19159] New: [4.0 Regression] Undefined symbol: vtable for __cxxabiv1::__vmi_class_type_info

This PR is a followup to as it didn't fix all the problems arising from the reworking of import_export_decl on systems without weak support. Here is a summary of the types of fails that I see in the g++ and libstdc++ testsuites that I believe a

[Bug preprocessor/18875] [4.0 Regression] Cannot build libcpp due to -Wno-long-long flag

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-26 15:37 --- This works for me, you had to have changed compilers between configuring and building. -- What|Removed |Added ---

[Bug tree-optimization/19158] [4.0 Regression] GNAT Bug Box compiling makegpr.adb of the GNAT tools

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-26 15:19 --- Patch here: . Mine. -- What|Removed |Added

[Bug ada/19158] New: GNAT Bug Box compiling makegpr.adb of the GNAT tools

BUG DETECTED==+ | 4.0.0 20041226 (experimental) (powerpc-apple-darwin7.7.0) GCC error: | | tree check: expected ssa_name, have var_decl in verify_ssa, at | |tree-ssa.c:645| | Error detected at

[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-26 15:06 --- This will happen with any "DO LABEL VAR=START,END" loop in fortran. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19038

[Bug tree-optimization/18048] [4.0 Regression] mgrid loop performance regression with ivopts

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-26 14:58 --- (In reply to comment #6) > PR 19038 shows up here also but not introduced by ivopts related. Though IV-OPTS helps fixing some of these. -- What|Removed |Added ---

[Bug tree-optimization/18048] [4.0 Regression] mgrid loop performance regression with ivopts

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-26 14:50 --- PR 19038 shows up here also but not introduced by ivopts related. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18048

[Bug target/19157] Wrong path search order for avr-gcc when -B is given

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-26 14:11 --- This is caused by the way you configured gcc: --with-as=/usr/avr/bin/as that will search that first. -- What|Removed |Added

[Bug c/19157] New: Wrong path search order for avr-gcc when -B is given

I'm forwrading a bugrepport from "Klaus S. Madsen" <[EMAIL PROTECTED]> reported to the debiag bugtracking system. I've verified that the problem is still in version 3.4.3: When using avr-gcc to compile for TinyOS (a operating-system for embedded devices), the nesc-compiler (used to compile TinyOS

[Bug c++/19156] cpp to c conversion

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-26 13:52 --- Not going to happen at least any time soon. Also since C++ started this way but not the GCC front- end though. -- What|Removed |Added --

[Bug c++/19156] New: cpp to c conversion

please implement a c++->c conversion (like the c++->asm conversion) thanks -- Summary: cpp to c conversion Product: gcc Version: 3.3.2 Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: c++ AssignedT

[Bug bootstrap/17383] [4.0 Regression] Building in src dir fails

--- Additional Comments From paolo dot bonzini at lu dot unisi dot ch 2004-12-26 11:00 --- Subject: Re: [4.0 Regression] Building in src dir fails aoliva at gcc dot gnu dot org wrote: > --- Additional Comments From aoliva at gcc dot gnu dot org 2004-12-23 > 21:03 --- > Paolo'