[Bug c/18978] [3.4 Regression] Segfault after a warning about 'struct sigaction'

--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-17 07:46 --- This is invalid code after all. -- What|Removed |Added Keywords|ice-on-valid-co

[Bug target/18371] [3.4/4.0 Regression] array subscript out of range

--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-17 07:32 --- Jan, the problem was introduced with this patch: http://gcc.gnu.org/ml/gcc-cvs/2003-10/msg01212.html Would you mind fixing as soon as possible? Thanks in advance. -- What|Removed

[Bug target/18371] [3.4/4.0 Regression] array subscript out of range

--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-17 07:30 --- This can't reasonably remain unfixed. -- What|Removed |Added Severity|normal

[Bug rtl-optimization/19038] Loop header copying

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 04:28 --- Could someone see if the patch attached to PR 19049 fixes the bug, I am going to submit it anyways since it helps so much fortran code in general and we can vectorize some more loops. -- http://gcc.gn

[Bug tree-optimization/19049] not vectorizing fortran loops because not moving user lables on the tree level

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 04:27 --- Created an attachment (id=7768) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7768&action=view) patch which fixes the non vectorizor problem This patch fixes the merging of the BB and the vectorizer c

Re: GCC C bug: sizeof a union of structs returns zero value

On Thu, 16 Dec 2004, Hugh Daniel wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Note, I gave up on GNATS after repeatedly getting this error message no matter what I did to the text: """ You have not described how to repeat the bug You have not defined a category for the bug """ If there i

[Bug rtl-optimization/19038] Loop header copying

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 04:16 --- I think the problem is the BBs are not being merged if the secondary BB has a user label. If that is so, what we should do is merge the BB and just move the labels. I will try to this and attach the patc

[Bug tree-optimization/19049] not vectorizing fortran loops because not moving user lables on the tree level

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 04:15 --- The problem is that tree_can_merge_blocks_p returns false as BB a has a user label, what should happen instead is just move the user label. -- What|Removed |Added -

[Bug tree-optimization/19049] not vectorizing fortran loops

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 04:05 --- If anyone wants the full benchmark I can attach it or sent it to them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19049

