[Bug debug/19345] New: [4.0 Regression] Segmentation fault

inline void bar (char a[], unsigned int l) { asm volatile ("" :: "m" ( *(struct {char x[l];} *) a)); } void foo (void) { bar (0, 0); } -- Summary: [4.0 Regression] Segmentation fault Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywor

[Bug tree-optimization/19224] [4.0 regression] Endless loop compiling simple file: Bug in tree-scalar-evolution.c (instantiate_parameters_1)?

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-09 08:22 --- Subject: Bug 19224 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-09 08:22:15 Modified files: gcc: ChangeLog tree-scalar-evolution.c L

[Bug debug/19345] [4.0 Regression] Segmentation fault

--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-01-09 08:23 --- use '-O1 -g' to reproduce -- What|Removed |Added Known to fail|

[Bug c/19346] New: Wrong warnings about undefined aliases

With current GCC CVS I get lots of warnings when compiling glibc about aliases to undefined symbols: [EMAIL PROTECTED]:~/tmp> /opt/gcc/4.0-devel/bin/gcc -O2 -c test.i test.i:2: warning: ?__libc_errno? aliased to undefined symbol ?errno? [EMAIL PROTECTED]:~/tmp> nm test.o 0004 C e

[Bug c/19342] internal compiler error: in common_type, at c-typeck.c:490

-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC build triplet|* | GCC

[Bug tree-optimization/19347] New: Invariant load not moved out of loop

In mesa benchmark (osmesa.c:678) GLuint i, n, *ptr4; n = osmesa->rowlength * osmesa->height; ptr4 = (GLuint *) osmesa->buffer; for (i=0;iclearpixel; } The load of osmesa->clearpixel is not taken outside the loop by LIM because of aliasing limitati

[Bug c/19342] internal compiler error: in common_type, at c-typeck.c:490

