[Bug c++/20157] [4.0/4.1 Regression] Internal compiler error on invalid code

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-14 03:54 --- Subject: Bug 20157 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-14 03:54:21 Modified files: gcc/cp : ChangeLog pt.c gcc/testsuite

[Bug middle-end/19331] [4.0 Regression] Inefficient code generated for bitfield assignment

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-14 03:58 --- Fixed. Thanks Roger for looking into this bug and fixing it. -- What|Removed |Added

[Bug middle-end/19466] [meta-bug] bit-fields are non optimal

-- Bug 19466 depends on bug 19331, which changed state. Bug 19331 Summary: [4.0 Regression] Inefficient code generated for bitfield assignment http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19331 What|Old Value |New Value -

[Bug c++/20157] [4.0/4.1 Regression] Internal compiler error on invalid code

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-14 03:59 --- Subject: Bug 20157 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-03-14 03:58:55 Modified files: gcc/cp : Change

[Bug c++/20157] [4.0/4.1 Regression] Internal compiler error on invalid code

--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-03-14 04:02 --- Fixed in 4.0. -- What|Removed |Added Status|ASSIGNED|RESOLV

[Bug rtl-optimization/20466] Missed invalidation of known memory contents in flow2...

--- Additional Comments From hp at gcc dot gnu dot org 2005-03-14 04:28 --- In response to comment #1, I have no answer besides what I wrote in the original description: "This bug has been there since at least 3.2.1". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20466

[Bug fortran/20467] New: Bad fortran code causes ICE

Im no fortran coder but Im pretty sure this isnt valid: SUBROUTINE a(b) b(c) = 0 END SUBROUTINE a Using todays cvs: GNU Fortran 95 (GCC 4.0.0 20050313 (prerelease)) We ICE: /usr/local/ppc64-4.0/libexec/gcc/powerpc64-linux/4.0.0/f951 f.f90 -quiet -dumpbase f.f90 -m64 -auxbase f

[Bug fortran/20467] Bad fortran code causes ICE

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-14 04:38 --- Confirmed, g77 gives the following error: t.f: In subroutine `a': t.f:1: SUBROUTINE a(b) 1 t.f:2: (continued): b(c) = 0 2 Invalid declaration of or reference to symb

[Bug fortran/20467] Bad fortran code causes ICE

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-14 04:39 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW E

[Bug inline-asm/20468] New: LABEL already defined in inline-asm

Hi, gcc fails to compile the following (on Suse 8.2): /usr/local/bin/gcc -O9 -v -save-temps -I. -c -o jdapimin.o jdapimin.c Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/specs Configured with: /home/ltg/software/src/work/gcc-3.4.3/configure --enable-threads=posix --enable-libgc

[Bug inline-asm/20468] LABEL already defined in inline-asm

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-14 05:51 --- This is invalid, as mmxsupport gets inlined into jpeg_CreateDecompress creating the label NOT_SUPPORTED twice. Either use noinline on that function or use the correct way of creating a label in inline-a

[Bug fortran/20460] Nasty extensions that should always warn

--- Additional Comments From kargl at gcc dot gnu dot org 2005-03-14 06:34 --- While I can agree that REAL DO loop indices should cause a warning, it is incorrect to call this feature an extension to the language. Fortran 77 permitted such indices. Fortran 90 declared them to be obsole

<    1   2