[Bug rtl-optimization/19038] Loop header copying

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 04:05 --- (In reply to comment #3) > If anyone wants the full benchmark I can attach it or sent it to them. That was not for this bug, woops. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19038

[Bug rtl-optimization/19038] Loop header copying

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 04:04 --- If anyone wants the full benchmark I can attach it or sent it to them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19038

[Bug tree-optimization/19049] New: not vectorizing fortran loops

>From a benchmark which deals with vectorizing loops, I noticed that all of the >loops were not being vectorized because we don't merge two BBs together. subroutine s111 (ntimes,ld,n,ctime,dtime,a,b,c,d,e,aa,bb,cc) c c linear dependence testing c no dependence - vectorizable c

GCC C bug: sizeof a union of structs returns zero value

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Note, I gave up on GNATS after repeatedly getting this error message no matter what I did to the text: """ You have not described how to repeat the bug You have not defined a category for the bug """ If there is a maintainer of the <[EMAIL PROTEC

[Bug middle-end/18999] gimplify_init_ctor_eval does not support RANGE_EXPRs

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 02:24 --- Patch posted here: . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18999

[Bug middle-end/16417] [4.0 Regression] crappy code (gcc.c-torture/compile/20020210-1.c) in arguments causes ICE

--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2004-12-17 01:54 --- Subject: Re: [4.0 Regression] crappy code (gcc.c-tortur > On hppa64-hp-hpux11.11, we don't get as far: > > /test/gnu/gcc-3.3/objdir/gcc/gfortran -B/test/gnu/gcc-3.3/objdir/gcc/ > -B/opt/gnu > 64/

[Bug middle-end/18191] [4.0 Regression] Struct member is not getting default-initialized

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 01:35 --- (In reply to comment #15) > The new4.C failure is, in fact, PR18999. I added a patch to PR18999 which implements the loop version for handling RANGE_EXPR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?i

[Bug middle-end/18999] gimplify_init_ctor_eval does not support RANGE_EXPRs

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 01:34 --- Created an attachment (id=7766) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7766&action=view) Patch which I am testing This is the full patch which also handles SAVE_EXPRs. -- What|

[Bug preprocessor/19040] #elif token1 token2 doesn't produce a diagnostic

--- Additional Comments From joseph at codesourcery dot com 2004-12-17 01:29 --- Subject: Re: #elif token1 token2 doesn't produce a diagnostic On Thu, 16 Dec 2004, dpatel at apple dot com wrote: > On Dec 16, 2004, at 1:01 PM, bangerth at dealii dot org wrote: > > > That's because it

[Bug libfortran/19032] modulo generates wrong result for divisor -1

--- Additional Comments From tobi at gcc dot gnu dot org 2004-12-17 01:18 --- A patch for integers is here: http://gcc.gnu.org/ml/fortran/2004-12/msg00171.html I had guessed so Thomas, but I hoped that someone else would complete the fix :-) -- What|Removed

[Bug preprocessor/19040] #elif token1 token2 doesn't produce a diagnostic

--- Additional Comments From dpatel at apple dot com 2004-12-17 01:04 --- Subject: Re: #elif token1 token2 doesn't produce a diagnostic Never mind, someone led me to believe that this is a Plum Hall test failure. It is not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19040

[Bug c++/19047] [3.3/3.4 Regression] Template template argument matching can violate SFINAE

--- Additional Comments From bangerth at dealii dot org 2004-12-17 00:12 --- This is a duplicate of one of the weirdest bugs we have ever had, PR 17344. W. *** This bug has been marked as a duplicate of 17344 *** -- What|Removed |Added

[Bug target/19041] [4.0 Regression] -fvisibility=hidden causes bad codegen for common symbols

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-17 00:25 --- Subject: Bug 19041 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-17 00:25:17 Modified files: gcc: ChangeLog gcc/config : d

[Bug target/19041] [4.0 Regression] -fvisibility=hidden causes bad codegen for common symbols

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 00:24 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED

[Bug c++/17344] completely wacky error with matching template template classes and default arguments

--- Additional Comments From bangerth at dealii dot org 2004-12-17 00:12 --- *** Bug 19047 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug ada/19035] Put constants read-only on ELF platforms

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 00:13 --- Confirmed, also happens on ppc-darwin. -- What|Removed |Added Status|UNCONFIRMED

[Bug target/19029] [4.0 Regression] ICE: unrecognizable insn:

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17 00:08 --- I think this is a dup of bug 18910 but I have not reduced this testcase fully but I looked into the source to see that it was the orginal testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19029

[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-16 23:54 --- I hacked up gimplify_init_ctor_eval to do this for PR18191. The code is gross, but if it works, you can give it a closer look ;-) -- What|Removed |Added -

[Bug libgcj/19036] readObject memory consumption

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 23:55 --- This works for me on the todays mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19036

[Bug middle-end/18999] gimplify_init_ctor_eval does not support RANGE_EXPRs

-- What|Removed |Added OtherBugsDependingO||18191 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18999

[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-16 23:52 --- The new4.C failure is, in fact, PR18999. -- What|Removed |Added BugsThisDependsOn|

[Bug ada/19037] constant renaming creates new constant

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 23:48 --- Confirmed, note for the procedure case, we put the const decl on the stack (at least on ppc-darwin). -- What|Removed |Added -

[Bug target/19019] GCC ldouble format incompatibility with XLC long double

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 23:41 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW E

[Bug c++/19043] [3.4/3.3 only] -fpermissive gives bad loop initializations

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 23:41 --- 3.3.2 does not work but the mainline works. -- What|Removed |Added Keywords|

[Bug fortran/19045] ICE in gfc_conv_expr

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 23:32 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW E

[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-16 23:35 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW E

[Bug c++/19047] [3.3/3.4 Regression] Template template argument matching can violate SFINAE

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 23:28 --- Fixed on the mainline: : Search converges between 2004-11-14-014001-trunk (#634) and 2004-11-14-161001-trunk (#635). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19047

[Bug c++/19047] [3.3/3.4 Regression] Template template argument matching can violate SFINAE

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 23:28 --- Reduced testcase: template struct char_traits {}; template > class basic_ostream {}; template basic_ostream& operator<<(basic_ostream& __out, const char* __s); extern basic_ostream cout; template c

[Bug ada/19048] Assertion failure on illegal program

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 23:29 --- Confirmed on the mainline: +===GNAT BUG DETECTED==+ | 4.0.0 20041208 (experimental) (powerpc-apple-darwin7.6.0) Assert_Failure sinfo.adb:1082| | Error de

[Bug ada/19048] New: Assertion failure on illegal program

The following code will make gcc abort: package foo is A : constant Integer := 1; B : Integer renames A; B : constant Integer := 2; end foo; $ gcc -c foo.ads +===GNAT BUG DETECTED==+ | 3.4.4 20041128 (prerelease) (Debian 3.4.3-3) (i486

[Bug tree-optimization/19042] Complex types are not SRA all the time.

-- What|Removed |Added CC||dje at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19042

[Bug preprocessor/9449] UCNs not recognized in identifiers (c++/c99)

--- Additional Comments From joseph at codesourcery dot com 2004-12-16 23:04 --- Subject: Re: UCNs not recognized in identifiers (c++/c99) The following example illustrates the problems with lack of normalisation. (I still expect WG14 and WG21 to consider the lack of normalisation t

[Bug c++/19047] Template template argument matching can violate SFINAE

-- What|Removed |Added Known to work|2.95.4 |2.95.4 4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19047

[Bug c++/19047] Template template argument matching can violate SFINAE

-- What|Removed |Added GCC build triplet||i486-linux GCC host triplet||i486-linux GCC target triplet|

[Bug target/19046] [4.0 Regression] MOVE_RATIO should be tweaked

-- What|Removed |Added CC||dje at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19046

[Bug target/19046] [4.0 Regression] MOVE_RATIO should be tweaked

--- Additional Comments From dje at gcc dot gnu dot org 2004-12-16 22:58 --- I think it needs some experimentation to determine the best performance trade off. I do not expect a value of 15 to be correct. I would guess at something like #define MOVE_RATIO (TARGET_STRING ? 2 : optimi

[Bug rtl-optimization/19038] Loop header copying

--- Additional Comments From steven at gcc dot gnu dot org 2004-12-16 22:55 --- The interesting thing is that the front end already does the header "copying" when it generates code: { int4 D.1164;

[Bug preprocessor/19040] #elif token1 token2 doesn't produce a diagnostic

--- Additional Comments From dpatel at apple dot com 2004-12-16 22:54 --- Subject: Re: #elif token1 token2 doesn't produce a diagnostic Neil, Would it be possible to quote standard here? We encountered this while running Plum Hall tests, so I just wanted to make sure. Thank you. -

[Bug c++/19047] New: Template template argument matching can violate SFINAE

The following program fails to compile: #include template class CT, int TA> void operator<<(CT, int); int main() { std::cout << "Hello, world\n"; } The error messages given are: test.cpp: In function `int main()': test.cpp:8: error: template argument 2 is invalid -- Summary: Te

[Bug preprocessor/19040] #elif token1 token2 doesn't produce a diagnostic

--- Additional Comments From neil at gcc dot gnu dot org 2004-12-16 22:38 --- Not a bug - the standard requires this. -- What|Removed |Added Status|NEW

[Bug libfortran/19032] modulo generates wrong result for divisor -1

--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-16 22:40 --- Reals are also broken: $ cat mod-real.f90 program main real :: a,b a = 2.0 b = -1.0 print *,modulo(a,b) end program main $ gfortran mod-real.f90 $ ./a.out -1.00 -- http://gcc.gnu.org/b

[Bug target/19046] [4.0 Regression] MOVE_RATIO should be tweaked

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

[Bug target/19046] New: [4.0 Regression] MOVE_RATIO should be tweaked

Take the following C++ code: class StringMap { const char empty_str[8]; public: StringMap() : empty_str() {} }; StringMap f() { StringMap a; return a; } For 3.3.2, we produced (at -O3): __Z1fv: LFB6: li r4,0 stw r4,0(r3) stw r4,4(r3) blr on the mainline we g

[Bug tree-optimization/18268] structure copy propagation not done

--- Additional Comments From rth at gcc dot gnu dot org 2004-12-16 22:07 --- SRA shouldn't be responsible for this. There should be a generalized block copy propagator. Which would help with copies far larger than you'd ever expect SRA to handle as well. -- What|Remove

[Bug fortran/19045] New: ICE in gfc_conv_expr

I think this is different than the existing Fortran failures. If '(ims:,jms:)'is changed to '(ims,jms)' or '(ims:ime,jms:jme)' things work. Test case: SUBROUTINE foo ( dnew , ims, jms, ime, jme) IMPLICIT NONE INTEGER ims, jms, ime, jme REAL , DIMENSION(ims:,jms:) :: dnew INTEGER

[Bug rtl-optimization/19038] Loop header copying

--- Additional Comments From dje at gcc dot gnu dot org 2004-12-16 21:39 --- The focus of the problem is the inner loop of functio thin6d at line 572. The function consumes 97.5% of the cycles and the inner loop consumes 48.5%. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19038

[Bug c++/19044] New: Alternate asm name for atan ignored when calling __builtin_atan

For atan (and other functions like it), calling __builtin_atan is sometimes supposed to fall back to the library version of atan. In the C++ front end, this interacts poorly with alternate asm names. Consider the following test case: #ifdef __cplusplus extern "C" #endif double atan(double x) _

[Bug preprocessor/19040] #elif token1 token2 doesn't produce a diagnostic

--- Additional Comments From bangerth at dealii dot org 2004-12-16 21:01 --- That's because it doesn't have to evaluate the #elif condition any more, since it has already taken the #ifdef branch. If you change the code to #ifdef BAR return 1; #elif BAR FOO return

[Bug preprocessor/19040] #elif token1 token2 doesn't produce a diagnostic

--- Additional Comments From dpatel at apple dot com 2004-12-16 21:07 --- Subject: Re: #elif token1 token2 doesn't produce a diagnostic On Dec 16, 2004, at 1:01 PM, bangerth at dealii dot org wrote: > That's because it doesn't have to evaluate the #elif condition any > more, > since

[Bug tree-optimization/19042] Complex types are not SRA all the time.

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 21:03 --- And here is a testcase where we don't use an unitialized variable and no loops either: COMMON TA,A COMPLEX*16 CLAM2

[Bug target/18997] [4.0 Regression] Segmentation Violation in pthread_getspecific

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 20:49 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED

[Bug tree-optimization/19042] Complex types are not SRA all the time.

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 20:49 --- This is most likely a dup of bug 18268. -- What|Removed |Added BugsThisDependsOn|

[Bug tree-optimization/19042] Complex types are not SRA all the time.

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 20:38 --- Here it is further reduced: COMMON TA(6,6) COMPLEX*16 CA2,CLAM2 CA2=DCMPLX(F2,ZERO)

[Bug tree-optimization/19042] Complex types are not SRA all the time.

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 20:40 --- Here it is further reduced: COMMON TA(6,6) COMPLEX*16 CA2,CLAM2 CLAM2=DCMPLX(a,2.0)

[Bug tree-optimization/18501] [4.0 Regression] Missing 'used unintialized' warning

--- Additional Comments From dnovillo at gcc dot gnu dot org 2004-12-16 20:42 --- This is not really fixable. Analysis: http://gcc.gnu.org/ml/gcc/2004-12/msg00681.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501

[Bug tree-optimization/19042] Complex types are not SRA all the time.

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 20:30 --- Here is the reduced testcase (fortran): COMMON TA(6,6) COMPLEX*16 CA1,CA2,CLAM2 CA2=DCMP

[Bug tree-optimization/18707] [4.0 Regression] Performance regression at -O2 with gzip

--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-16 20:04 --- See http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01232.html -- What|Removed |Added

[Bug tree-optimization/18707] [4.0 Regression] Performance regression at -O2 with gzip

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-16 20:01 --- Subject: Bug 18707 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-16 20:01:26 Modified files: gcc: ChangeLog cfgloopmanip.c Log messag

[Bug target/18997] [4.0 Regression] Segmentation Violation in pthread_getspecific

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-16 19:56 --- Subject: Bug 18997 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-16 19:56:12 Modified files: gcc: ChangeLog gcc/config/i386: c

[Bug c++/19043] New: -fpermissive gives bad loop initializations

Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux int main() { //int i; f

[Bug tree-optimization/19042] New: Complex types are not SRA all the time.

I decided to look into sixtrack and noticed this. I will add a small testcase after I reduce the problem. -- Summary: Complex types are not SRA all the time. Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: missed-optimization

[Bug tree-optimization/19042] Complex types are not SRA all the time.

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 19:32 --- Note we end up with: D.770 = COMPLEX_EXPR ; ca1$imag = IMAGPART_EXPR ; ca1$real = REALPART_EXPR ; in .t66.final_cleanup -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19042

[Bug other/18508] [3.4/4.0 Regression] "basename: too few arguments" when building without bootstrap

--- Additional Comments From hjl at lucon dot org 2004-12-16 19:17 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolut

[Bug other/18508] [3.4/4.0 Regression] "basename: too few arguments" when building without bootstrap

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-16 19:14 --- Subject: Bug 18508 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-16 19:14:29 Modified files: gcc: ChangeLog gcc/config : t

[Bug other/18508] [3.4/4.0 Regression] "basename: too few arguments" when building without bootstrap

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-16 19:16 --- Subject: Bug 18508 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2004-12-16 19:16:23 Modified files: gcc: Change

[Bug target/19041] [4.0 Regression] -fvisibility=hidden causes bad codegen for common symbols

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 19:12 --- Patch posted here: , this is a regression from before Mark implemented his speed up. There is also a better testcase which does not use the option b

[Bug target/19041] -fvisibility=hidden causes bad codegen for common symbols

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 19:10 --- Mine, I posted a patch last week, I will find it again and add the link to the bug here. -- What|Removed |Added -

[Bug c/19041] New: -fvisibility=hidden causes bad codegen for common symbols

Compile the following file with -fvisibility=hidden int foo; void bar(void) { foo = 0; } You will find that the assembler rejects the .s file that the compiler creates, giving the error: /var/tmp//cclfEVh7.s:16:non-relocatable subtraction expression, "_foo" minus "L001$pb" /var/tmp//cclf

[Bug c/19039] New: another SSE optimization ICE

Attached testcase ICEs GCC: [opel:/Volumes/sandbox/stuart] hasting2% gcc.fsf.debug.obj/gcc/xgcc -B gcc.fsf.debug.obj/gcc -O1 - msse2 -S m4.i m4.i: In function 'rrr': m4.i:36: error: unrecognizable insn: (insn 283 210 211 10 (set (reg:V16QI 22 xmm1) (const_int 1 [0x1])) -1 (nil) (nil))

[Bug c++/18829] Error signale on an unexisting line

--- Additional Comments From federicotomassetti at yahoo dot it 2004-12-16 18:31 --- No I provided info needed to analyze this bug -- What|Removed |Added Status|

[Bug target/19039] [4.0 Regression] another SSE optimization ICE

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

[Bug target/19029] [4.0 Regression] ICE: unrecognizable insn:

-- What|Removed |Added Keywords||ice-on-valid-code Summary|ICE: unrecognizable insn: |[4.0 Regression] ICE: |

[Bug preprocessor/19040] #elif token1 token2 doesn't produce a diagnostic

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 18:23 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW E

[Bug preprocessor/19040] New: #elif token1 token2 doesn't produce a diagnostic

GCC emits diagnostics for following... $ cat a.c int foo() { #ifdef FOO return 1; #elif BAR FOO return 0; #endif } $ cc a.c -c a.c:6:11: error: missing binary operator before token "FOO" $ However, it does not emit diagnostics for following ... $ cat a.c #define FOO 1 int foo()

[Bug target/17767] [4.0 Regression] MMX intrinsics cause internal compiler error

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

[Bug java/18796] [4.0 Regression] gcj imports wrong superclass

--- Additional Comments From tromey at gcc dot gnu dot org 2004-12-16 18:14 --- Andrew agreed to look at this. -- What|Removed |Added AssignedTo|unassigned at gcc d

[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-16 18:07 --- Someone had a bad day: case ARRAY_TYPE: case VECTOR_TYPE: /* We're already checked the component type (TREE_TYPE), so just check the index type. */ return type_contains_pl

[Bug middle-end/18493] [3.4 Regression] gcc doesn't like switch blocks without case/default labels

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-16 17:52 --- Subject: Bug 18493 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-16 17:52:02 Modified files: gcc/testsuite : ChangeLog Added files: gcc/t

[Bug tree-optimization/18754] unrolling happens too late/SRA does not happen late enough

--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2004-12-16 17:08 --- The attached patch makes us for -O3 -funroll-loops -ffast-math produce in .vars float foobar() () { : return a.array[3] * b.array[3] + a.array[2] * b.array[2] + a.array[0] * b.array[0]

[Bug c++/19030] [4.0 Regression] ice on tree check

--- Additional Comments From bangerth at dealii dot org 2004-12-16 17:01 --- Created an attachment (id=7762) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7762&action=view) Slightly smaller testcase Attached is a slightly smaller testcase (down to 183,000 lines or so). The bug may

[Bug middle-end/15114] [3.4 regression] -funit-at-a-time causes compilation of functions with variable length arrays to fail

--- Additional Comments From bangerth at dealii dot org 2004-12-16 16:50 --- *** Bug 19033 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug c/19033] Passing array as a function parameter in C99 style fails

--- Additional Comments From bangerth at dealii dot org 2004-12-16 16:50 --- This is a duplicate of PR 15114. It is fixed on mainline, but the audit trail of that PR states that it is not going to be fixed for 3.4.x. W. *** This bug has been marked as a duplicate of 15114 *** --

[Bug c++/19030] [4.0 Regression] ice on tree check

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 16:45 --- This is at least a 4.0 regression, as (with --disable-checking) on the mainline we ICE but don't with 3.3.2. -- What|Removed |Added

[Bug c++/19030] ice on tree check

--- Additional Comments From bangerth at dealii dot org 2004-12-16 16:40 --- I can confirm this. We get a million error messages before the place where we crash, though. And the testcase has some 247,000 lines... W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19030

[Bug target/17603] [4.0 Regression] cpowf and cpowl give wrong results

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 16:33 --- Patch here: . -- What|Removed |Added

[Bug c/19031] [4.0 Regression] #pragma weak handling changes in 4.0.0

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 16:31 --- Well the following patch changed it: 2004-11-29 Daniel Jacobowitz <[EMAIL PROTECTED]> PR c/7544 * Makefile.in (c-lang.o): Update dependencies. * c-lang.c: Include "c-pragma.h".

[Bug libgcj/19036] readObject memory consumption

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 16:27 --- Note This version is almost 3 months old. -- What|Removed |Added Component|java

[Bug middle-end/18493] [3.4 Regression] gcc doesn't like switch blocks without case/default labels

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 16:25 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED

[Bug c++/14075] ("foo") accepted as char[] initializer

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

[Bug fortran/18977] LAPACK test xeigtsts segfaults with optimization

--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-16 15:59 --- I reran the tests with the 20041114 snapshot at -O1, and the segfault did indeed go away, so this is a regression. Quite likely, this is a IA-64 target problem. -- http://gcc.gnu.org/bugzilla/show_

[Bug target/17603] [4.0 Regression] cpowf and cpowl give wrong results

--- Additional Comments From jbeulich at novell dot com 2004-12-16 15:46 --- Patch for the x86-64 long double complex part submitted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17603

  1   2   >