--- Additional Comments From steven at gcc dot gnu dot org 2005-01-09 11:12 --- typedef enum { ORANGE, GRAPE } fruit; struct list { fruit __attribute__ ((mode (__byte__))) elt; fruit __attribute__ ((mode (__byte__))) next_elt; }; void bar (void); void foo (struc

[Bug c/19342] [4.0 regression] ICE in common_type, at c-typeck.c:490

-- What|Removed |Added Severity|normal |critical Keywords||ice-on-valid-code Known to fail|

[Bug fortran/19334] ISHFT has the wrong type for constant values

--- Additional Comments From tobi at gcc dot gnu dot org 2005-01-09 11:56 --- Is the reduced testcase also not fixed by the patch, or is this a new issue? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19334

[Bug fortran/19334] ISHFT has the wrong type for constant values

--- Additional Comments From tobi at gcc dot gnu dot org 2005-01-09 12:29 --- Hm, I've instrumented the tree-dumper to print the widths and signednesses of integer constants, i.e. Index: tree-pretty-print.c === RCS file: /c

[Bug fortran/19334] ISHFT has the wrong type for constant values

--- Additional Comments From tobi at gcc dot gnu dot org 2005-01-09 12:30 --- also, I'm on i686, which could be making a difference even though it shouldn't at this stage. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19334

[Bug target/16322] C99 complex math functions not implemented for irix6.5

--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-09 14:47 --- I think this bug and PR15266 are really about the same thing: getting the configure system to handle the complex libraries on IRIX. Would there be any chance to get one of them resolved as DUPLICATE? --

[Bug libfortran/15266] libgfortran doesn't compile on IRIX 5.3

: /bin/sh ./libtool --mode=compile /var/tmp/gfortran-20050109/ibin/gcc/gfortran -B/var/tmp/gfortran-20050109/ibin/gcc/ -B/var/tmp/gfortran-20050109/irun/mips-sgi-irix6.5/bin/ -B/var/tmp/gfortran-20050109/irun/mips-sgi-irix6.5/lib/ -isystem /var/tmp/gfortran-20050109/irun/mips-sgi-irix6.5/include

[Bug libfortran/15266] libgfortran doesn't compile on IRIX 5.3

--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2005-01-09 15:07 --- Subject: Re: libgfortran doesn't compile on IRIX 5.3 coudert at clipper dot ens dot fr wrote: > /var/tmp/gfortran-20050109/irun/mips-sgi-irix6.5/sys-include

[Bug c++/9737] [DR150] Partial template specialisation selection failure involving template parameter defaults

--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-01-09 15:26 --- I posted a solution for this on comp.std.c++: http://groups.google.co.th/groups?hl=th&lr=&group=comp.std.c%2B%2B&selm=ac0d020c.0501090129.6b1fc0a9%40posting.google.com -- http://gcc.gnu.org/bugzilla/s

[Bug target/18329] [4.0 regression] mmix-knuth-mmixware testsuite failure: execute/920501-7.c

--- Additional Comments From hp at gcc dot gnu dot org 2005-01-09 15:27 --- http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00478.html> -- What|Removed |Added Keyword

[Bug target/18330] [4.0 regression] mmix-knuth-mmixware testsuite failure: execute/comp-goto-2.c

--- Additional Comments From hp at gcc dot gnu dot org 2005-01-09 15:28 --- *** This bug has been marked as a duplicate of 18329 *** -- What|Removed |Added Sta

[Bug target/18329] [4.0 regression] mmix-knuth-mmixware testsuite failure: execute/920501-7.c

--- Additional Comments From hp at gcc dot gnu dot org 2005-01-09 15:28 --- *** Bug 18330 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18329

[Bug fortran/19334] ISHFT has the wrong type for constant values

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-09 15:29 --- int1 C.454 = 0_S8; The 8 is where the problem is, it is just plainly wrong, it should be 1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19334

[Bug c/19342] [4.0 regression] ICE in common_type, at c-typeck.c:490

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-09 15:35 --- The only obvious change which caused this would be: 2005-01-07 Jakub Jelinek <[EMAIL PROTECTED]> * c-common.c (handle_mode_attribute): For ENUMERAL_TYPE, also copy TYPE_MODE. --

[Bug fortran/19334] ISHFT has the wrong type for constant values

--- Additional Comments From Tobias dot Schlueter at physik dot uni-muenchen dot de 2005-01-09 15:36 --- Subject: Re: ISHFT has the wrong type for constant values pinskia at gcc dot gnu dot org wrote: > --- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-09 > 15:2

[Bug target/15491] ICE (Internal compiler error) while compiling glibc to vax-linux target

--- Additional Comments From danglin at gcc dot gnu dot org 2005-01-09 15:45 --- Created an attachment (id=7912) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7912&action=view) Patch For main. Should also apply to 3.4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15491

[Bug debug/19345] [4.0 Regression] Segmentation fault

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-09 15:46 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW E

[Bug target/19334] ISHFT has the wrong type for constant values

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-09 15:47 --- Then this must be a target bug, I will look into it. -- What|Removed |Added Assigned

[Bug c/19346] Wrong warnings about undefined aliases

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-09 15:50 --- Confirmed. -- What|Removed |Added CC||rth at gcc

[Bug tree-optimization/19347] Invariant load not moved out of loop

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-09 15:55 --- Confirmed but add a full testcase here, thanks. Actually I don't think it would require whole program analysis to do this in LIM (or LICM), we just need more information (which might be done on the struct

[Bug tree-optimization/19224] [4.0 regression] Endless loop compiling simple file: Bug in tree-scalar-evolution.c (instantiate_parameters_1)?

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-09 15:56 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED

[Bug target/15491] ICE (Internal compiler error) while compiling glibc to vax-linux target

-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-

[Bug c++/19343] [4.0 Regression] New warnings in libstdc++-v3 since 2004-01-05

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-09 15:58 --- Hmm, is this at -O0 or -O2. If the former then this is a dup of bug 16558. If the later, then I don't know. Please attach the preprocessed source (my last build did not have the warning). --

[Bug middle-end/19327] [4.0 Regression] FAIL: gcc.c-torture/execute/921215-1.c compilation, -O3 -g

--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-09 16:00 --- Reproducible on sparc32, sparc64, x86 and x86-64 with -gstabs: RELOCATION RECORDS FOR [.stab]: OFFSET TYPE VALUE 0014 R_386_32 .text 00e0 R_386_32 foo 0104 R_3

[Bug ada/19337] [4.0 Regression] ada does not compile

--- Additional Comments From heitkamp at ameritech dot net 2005-01-09 16:04 --- Subject: Re: [4.0 Regression] ada does not compile On Sat, 8 Jan 2005, pinskia at gcc dot gnu dot org wrote: Which file are you refering to? How do I check this? I am a novice. Thanks. Fred > > ---

[Bug tree-optimization/19241] [4.0 Regression] ICE in make_decl_rtl with inliner

--- Additional Comments From hubicka at ucw dot cz 2005-01-09 16:06 --- Subject: Re: [4.0 Regression] ICE in make_decl_rtl with inliner > > --- Additional Comments From aj at gcc dot gnu dot org 2005-01-09 07:29 > --- > Honza, this is an inliner bug - could you look at it, pl

[Bug ada/19337] [4.0 Regression] ada does not compile

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-09 16:06 --- (In reply to comment #5) > Subject: Re: [4.0 Regression] ada does not compile > > On Sat, 8 Jan 2005, pinskia at gcc dot gnu dot org wrote: > > Which file are you refering to? How do I check this? I am a

[Bug target/15491] ICE (Internal compiler error) while compiling glibc to vax-linux target

--- Additional Comments From danglin at gcc dot gnu dot org 2005-01-09 16:08 --- Could you test this change? I've done a full bootstrap with an x86 cross to vax-ultrix but this doesn't provide a full test. The ICE was introduced in the 3.4 branch when the macro RTX_COSTS was removed.

[Bug tree-optimization/19241] [4.0 Regression] ICE in make_decl_rtl with inliner

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-09 16:08 --- (In reply to comment #29) > Subject: Re: [4.0 Regression] ICE in make_decl_rtl with inliner > I did already once, but it really seem to be template instanciation > problem. I will try harder... In the sma

[Bug ada/19337] [4.0 Regression] ada does not compile

--- Additional Comments From heitkamp at ameritech dot net 2005-01-09 16:09 --- Subject: Re: [4.0 Regression] ada does not compile On Sat, 8 Jan 2005, laurent at guerby dot net wrote: I would be glad to provide any other information that you may need to reproduce the bug or give more

[Bug tree-optimization/19241] [4.0 Regression] ICE in make_decl_rtl with inliner

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-09 16:20 --- I think this was caused by: 2004-08-07 Jason Merrill <[EMAIL PROTECTED]> Make return in memory explicit. * function.c (aggregate_value_p): Check DECL_BY_REFERENCE. (assign_parm_fin

[Bug tree-optimization/18403] FAILs to vectorize testcases on ppc64-linux

--- Additional Comments From dorit at il dot ibm dot com 2005-01-09 16:35 --- vect-[46,50,52,58,60] don't fail anymore, and vect-[77,78] xfail on vectorizing for lp62 targets, so I think we can classify this PR as missed-optimization only, or close it and open a new (missed-optimizatio

[Bug target/14436] [3.3/3.4 regression] ICE building libgcc.a

--- Additional Comments From joel at gcc dot gnu dot org 2005-01-09 16:37 --- (In reply to comment #9) > Fixed on the mainline. Could this fix be applied to the 3.4 branch? -- What|Removed |Added -

[Bug c++/19343] [4.0 Regression] New warnings in libstdc++-v3 since 2004-01-05

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-09 16:46 --- But I do get it on my daily builds on i686-openbsd3.1 starting on the 7th. I will try to reduce this later today once I finish some homework and get some food. -- http://gcc.gnu.org/bugzilla/show_bug.cg

[Bug target/19334] ISHFT has the wrong type for constant values

--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-09 16:50 --- Reduced case (from FP19335) still fails on powerpc-darwin with Tobias' patch. The output from gfortran -fdump-tree-gimple (I hope this was the right thing to do) is the same with and without -fmerge-const

[Bug rtl-optimization/19348] New: internal consistency error while compiling linux kernel

(guessing at component) While compiling the attached file from the linux 2.6 kernel with -march=i686 -fno-unit-at-a-time -m32 -Os I get: -a-time -S -m32 -Os acct-full.i /home/lsrc/v2.6/quilt/linux/kernel/acct.c: In function `encode_float': /home/lsrc/v2.6/quilt/linux/kernel/acct.c:366: fatal e

[Bug rtl-optimization/19348] internal consistency error while compiling linux kernel

--- Additional Comments From ak at muc dot de 2005-01-09 17:41 --- Created an attachment (id=7913) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7913&action=view) Preprocessed acct.c file from linux 2.6 kernel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19348

[Bug rtl-optimization/19348] internal consistency error while compiling linux kernel

--- Additional Comments From aj at gcc dot gnu dot org 2005-01-09 17:57 --- This might be a duplicate of PR19084. -- What|Removed |Added CC|

[Bug ada/19337] [4.0 Regression] ada does not compile

--- Additional Comments From aj at gcc dot gnu dot org 2005-01-09 18:00 --- Btw. this crashes in the same place as in PR 19241. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19337

[Bug ada/19337] [4.0 Regression] ada does not compile

DETECTED==+ | 4.0.0 20050109 (experimental) (i686-pc-linux-gnu) GCC error: | | in make_decl_rtl, at varasm.c:867 | | Error detected at ali.adb:2098:1 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html. | | Include the entire contents of this bug box in the

[Bug ada/19337] [4.0 Regression] ada does not compile

--- Additional Comments From laurent at guerby dot net 2005-01-09 18:22 --- Could you paste the 10 last compile lines of your log? We cannot say wether it's stage2, 3 or part of gnattools that is failing from your report. Please also give your complete configure line, and the list of al

[Bug rtl-optimization/19348] [4.0 Regression] internal consistency error while compiling linux kernel

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-09 18:45 --- Confirmed. : Search converges between 2004-09-12-trunk (#538) and 2004-09-14-trunk (#539). Reduced testcase: unsigned int encode_float(unsigned long long value) { unsigned u; if (value==0) return 0; u =

[Bug c/19346] [4.0 Regression] Wrong warnings about undefined aliases

--- Additional Comments From rth at gcc dot gnu dot org 2005-01-09 18:46 --- I hadn't realized aliases to COMMON symbols ever worked... -- What|Removed |Added Assign

[Bug rtl-optimization/19348] [4.0 Regression] internal consistency error while compiling linux kernel

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-09 18:49 --- (In reply to comment #2) > This might be a duplicate of PR19084. I don't think it is but it is related. This one can be reproduced with a native 32bit compiler while PR 19084 I cannot. -- http://gcc.gnu

[Bug c/19346] [4.0 Regression] Wrong warnings about undefined aliases

--- Additional Comments From rth at gcc dot gnu dot org 2005-01-09 18:49 --- Indeed, they DO NOT work, and never have. The warning is correct. -- What|Removed |Added

[Bug middle-end/19084] [4.0 Regression] ICE: internal consistency failure

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-09 18:53 --- Confirmed, I don't know if this is a regression or not but I am going to assume so as I could not reproduce this before. Reduced testcase: unsigned long long __lcong48_r (unsigned short param) { return (

[Bug target/19075] [4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.dg/tree-ssa/loop-4.c arr_base

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-09 18:56 --- Confirmed, this is not a missed-optimization after all. Patch here to fix the testcase: . -- What|Removed |Added

[Bug libgcj/17069] InetAddress.getLocalHost() returns broken InetAddress object if hostname not set

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-09 18:57 --- Subject: Bug 17069 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-09 18:57:33 Modified files: libjava: ChangeLog libjava/java/net:

[Bug other/19075] [4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.dg/tree-ssa/loop-4.c arr_base

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-09 18:58 --- The only regression here is the testsuite failure. -- What|Removed |Added Component

[Bug other/19075] [4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.dg/tree-ssa/loop-4.c arr_base

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-09 18:59 --- And that patch was committed so this is fixed. -- What|Removed |Added Status|NEW

[Bug libgcj/17069] InetAddress.getLocalHost() returns broken InetAddress object if hostname not set

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-09 18:59 --- Fixed on the mainline (aka for 4.0.0). -- What|Removed |Added Status|ASSIGNED

[Bug ada/18817] ACATS c380004 fails at run time

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-09 19:01 --- Confirmed, via the testsuite run and moving to minor as this is a off in left field case. -- What|Removed |Added

[Bug libgcj/15560] SimpleTimeZone doesn't handle on-or-before/after at ends of month

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-09 19:06 --- Patch here: . -- What|Removed |Added ---

[Bug target/19334] darwin backend places some CONST_DECLs in the wrong section

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-09 19:21 --- Here is a reduced testcase now without ISHFT: call c_i1(0_1) end -- What|Removed |Added

[Bug rtl-optimization/18853] [4.0 Regression] ICE: genautomata.c:5238, error: verify_flow_info: Incorrect fallthru

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-09 19:25 --- This works on the 3.4 branch so it is a regression from there. -- What|Removed |Added

[Bug target/19334] darwin backend places some CONST_DECLs in the wrong section

--- Additional Comments From tobi at gcc dot gnu dot org 2005-01-09 19:28 --- (In reply to comment #12) > The output from gfortran -fdump-tree-gimple (I hope this was the right thing > to > do) -fdump-tree-original gives you the output of the frontend, so if the frontend produces crap,

[Bug target/19334] darwin backend places some CONST_DECLs in the wrong section

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-09 19:31 --- (In reply to comment #14) > (In reply to comment #12) > > The output from gfortran -fdump-tree-gimple (I hope this was the right > > thing to > > do) > > -fdump-tree-original gives you the output of the fr

[Bug target/13891] [3.4/4.0 Regression] support for openbsd 3.4 nonexistent

-- What|Removed |Added Severity|enhancement |minor Summary|support for openbsd 3.4 |[3.4/4.0 Regression] support |nonexist

[Bug target/19334] darwin backend places some CONST_DECLs in the wrong section

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-09 20:07 --- Patch here: . -- What|Removed |Added

[Bug c++/19349] New: Valgrind errors compiling libjava c++ sources

When configuring with --enable-checking=assert,misc,tree,gc,rtlflag,valgrind compilation of some c++ source files in the libjava directory give the following invalid reads: /home/mark/src/gcc-obj/gcc/xgcc -shared-libgcc -B/home/mark/src/gcc-obj/gcc/ -nostdinc++ -L/home/mark/src/gcc-obj/i686-pc-

[Bug target/19350] New: Compilation with -O1 -ftree-vectorize gives unrecognizable insn on x86.

Following test code -- test.c --- typedef struct { int x; int y[16]; } ta; typedef struct { int y[16]; } tb; void f (tb *b) { int i, j; ta *a; for (i=0, j=a->x; iy[i] = a->y[i]; } - when compiled with ---

[Bug target/19350] Compilation with -O1 -ftree-vectorize gives unrecognizable insn on x86.

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-09 21:26 --- I get a different error with today's compiler but that is because I am not compiling with --disable- checking. t.c:7: internal compiler error: in simplify_binary_operation, at simplify-rtx.c:2178 WTF: (se

[Bug other/18720] collect2 uses wrong search order if -brtl specified

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-09 22:02 --- Subject: Bug 18720 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-09 22:01:49 Modified files: gcc: ChangeLog collect2.c Log message:

[Bug tree-optimization/17133] [4.0 Regression] wrong code with -ftree-lim

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-09 22:05 --- Subject: Bug 17133 CVSROOT:/cvs/gcc Module name:gcc Branch: apple-ppc-branch Changes by: [EMAIL PROTECTED] 2005-01-09 22:05:17 Modified files: gcc: tree

[Bug tree-optimization/18519] [4.0 Regression] ICE: Segmentation fault with optimization

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-09 22:05 --- Subject: Bug 18519 CVSROOT:/cvs/gcc Module name:gcc Branch: apple-ppc-branch Changes by: [EMAIL PROTECTED] 2005-01-09 22:05:17 Modified files: gcc: tree

[Bug c++/19351] New: operator new[] can return heap blocks which are too small

operator new[] sometimes returns pointers to heap blocks which are too small. When a new array is allocated, the C++ run-time has to calculate its size. The product may exceed the maximum value which can be stored in a machine register. This error is ignored, and the truncated value is used for

[Bug tree-optimization/19333] [4.0 Regression] Compilation SEGFAULTs with -O1 -finline-functions on the x86_64 architecture.

-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW

[Bug c++/19351] operator new[] can return heap blocks which are too small

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-09 22:25 --- This is undefined behavor. Really there is nothing we can do, just think about this again, the programmer should catch this when they read in the length. -- What|Removed

[Bug c++/19351] operator new[] can return heap blocks which are too small

--- Additional Comments From fw at deneb dot enyo dot de 2005-01-09 22:35 --- Why is this undefined behavior? Would you quote chapter and verse, please? GCC's behavior violates 5.3.4(10): "A new-expression passes the amount of space requested to the allocation function as the first ar

[Bug c++/19351] operator new[] can return heap blocks which are too small

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-09 22:45 --- But the C++ standard does not say anything about this case. -- What|Removed |Added

[Bug c++/19351] operator new[] can return heap blocks which are too small

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-09 22:47 --- I would get a clearification from the standards comittee if I were you. multiplying a large unsigned number by 16 and getting an overflow is werid case but again, the developer should be checking the si

[Bug c++/19351] operator new[] can return heap blocks which are too small

--- Additional Comments From bangerth at dealii dot org 2005-01-09 22:48 --- I also wonder what the semantics are that you are expecting? I mean, you try to allocate an array that is so large that you can't address the individual bytes using a size_t, in other words one that is large

[Bug fortran/19352] New: Recursive IO functions are not allowed

In this is both a fortran and a libfortran problem. Take the following code and try to run it and you will get an internal error: module mymod contains function mystring () character(len=4) :: mystring write (unit=mystring,fmt='(A)') '' end function mystring end module mymod progr

[Bug fortran/19352] Recursive IO functions are not allowed

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-09 22:53 --- If I remember correctly to fix this correctly you also need to fix PR 14943. -- What|Removed |Added --

[Bug fortran/17675] [Regression w.r.t. g77] Alignment constraints not honored in EQUIVALENCE

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-09 22:57 --- Subject: Bug 17675 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-09 22:57:45 Modified files: gcc/fortran: ChangeLog trans-common.c gcc

[Bug fortran/19292] [metabug] g77 features lacking in gfortran

-- Bug 19292 depends on bug 17675, which changed state. Bug 17675 Summary: [Regression w.r.t. g77] Alignment constraints not honored in EQUIVALENCE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17675 What|Old Value |New Value

[Bug fortran/17675] [Regression w.r.t. g77] Alignment constraints not honored in EQUIVALENCE

--- Additional Comments From pbrook at gcc dot gnu dot org 2005-01-09 22:59 --- Should be fixed now. -- What|Removed |Added Status|ASSIGNED|R

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

-- Bug 18977 depends on bug 17675, which changed state. Bug 17675 Summary: [Regression w.r.t. g77] Alignment constraints not honored in EQUIVALENCE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17675 What|Old Value |New Value

[Bug c++/19351] operator new[] can return heap blocks which are too small

--- Additional Comments From fw at deneb dot enyo dot de 2005-01-09 23:07 --- There's no multiplication in the source code. The multiplication is an implementation detail. You can hardly use it to justify the semantics of the operation. I would expect that std::bad_alloc is thrown. B

[Bug c++/19351] operator new[] can return heap blocks which are too small

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-09 23:11 --- (In reply to comment #6) > There's no multiplication in the source code. The multiplication is an > implementation detail. You can hardly use it to justify the semantics of the > operation. Actually the m

[Bug fortran/17675] [Regression w.r.t. g77] Alignment constraints not honored in EQUIVALENCE

--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-09 23:16 --- > Should be fixed now. Unfortunately not all of them: FAIL: gfortran.dg/g77/980628-10.f -O0 execution test FAIL: gfortran.dg/g77/980628-10.f -O1 execution test FAIL: gfortran.dg/g77/980628-10.f -O2

[Bug fortran/19292] [metabug] g77 features lacking in gfortran

-- Bug 19292 depends on bug 17675, which changed state. Bug 17675 Summary: [Regression w.r.t. g77] Alignment constraints not honored in EQUIVALENCE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17675 What|Old Value |New Value

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

-- Bug 18977 depends on bug 17675, which changed state. Bug 17675 Summary: [Regression w.r.t. g77] Alignment constraints not honored in EQUIVALENCE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17675 What|Old Value |New Value

[Bug regression/19174] wrong code regression or library problem in gcc-4.0-20041226

--- Additional Comments From andre dot maute at gmx dot de 2005-01-10 00:00 --- tried gcc-4.0-20050109 compile with gcc-3.4.3 the problem still appears -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19174

[Bug c++/19311] [3.4/4.0 Regression] ICE in resolve_overloaded_unification

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-10 00:50 --- I almost think this was caused by: 2004-07-18 Kriang Lerdsuwanakij <[EMAIL PROTECTED]> 2004-07-28 Kriang Lerdsuwanakij <[EMAIL PROTECTED]> PR c++/13092 Because that is when the date mat

[Bug target/19307] [4.0 Regression] ICE with -msse2 -mno-80387

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-10 00:52 --- It also worked with 2004-12-11. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19307

[Bug tree-optimization/16220] [4.0 Regression] Jump pessimization

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-10 01:05 --- Fixed by: 2005-01-08 Roger Sayle <[EMAIL PROTECTED]> * ifcvt.c (find_if_case_1): Reinstate 2005-01-04 change, now that the latent bug in rtl_delete_block has been resolved. aka 2005-01-04

[Bug fortran/19352] Recursive IO functions are not allowed (F2003)

--- Additional Comments From pbrook at gcc dot gnu dot org 2005-01-10 01:28 --- This is a f2003 feature, and not legal f95. http://gcc.gnu.org/ml/fortran/2005-01/msg00091.html -- What|Removed |Added ---

[Bug rtl-optimization/8361] [3.3/3.4/4.0 regression] C++ compile-time performance regression

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-10 01:35 --- I am now getting results which say at -O1, we are now faster than 3.3.2, could someone test to make sure that they get close results to mine? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8361

[Bug driver/19353] New: Faulty handling of startfile_prefix_spec

This test case is about the spec `startfile_prefix_spec', tho' I suspect the problem might actually be a generic specs problem, but am not sure. Scenario: Say you want to link executables with startfiles different from those in the default location on your system. Sure, I can use -B, but there are

[Bug driver/19353] Faulty handling of startfile_prefix_spec

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-10 02:36 --- Hmm, this SPEC should be removed from the mainline, it is unused in GCC at all. Most of the use of this was removed when this patch was applied: . In

[Bug c/19090] Non-useful warnings included in -Wall

--- Additional Comments From ak at muc dot de 2005-01-10 02:39 --- Created an attachment (id=7915) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7915&action=view) Patch to add -Wno-pointer-sign This patch adds a new flag to disable this warning. With that the kernel compilation is

[Bug driver/19353] Faulty handling of startfile_prefix_spec

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-10 02:52 --- Patch to remove STARTFILE_PREFIX_SPEC support: . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19353

[Bug c++/19288] No more possible to have a template function that uses a nested class of a template class

--- Additional Comments From jean-pierre dot chevallet at imag dot fr 2005-01-10 03:04 --- (In reply to comment #3) > Giving explicit template arguments for template operators works > the same way: write > x.operator<< (abc) > instead of > x << abc > Ok, I have test it but w

  1   2   >