[Bug tree-optimization/21858] [4.1 Regression] ICE in compare_values, at tree-vrp.c:301
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org, dnovillo at gcc dot gnu ||dot org Summary|ICE in compare_values, at |[4.1 Regression] ICE in |tree-vrp.c:301 |compare_values, at tree- ||vrp.c:301 Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21858
[Bug AWT/20630] Image APIs should use BufferedImage exclusively
--- Additional Comments From sven at physto dot se 2005-06-01 08:06 --- Ok, in light of my reworking of GtkImage, I should add some thoughts here: - GtkImagePainter is gone. GtkImage now does its own drawing, and wraps a GdkPixbuf. - ImageObserver use is pretty much elimated for GtkImage use now, although it should be reintroduced for animated gif support. This can probably be done nicely within the GtkImage class without involving other stuff. - GtkImage should probably be kept to a small extent even in the future, if only for internal Component usage. (I'm thinking about animated-gif support for ImageIcon buttons for instance) - Component and Toolkit.createImage can create two kinds of images, either from a file (essentially immutable), and drawable (createImage(int, int)). The latter should definitely become a BufferedImage with Graphics2D. (as BufferedImage is drawable and its getGraphics() method should return a Graphics2D object) The former should probably be implemented on top of ImageIO in the future. Although the question remains if that'll make things a bit too complicated for animated gifs? - the Graphics peer now supports drawing BufferedImages (although slowly) through the ImageProducer/Consumer interfaces. This should give us a chance to get BufferedImage working at least to some extent. Sketching out a BufferedImage strategy: - The goal is to draw BufferedImages and be able to draw *to* BufferedImages fast. That means no copying or converting pixel data on these operations. If we have to choose one, it should be the latter. Copying image data after every drawing operation would be costly indeed. - User-defined ColorModels are allowed. So the former goal can never be realized fully. Realistically, we should aim for the predefined BufferedImage types. - In other words, we need to differentiate our BufferedImage drawing code for the predefined types, and others. - Storing the image data in Javaland memory space will make data copying necessary, since it can be relocated by the VM. BufferedImage memory must be natively allocated then. - This makes me belive that wrapping these native memory buffers is what java.awt.image.DataBuffer is for. So our current implementation wrapping java arrays is wrong. - Currently, Cairo only seems to support RGB-24 and RGBA-32 color models. We really need it to support all predefined BufferedImage types. (or face copying and converting pixel data on every draw operation) - The easiest starting point for implementing all this should therefore be BufferedImage.TYPE_4BYTE_ABGR. - I still have no good idea how we should handle drawing to a BufferedImage with a user-defined color model and pixel storage. Although I'm not sure this is an important case either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20630
[Bug c++/21619] [4.0/4.1 regression] __builtin_constant_p(&"Hello"[0])?1:-1 not compile-time constant
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2005-06-01 08:16 --- Subject: Re: [4.0/4.1 regression] __builtin_constant_p(&"Hello"[0])?1:-1 not compile-time constant On 1 Jun 2005, pinskia at gcc dot gnu dot org wrote: > > --- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-01 > 00:31 --- > : Search converges between 2004-08-30-trunk (#529) and 2004-08-31-trunk > (#530). Top of cp/ChangeLog for these? I point my finger at 2004-08-31 Richard Henderson <[EMAIL PROTECTED]> PR c++/17221 * pt.c (tsubst_expr): Move OFFSETOF_EXPR handling ... (tsubst_copy_and_build): ... here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21619
[Bug libstdc++/21554] [4.0 Regression] ext/array_allocator/2.cc execution fails
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-06-01 08:33 --- Confirmed on SPARC/Solaris 64-bit. -- What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC target triplet||hppa64-hpux, sparc64-solaris Last reconfirmed|-00-00 00:00:00 |2005-06-01 08:33:42 date|| Summary|[4.0 Regression]|[4.0 Regression] |ext/array_allocator/2.cc|ext/array_allocator/2.cc |execution test fails on |execution fails |hppa64-hpux | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21554
[Bug tree-optimization/21734] [4.1 regression] ICE: -ftree-vectorize, segfault
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-06-01
08:41 ---
Even shorter testcase:
struct A
{
int a[4];
int* operator[](int i) { return &a[i]; }
};
void foo(A a1, A &a2)
{
a1[1][1]=0;
for (int i=0; i<4; ++i)
a2.a[i]=0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21734
[Bug libstdc++/21554] [4.0 Regression] ext/array_allocator/2.cc execution fails
--- Additional Comments From pcarlini at suse dot de 2005-06-01 08:43 --- Eric, if you are willing to prepare a patchlet xfailing the testcase on "strict-alignment" targets, whatever that means (*), I would be grateful. (*) Actually, in case of hppa64 the alignment is insufficient for the size_t length and capacity fields. In other cases (powerpc) can be the atomic memory for the reference-count. In any case, I don't think we can fix this problem without changing basic_string in a binary incompatible way vs other so.6 releases, unfortunately. Certainly, not for 4.0.x. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21554
[Bug libfortran/16436] gfortran TL edit descriptor failure - test f77-edit-t-in.f
-- What|Removed |Added URL||http://gcc.gnu.org/ml/fortra ||n/2005-05/msg00439.html Keywords||patch Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16436
[Bug libfortran/20236] runtime error reading float
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-06-01 09:44 --- As I suggested in comment #3, this is a duplicate of PR16436. Patch from http://gcc.gnu.org/ml/fortran/2005-05/msg00439.html fixes both. *** This bug has been marked as a duplicate of 16436 *** -- What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20236
[Bug libfortran/16436] gfortran TL edit descriptor failure - test f77-edit-t-in.f
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-06-01 09:44 --- *** Bug 20236 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||blime at cox dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16436
[Bug fortran/20235] Gfortran internal read error
-- Bug 20235 depends on bug 20236, which changed state. Bug 20236 Summary: runtime error reading float http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20236 What|Old Value |New Value Status|UNCONFIRMED |NEW Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20235
[Bug tree-optimization/21789] [4.1 regression] ICE with -ftree-vectorize
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-06-01 09:46 --- Dorit, I think your guess is right. The ICE already disappeared with the patch http://gcc.gnu.org/ml/gcc-cvs/2005-05/msg01207.html * tree-ssa-forwprop.c (forward_propagate_addr_expr): See through ADDR_EXPR in finding place to propagate into. But that only seems to paper over the problem. Backing this patch out I get the ICE again. It really disappears with Keith's patch you mentioned: http://gcc.gnu.org/ml/gcc-cvs/2005-05/msg01301.html So I think we can close the PR as fixed then. -- What|Removed |Added CC||dorit at gcc dot gnu dot org Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21789
[Bug libfortran/19308] I/O library should support more real and integer kinds
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-06-01 09:56 --- This bug is a lot more general. I/O library should really support all available kinds of integers and reals. I'm working on that... -- What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Summary|compiler claims to accept |I/O library should support |variables of|more real and integer kinds |selected_integer_kind(30), | |I/O leads to internal error | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19308
[Bug fortran/21729] ICE in gfc_typenode_for_spec
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-01 10:00 --- Subject: Bug 21729 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-01 10:00:20 Modified files: gcc/fortran: ChangeLog resolve.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: implicit_5.f90 Log message: PR fortran/21729 * resolve.c (resolve_contained_fntype): Use sym->attr.untyped to avoid giving error multiple times. (resolve_entries): Don't error about BT_UNKNOWN here. (resolve_unknown_f): Capitalize IMPLICIT for consistency. (resolve_fntype): New function. (gfc_resolve): Call resolve_fntype. * gfortran.dg/implicit_5.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.447&r2=1.448 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/resolve.c.diff?cvsroot=gcc&r1=1.43&r2=1.44 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5570&r2=1.5571 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/implicit_5.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21729
[Bug c++/20350] [4.0/4.1 Regression] extern template and struct initializer and specification for a static variable
--- Additional Comments From nathan at gcc dot gnu dot org 2005-06-01
10:07 ---
Even smaller test case
template struct Mutex
{
static int mutex;
};
template
int Mutex::mutex = {1};
template <> int Mutex<0>::mutex;
template <> int Mutex<0>::mutex = 0;
void g()
{
Mutex<0>::mutex = 0;
}
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2005-03-06 23:49:41 |2005-06-01 10:07:38
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20350
[Bug fortran/21859] New: ICE with -ftree-vectorize and -O2 or higher
Compiling this piece of code: c=== SUBROUTINE SETGRDREC (NMREC,ZREC,KK,Z,IREC) DIMENSION Z(KK) DIMENSION ZREC(NMREC,KK) i = 0 DO K=1,KK ZREC(IREC,I) = Z(I) ENDDO END c=== with the following command: gfortran -O2 -Wall -Wextra -ftree-vectorize -c bug.F -o bug.o results in: === problem.F: In function 'setgrdrec': problem.F:1: error: Definition in block 2 does not dominate use in block 5 for SSA_NAME: TMT.7_31 in statement: # TMT.7_25 = V_MAY_DEF ; (*zrec_28)[D.821_23] = lsm_tmp.9_15; problem.F:1: internal compiler error: verify_ssa failed. === It compiles without problems without -ftree-vectorize or -O1 or lower. output of gfortran -v: === Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ./configure --prefix=/home/vici --enable-languages=f95 : (reconfigured) ./configure --prefix=/home/vici --enable-languages=f95 Thread model: posix gcc version 4.1.0 20050601 (experimental) === Output of uname -a: Linux galadriel 2.6.11.4-20a-default #1 Wed Mar 23 21:52:37 UTC 2005 x86_64 x86_64 x86_64 GNU/Linux -- Summary: ICE with -ftree-vectorize and -O2 or higher Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fischer at td dot mw dot tum dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21859
[Bug fortran/21729] ICE in gfc_typenode_for_spec
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-01 10:13 --- Subject: Bug 21729 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-06-01 10:13:23 Modified files: gcc/fortran: ChangeLog resolve.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: implicit_5.f90 Log message: PR fortran/21729 * resolve.c (resolve_contained_fntype): Use sym->attr.untyped to avoid giving error multiple times. (resolve_entries): Don't error about BT_UNKNOWN here. (resolve_unknown_f): Capitalize IMPLICIT for consistency. (resolve_fntype): New function. (gfc_resolve): Call resolve_fntype. * gfortran.dg/implicit_5.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.335.2.60&r2=1.335.2.61 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/resolve.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.34.2.8&r2=1.34.2.9 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.214&r2=1.5084.2.215 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/implicit_5.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21729
[Bug c/21860] New: Frontends should be adding DECL_EXPRs for TYPE_DECLs, at least when the type has SAVE_EXPRs in it
See http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02644.html > ... or the frontends would need to guarantee that for all types with some > variable TYPE_SIZE reachable from the type there would be a DECL_EXPR with > TYPE_DECL right before the first use of such type. > What's your preference? This later option should be the eventual goal. That's not appropriate for the 4.0 branch though. Your posted patch plus some additions for aggregates should be good enough for that. -- Summary: Frontends should be adding DECL_EXPRs for TYPE_DECLs, at least when the type has SAVE_EXPRs in it Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21860
[Bug fortran/21859] ICE with -ftree-vectorize and -O2 or higher
-- What|Removed |Added GCC build triplet||x86_64-linux-gnu GCC host triplet||x86_64-linux-gnu GCC target triplet||x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21859
[Bug c/20760] cast to variable-length array type combined with switch statement gives segv
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-01 10:23 --- Subject: Bug 20760 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-01 10:23:17 Modified files: gcc: ChangeLog gimplify.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: 20050527-1.c Log message: PR c/21536 PR c/20760 * gimplify.c (gimplify_decl_expr): Call gimplify_type_sizes on variable sizes types if a decl is a pointer to a VLA. (gimplify_type_sizes): Handle POINTER_TYPE and REFERENCE_TYPE. Call gimplify_type_sizes on aggregate fields. Prevent infinite recursion. * gcc.dg/20050527-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8979&r2=2.8980 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gimplify.c.diff?cvsroot=gcc&r1=2.129&r2=2.130 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5572&r2=1.5573 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20050527-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20760
[Bug c/21536] [3.4/4.0/4.1 Regression] C99 array of variable length use causes segmentation fault
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-01 10:23 --- Subject: Bug 21536 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-01 10:23:17 Modified files: gcc: ChangeLog gimplify.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: 20050527-1.c Log message: PR c/21536 PR c/20760 * gimplify.c (gimplify_decl_expr): Call gimplify_type_sizes on variable sizes types if a decl is a pointer to a VLA. (gimplify_type_sizes): Handle POINTER_TYPE and REFERENCE_TYPE. Call gimplify_type_sizes on aggregate fields. Prevent infinite recursion. * gcc.dg/20050527-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8979&r2=2.8980 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gimplify.c.diff?cvsroot=gcc&r1=2.129&r2=2.130 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5572&r2=1.5573 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20050527-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21536
[Bug c/20760] cast to variable-length array type combined with switch statement gives segv
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-01 10:36 --- Subject: Bug 20760 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-06-01 10:35:49 Modified files: gcc: ChangeLog gimplify.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: 20050527-1.c Log message: PR c/21536 PR c/20760 * gimplify.c (gimplify_decl_expr): Call gimplify_type_sizes on variable sizes types if a decl is a pointer to a VLA. (gimplify_type_sizes): Handle POINTER_TYPE and REFERENCE_TYPE. Call gimplify_type_sizes on aggregate fields. Prevent infinite recursion. * gcc.dg/20050527-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.273&r2=2.7592.2.274 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gimplify.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.113.2.4&r2=2.113.2.5 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.216&r2=1.5084.2.217 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20050527-1.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20760
[Bug c/21536] [3.4/4.0/4.1 Regression] C99 array of variable length use causes segmentation fault
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-01 10:36 --- Subject: Bug 21536 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-06-01 10:35:49 Modified files: gcc: ChangeLog gimplify.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: 20050527-1.c Log message: PR c/21536 PR c/20760 * gimplify.c (gimplify_decl_expr): Call gimplify_type_sizes on variable sizes types if a decl is a pointer to a VLA. (gimplify_type_sizes): Handle POINTER_TYPE and REFERENCE_TYPE. Call gimplify_type_sizes on aggregate fields. Prevent infinite recursion. * gcc.dg/20050527-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.273&r2=2.7592.2.274 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gimplify.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.113.2.4&r2=2.113.2.5 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.216&r2=1.5084.2.217 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20050527-1.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21536
[Bug tree-optimization/21861] New: [meta-bug] scalar evolution type conversion
At the moment, there are some missed optimizations and errors linked to the same problem: type conversion of induction variables. -- Summary: [meta-bug] scalar evolution type conversion Product: gcc Version: 3.3.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sebastian dot pop at cri dot ensmp dot fr CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21861
[Bug tree-optimization/21861] [meta-bug] scalar evolution type conversion
-- What|Removed |Added BugsThisDependsOn||18403, 21029 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21861
[Bug fortran/21859] ICE with -ftree-vectorize and -O2 or higher
--- Additional Comments From dorit at il dot ibm dot com 2005-06-01 11:13 --- I can reproduce this on powerpc-apple-darwin. Maybe a duplicate of PR21831. Hopefully will be resolved by Keith's work (http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02478.html) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21859
[Bug libfortran/19216] list directed read with leading slash (NIST FM923)
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-06-01 11:17 --- This is more complex than I thought. It appears that: 1. there is a typo (space missing in dg command) in the testcase 2. when the typo is corrected and the testcase is really ran, it FAILs on both mainline and 4.0 I'll be looking into this. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Keywords|patch | Last reconfirmed|2005-04-18 07:18:07 |2005-06-01 11:17:25 date|| Summary|[4.0 only] list directed|list directed read with |read with leading slash |leading slash (NIST FM923) |(NIST FM923)| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19216
[Bug tree-optimization/21155] [4.1 Regression] ICE in ssa tree check compiling crafty with -ftree-vectorize -maltivec
--- Additional Comments From dorit at il dot ibm dot com 2005-06-01 11:24 --- I think Keith is looking into these SPEC ICEs on powerpc-linux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21155
[Bug rtl-optimization/21767] if-convert leaves invalid REG_EQUAL notes
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-01 11:39 --- Subject: Bug 21767 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-01 11:38:54 Modified files: gcc: ChangeLog rtl.h reload1.c ifcvt.c Log message: PR rtl-optimization/21767 * rtl.h (function_invariant_p): Re-add declaration. * reload1.c (function_invariant_p): No longer static. * ifcvt.c (dead_or_predicable): Remove REG_EQUAL notes that might have become invalid. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8980&r2=2.8981 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/rtl.h.diff?cvsroot=gcc&r1=1.550&r2=1.551 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/reload1.c.diff?cvsroot=gcc&r1=1.471&r2=1.472 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ifcvt.c.diff?cvsroot=gcc&r1=1.189&r2=1.190 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21767
[Bug rtl-optimization/21767] if-convert leaves invalid REG_EQUAL notes
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-06-01 11:45 --- Fixed on mainline with patch just checked in. Now we have to decide if we want this fix (without the reload1.c / rtl.h hunks) in 3.4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21767
[Bug libstdc++/21405] Template inlines have global visibility
--- Additional Comments From mike at navi dot cx 2005-06-01 11:56 --- So this feature is basically terminally broken and never worked in the first place? How about if GCC supported a new attribute or something that made it emit inlines for that class with a specific symbol version? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21405
[Bug rtl-optimization/21767] if-convert leaves invalid REG_EQUAL notes
-- What|Removed |Added OtherBugsDependingO|20070 | nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21767
[Bug rtl-optimization/20070] If-conversion can't match equivalent code, and cross-jumping only works for literal matches
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-06-01 11:59 --- For the purposes of PR20070, it is sufficient that PR21767 is fixed on mainline. -- What|Removed |Added BugsThisDependsOn|21767 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20070
[Bug rtl-optimization/21848] [4.1 Regression] load_mems / replace_loop_mems bug causes miscompilation of jcf-io.c / SEGV while processing java/lang/AbstractMethodError
-- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21848
[Bug tree-optimization/21859] ICE with -ftree-vectorize and -O2 or higher
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-01 12:15 --- Confirmed based on Dorit's comment. -- What|Removed |Added Status|UNCONFIRMED |NEW Component|fortran |tree-optimization Ever Confirmed||1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2005-06-01 12:15:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21859
[Bug libfortran/21787] libfortran - better error message needed
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-06-01 12:48 --- A few things you can do: 1. Run this program inside gdb: Compile all files with "-g" flag, then run "gdb ./myprogram" and enter the command "run"). When program aborts, signal should be caught by gdb and you should have a prompt; enter the "where" command and post here what it says. 2. Trim it down if you have time. 3. Send it to me by private mail, with instructions to build it. I'll be glad to trim it down (and the code will not be posted publicly) and debug. PS: sorry if point 1 sounds trivial to you. I just don't know if you are familiar with gdb. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21787
[Bug libfortran/21787] libfortran - better error message needed
-- What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21787
[Bug tree-optimization/21861] [meta-bug] scalar evolution type conversion
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||meta-bug Last reconfirmed|-00-00 00:00:00 |2005-06-01 13:06:16 date|| Version|3.3.1 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21861
[Bug middle-end/21862] New: strength reduction uses signed comparisons for pointers
The attached testcase fails on i386-linux (as well as x86_64-linux -m32). It computes the p + (MAP_LEN / 0x100) * 0x100 end pointer, but instead of doing unsigned comparison on the pointers, it does a signed one, which obviously doesn't work if the pointer has topmost bit set. -- Summary: strength reduction uses signed comparisons for pointers Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P2 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: i386-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21862
[Bug middle-end/21862] strength reduction uses signed comparisons for pointers
--- Additional Comments From jakub at gcc dot gnu dot org 2005-06-01 13:10 --- Created an attachment (id=9007) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9007&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21862
[Bug middle-end/21862] strength reduction uses signed comparisons for pointers
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-01 13:18 --- This is a known bug, see gcc.c-torture/execute/loop-2e.c. This is a dup of bug 16052. *** This bug has been marked as a duplicate of 16052 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21862
[Bug rtl-optimization/16052] strength reduction produces wrong code
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-01 13:18 --- *** Bug 21862 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16052
[Bug tree-optimization/21734] [4.1 regression] ICE: -ftree-vectorize, segfault
--- Additional Comments From dorit at il dot ibm dot com 2005-06-01 13:20 --- thanks, reproduced. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21734
[Bug tree-optimization/21734] [4.1 regression] ICE: -ftree-vectorize, segfault
--- Additional Comments From dorit at il dot ibm dot com 2005-06-01 13:22
---
> Note that if !new_ssa_name, we continue the loop without ever
> adding the PHI argument. The net result being that we have a
> PHI where PHI_ARG_DEF for one of the PHI's incoming edges is null.
>
> I'm pretty sure that this can only happen if the result of the
> PHI is not set anywhere in the loop.
you're right, this is exactly what we have here:
before loop duplication we have:
m2 = phi
The phi is dead, and has no defs in the loop, which, as you identified, results
in the fact that it doesn't have a current_def set, and then in the duplicated
loop we have:
m24 = phi
> In that case the PHI
> argument in question should be the same SSA_NAME as the PHI_RESULT
> [ ie, we ultimately end up generating a degenerate phi of the form
>
>
> x_3 = PHI (x_3 (latch edge), x_2 (initial value from entry edge))
>
>
Indeed applying the following patch, which does exactly that, solves the
problem:
Index: tree-vectorizer.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-vectorizer.c,v
retrieving revision 2.91
diff -u -3 -p -r2.91 tree-vectorizer.c
--- tree-vectorizer.c 26 May 2005 18:14:48 - 2.91
+++ tree-vectorizer.c 1 Jun 2005 13:11:01 -
@@ -1,3 +1,4 @@
+
/* Loop Vectorization
Copyright (C) 2003, 2004, 2005 Free Software Foundation, Inc.
Contributed by Dorit Naishlos <[EMAIL PROTECTED]>
@@ -321,8 +322,11 @@ slpeel_update_phis_for_duplicate_loop (s
new_ssa_name = get_current_def (def);
if (!new_ssa_name)
-/* Something defined outside of the loop. */
-continue;
+ {
+ /* This only happens if there are no definitions
+inside the loop. use the phi_result in this case. */
+ new_ssa_name = PHI_RESULT (phi_new);
+ }
/* An ordinary ssa name defined in the loop. */
add_phi_arg (phi_new, new_ssa_name, loop_latch_edge (new_loop));
@@ -566,7 +570,12 @@ slpeel_update_phi_nodes_for_guard1 (edge
else
{
current_new_name = get_current_def (loop_arg);
- gcc_assert (current_new_name);
+ /* current_def is not available only if the variable does not
+change inside the loop, in which case we also don't care
+about recording a current_def for it because we won't be
+trying to create loop-exit-phis for it. */
+ if (!current_new_name)
+ continue;
}
>
> What I don't know yet is if the problem is really that we haven't
> set up the current def properly (thus causing get_current_def to
> return NULL) or if we just need code to compensate for this
> situation in slpeel_update_phis_for_duplicate_loop.
>
> Thoughts?
>
I don't know which current_def would make sense to set for this phi, if at all.
It originally was:
m2 = phi
m16 =
after t41.alias4 it became:
m2 = phi
and after t44.store_ccp it got to its current form:
m2 = phi
The best thing would be to detect such redundant phis and clean them up, and in
the vectorizer work under the assumption that they don't exit. The code to do
peeling would be cleaner (not having to consider these special cases), and we
would generate much less code (see below how many phis we end up generating
when peeling before and after this loop). By the way, all these garbage phis do
get eliminated later on, by dce (at t68.cd_dce). Calling dce just before loop
optimizations or just before the vectorizer also solved the problem. We can
actually also detect invariant/dead phis at the beginning of the vectorizer (it
will be pretty much for free cause we examine all phis and their uses anyhow.
might as well get rid of them). In the meantime, I'll test the patch above.
FYI, when applying the patch above, the resulting code that we generate is as
shown below:
==
>>>before:
orig_loop:
m2 = phi
>>>after:
if C1 goto new_prolog_loop
else goto bb1
new_prolog_loop (dup):
m24 = phi
loop_exit:
m34 = phi
if C2 goto bb1
else goto bb3
bb1:
m33 = phi
if C3 goto orig_loop
else goto bb2
orig_loop:
m2 = phi
loop_exit:
m54 = phi
if C4 goto bb2
else goto bb4
bb2:
m53 = phi
new_epilog_loop (dup):
m44 = phi
loop exit:
bb4:
bb3:
==
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21734
[Bug c++/21151] [4.0/4.1 Regression] ICE when compiling c++ PCH of class definition within template function.
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-04-21 14:37:25 |2005-06-01 13:47:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21151
[Bug c++/20350] [4.0/4.1 Regression] extern template and struct initializer and specification for a static variable
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-01 14:47 --- Subject: Bug 20350 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-06-01 14:47:07 Modified files: gcc/cp : ChangeLog decl.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/template: spec24.C Log message: cp: PR c++/20350 * decl.c (duplicate_decls): Copy all of DECL_USE_TEMPLATE. testsuite: PR c++/20350 * g++.dg/template/spec24.C: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.4648.2.51&r2=1.4648.2.52 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.1371.2.11&r2=1.1371.2.12 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.217&r2=1.5084.2.218 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/spec24.C.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20350
[Bug libgcj/21753] String.substring sharing heuristic should be improved
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-01 15:52 --- Subject: Bug 21753 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-06-01 15:51:58 Modified files: libjava: ChangeLog libjava/java/lang: natString.cc Log message: PR libgcj/21753: * java/lang/natString.cc (substring): Changed sharing heuristic. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.3391.2.80&r2=1.3391.2.81 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/lang/natString.cc.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.36.12.1&r2=1.36.12.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21753
[Bug libgcj/21753] String.substring sharing heuristic should be improved
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-01 15:53 --- Subject: Bug 21753 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-01 15:52:45 Modified files: libjava: ChangeLog libjava/java/lang: natString.cc Log message: PR libgcj/21753: * java/lang/natString.cc (substring): Changed sharing heuristic. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&r1=1.3640&r2=1.3641 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/lang/natString.cc.diff?cvsroot=gcc&r1=1.38&r2=1.39 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21753
[Bug libgcj/21753] String.substring sharing heuristic should be improved
--- Additional Comments From tromey at gcc dot gnu dot org 2005-06-01 15:54 --- I've checked in a fix. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21753
[Bug libgcj/21785] [4.1 regression] ClassNotFound during deserialization
--- Additional Comments From tromey at gcc dot gnu dot org 2005-06-01 17:15 --- I'm testing a patch. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21785
[Bug bootstrap/21698] creating first stage compiler
--- Additional Comments From jlm_devel at laposte dot net 2005-06-01 17:35 --- this issue is solved if and only if BOTH configure options are set : --with-local-prefix=$DESTDIR_BCKP --with-sysroot=$DESTDIR_BCKP specifying only where to find the headers isn't enough but the error message don't help finding the issue -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21698
[Bug other/21863] New: strange code generation
Given the appended input this code gets generated by gcc 3.4 / 4.0 / 4.1 version when launched by "g++ matrix.cpp -o matrix -O2 -Wall -Wextra -pedantic -std=c++98 -save-temps": .LCFI2: leal-48(%ebp), %ecx leal-88(%ebp), %ebx subl$100, %esp .LCFI3: movl$1, -48(%ebp) movl$2, -44(%ebp) andl$-16, %esp movl$3, -40(%ebp) movl$4, -36(%ebp) subl$16, %esp movl$5, -32(%ebp) movl$6, -28(%ebp) movl$7, -24(%ebp) movl$8, -20(%ebp) movl$9, -16(%ebp) movl$10, -12(%ebp) .p2align 4,,7 could be replaced by .LCFI2: leal-48(%ebp), %ecx leal-88(%ebp), %ebx .LCFI3: movl$1, -48(%ebp) movl$2, -44(%ebp) movl$3, -40(%ebp) movl$4, -36(%ebp) movl$5, -32(%ebp) movl$6, -28(%ebp) movl$7, -24(%ebp) movl$8, -20(%ebp) movl$9, -16(%ebp) movl$10, -12(%ebp) .p2align 4,,7 Since esp won't be accessed in the remaining program. gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.1-20050528/configure --prefix=/import/share/tools --with-local-prefix=/import/share/tools --with-arch=athlon --enable-version-specific-runtime-libs --enable-languages=c,c++ --program-suffix=-4.1 --disable-werror Thread model: posix gcc version 4.1.0 20050528 (experimental) -- Summary: strange code generation Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: alonsoschaich at gmx dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21863
[Bug other/21863] strange code generation
--- Additional Comments From alonsoschaich at gmx dot de 2005-06-01 17:50 --- Created an attachment (id=9008) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9008&action=view) precompiled code and assembly output -save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21863
[Bug c++/21864] New: ICE on invalid command line
Having a directory name, a -c and -o on the command line causes an ICE and a seg
fault. The actual code does not seem to matter. Reproduction instructions and
actual output follow:
cheinan/test> cat null.cpp
int main()
{
return 0;
}
cheinan/test> g++ /home/cheinan/test -c null.cpp -o MakeMeICE.o
g++: /home/cheinan/test: linker input file unused because linking not done
cc1plus: /home/cheinan/test: No such file or directory
cc1plus: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
cheinan/test> gcc -v
Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/specs
Configured with: ../gcc-3.4.3/configure --prefix=/usr/local
--enable-threads=posix --enable-languages=c,c++ --disable-nls
--enable-__cxa_atexit --enable-shared --program-suffix=3.4.3
Thread model: posix
gcc version 3.4.3
cheinan/test>
Workaround: Fix make file so invalid compiler command lines are not produced.
--
Summary: ICE on invalid command line
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cheinan at atg dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21864
[Bug middle-end/21842] [4.1 Regression] 23_containers/bitset/operations/2.cc execution test fails
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-06-01 17:53 --- Fixed mainline 20050601. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21842
[Bug middle-end/21843] [4.1 Regression] gcc.c-torture/execute/920501-2.c execution fails
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-06-01 17:54 --- Fixed mainline 20050601. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21843
[Bug middle-end/21842] [4.1 Regression] 23_containers/bitset/operations/2.cc execution test fails
-- Bug 21842 depends on bug 21843, which changed state. Bug 21843 Summary: [4.1 Regression] gcc.c-torture/execute/920501-2.c execution fails http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21843 What|Old Value |New Value Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21842
[Bug tree-optimization/21734] [4.1 regression] ICE: -ftree-vectorize, segfault
--- Additional Comments From giovannibajo at libero dot it 2005-06-01 18:08 --- Please, remember to add both the new and the old testcase to the testsuite. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21734
[Bug testsuite/21865] New: gcc.dg/torture/pr21817-1.c fails on hppa2.0w-hpux
The newly added test gcc.dg/torture/pr21817-1.c fails on hppa2.0w-hpux with: pr21817-1.c:12: warning: alignment (16) for value exceeds maximum alignment for global common data. Using 8 This is a target-specific warning. There seems to be nothing about this test requiring it to be in gcc.dg (and the test does not seem to have been included in the patch posted - patches should always be posted as the exact patch tested and proposed to be committed including all testcases in their proposed locations), so it would better belong in gcc.c-torture/compile, which would fix this problem by having the warning no longer cause a test failure. FAIL: gcc.dg/torture/pr21817-1.c -O0 (test for excess errors) FAIL: gcc.dg/torture/pr21817-1.c -O1 (test for excess errors) FAIL: gcc.dg/torture/pr21817-1.c -O2 (test for excess errors) FAIL: gcc.dg/torture/pr21817-1.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.dg/torture/pr21817-1.c -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gcc.dg/torture/pr21817-1.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gcc.dg/torture/pr21817-1.c -O3 -g (test for excess errors) FAIL: gcc.dg/torture/pr21817-1.c -Os (test for excess errors) -- Summary: gcc.dg/torture/pr21817-1.c fails on hppa2.0w-hpux Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: hppa2.0w-*-hpux11.* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21865
[Bug testsuite/21866] New: profiledbootstrap on gcc4 - release fails
I think it is an already fixed bug at least in CVS, though I can't find the appropriate patch. I have now tried at least 25 patches since release date which are around string and bootstrapping issues, no lack so far. Please point me towards the appropriate fix. Thanks in advance T.Gerschner Making all in testsuite make[4]: Entering directory `/usr/src/yoper/BUILD/gcc-build/i686-pc-linux-gnu/libstdc++-v3/testsuite' /bin/sh ../libtool --tag=CXX --mode=link /usr/src/yoper/BUILD/gcc-build/gcc/g++ -shared-libgcc -B/usr/src/yoper/BUILD/gcc-build/gcc/ -nostdinc++ -L/usr/src/yoper/BUILD/gcc-build/i686-pc-linux-gnu/libstdc++-v3/src -L/usr/src/yoper/BUILD/gcc-build/i686-pc-linux-gnu/libstdc++-v3/src/.libs -B/usr/i686-pc-linux-gnu/bin/ -B/usr/i686-pc-linux-gnu/lib/ -isystem /usr/i686-pc-linux-gnu/include -isystem /usr/i686-pc-linux-gnu/sys-include -R `/usr/src/yoper/BUILD/gcc-build/gcc/xgcc -B/usr/src/yoper/BUILD/gcc-build/gcc/ -B/usr/i686-pc-linux-gnu/bin/ -B/usr/i686-pc-linux-gnu/lib/ -isystem /usr/i686-pc-linux-gnu/include -isystem /usr/i686-pc-linux-gnu/sys-include -print-libgcc-file-name | sed 's,/[^/]*$,,'` -R /usr/src/yoper/BUILD/gcc-build/i686-pc-linux-gnu/libstdc++-v3/src/.libs -g -O2 -D_GLIBCXX_ASSERT -ffunction-sections -fdata-sections -fmessage-length=0 -DLOCALEDIR="/usr/src/yoper/BUILD/gcc-build/i686-pc-linux-gnu/libstdc++-v3/po/share/locale" -g -O2 -D_GNU_SOURCE -lv3test -L. -o abi_check abi_check.o -lm /usr/src/yoper/BUILD/gcc-build/gcc/g++ -shared-libgcc -B/usr/src/yoper/BUILD/gcc-build/gcc/ -nostdinc++ -B/usr/i686-pc-linux-gnu/bin/ -B/usr/i686-pc-linux-gnu/lib/ -isystem /usr/i686-pc-linux-gnu/include -isystem /usr/i686-pc-linux-gnu/sys-include -g -O2 -D_GLIBCXX_ASSERT -ffunction-sections -fdata-sections -fmessage-length=0 -DLOCALEDIR=/usr/src/yoper/BUILD/gcc-build/i686-pc-linux-gnu/libstdc++-v3/po/share/locale -g -O2 -D_GNU_SOURCE -o abi_check abi_check.o -L/usr/src/yoper/BUILD/gcc-build/i686-pc-linux-gnu/libstdc++-v3/src -L/usr/src/yoper/BUILD/gcc-build/i686-pc-linux-gnu/libstdc++-v3/src/.libs -lv3test -L/usr/src/yoper/BUILD/gcc-build/i686-pc-linux-gnu/libstdc++-v3/testsuite -lm -Wl,--rpath -Wl,/usr/src/yoper/BUILD/gcc-build/gcc -Wl,--rpath -Wl,/usr/src/yoper/BUILD/gcc-build/i686-pc-linux-gnu/libstdc++-v3/src/.libs /usr/src/yoper/BUILD/gcc-build/i686-pc-linux-gnu/libstdc++-v3/testsuite/libv3test.a(testsuite_abi.o): In function `__gnu_cxx::hashtable, std::allocator > const, symbol>, std::basic_string, std::allocator >, __gnu_cxx::hash, std::allocator > >, std::_Select1st, std::allocator > const, symbol> >, std::equal_to, std::allocator > >, std::allocator >::_M_copy_from(__gnu_cxx::hashtable, std::allocator > const, symbol>, std::basic_string, std::allocator >, __gnu_cxx::hash, std::allocator > >, std::_Select1st, std::allocator > const, symbol> >, std::equal_to, std::allocator > >, std::allocator > const&)': /usr/src/yoper/BUILD/gcc-build/i686-pc-linux-gnu/libstdc++-v3/include/ext/hash_map:233: undefined reference to `std::basic_string, std::allocator >::~basic_string()' /usr/src/yoper/BUILD/gcc-build/i686-pc-linux-gnu/libstdc++-v3/include/ext/hash_map:233: undefined reference to `std::basic_string, std::allocator >::~basic_string()' /usr/src/yoper/BUILD/gcc-build/i686-pc-linux-gnu/libstdc++-v3/include/ext/hash_map:233: undefined reference to `std::basic_string, std::allocator >::~basic_string()' /usr/src/yoper/BUILD/gcc-build/i686-pc-linux-gnu/libstdc++-v3/include/ext/hash_map:233: undefined reference to `std::basic_string, std::allocator >::~basic_string()' /usr/src/yoper/BUILD/gcc-build/i686-pc-linux-gnu/libstdc++-v3/testsuite/libv3test.a(testsuite_abi.o): In function `symbol::init(std::basic_string, std::allocator >&)': ../../../../gcc-4.0.0/libstdc++-v3/testsuite/testsuite_abi.cc:65: undefined reference to `std::basic_istringstream, std::allocator >::basic_istringstream(std::basic_string, std::allocator > const&, std::_Ios_Openmode)' /usr/src/yoper/BUILD/gcc-build/i686-pc-linux-gnu/libstdc++-v3/testsuite/libv3test.a(testsuite_abi.o): In function `check_version(symbol const&, bool)': ../../../../gcc-4.0.0/libstdc++-v3/testsuite/testsuite_abi.cc:160: undefined reference to `std::allocator::allocator()' ../../../../gcc-4.0.0/libstdc++-v3/testsuite/testsuite_abi.cc:160: undefined reference to `std::basic_string, std::allocator >::~basic_string()' ../../../../gcc-4.0.0/libstdc++-v3/testsuite/testsuite_abi.cc:161: undefined reference to `std::allocator::allocator()' ../../../../gcc-4.0.0/libstdc++-v3/testsuite/testsuite_abi.cc:161: undefined reference to `std::basic_string, std::allocator >::~basic_string()' ../../../../gcc-4.0.0/libstdc++-v3/testsuite/testsuite_abi.cc:162: undefined reference to `std::allocator::allocator()' ../../../../gcc-4.0.0/libstdc++-v3/testsuite/testsuite_abi.cc:162: undefined reference to `std::basic_string, std::allocator >::~basic_string()' ../../../../gcc-4.0.0/libstdc++-v3/testsuite/testsuite_abi.cc:163: undefined reference to `std::allocator::allocator()' ../../
[Bug rtl-optimization/21767] if-convert leaves invalid REG_EQUAL notes
--- Additional Comments From giovannibajo at libero dot it 2005-06-01 18:10 --- Well, 3.4 is open for regression fixes only. Did the testcase ever work before 3.4 in any previous GCC version? -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |amylaar at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21767
[Bug rtl-optimization/21767] if-convert leaves invalid REG_EQUAL notes
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-06-01 18:38 --- (In reply to comment #4) > Well, 3.4 is open for regression fixes only. Did the testcase ever work > before > 3.4 in any previous GCC version? Of course. if-conversion is a relatively new pass: 2000-04-30 Richard Henderson <[EMAIL PROTECTED]> * ifcvt.c: New file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21767
[Bug rtl-optimization/21767] if-convert leaves invalid REG_EQUAL notes
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-06-01 18:53 --- (In reply to comment #4) > Well, 3.4 is open for regression fixes only. Did the testcase ever work > before > 3.4 in any previous GCC version? P.S.: There used to be an euivalent optimization in jump.c, but that one explicitly acknowledged the problem with REG_EQUAL notes possibly confusing cse, and didn't do the transformation if a non-trivial REG_EQUAL note was present. For details, do: cvs -z 9 dif -puw -r1.119 -r1.120 jump.c|less and search for: x = a; goto l -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21767
[Bug c/20760] cast to variable-length array type combined with switch statement gives segv
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-01 18:59 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20760
[Bug c/16989] [meta-bug] C99 conformance bugs
-- Bug 16989 depends on bug 20760, which changed state. Bug 20760 Summary: cast to variable-length array type combined with switch statement gives segv http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20760 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16989
[Bug c/21536] [3.4 Regression] C99 array of variable length use causes segmentation fault
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-01 19:00 --- Fixed in 4.0.1 and above. -- What|Removed |Added Known to work|2.95.3 |2.95.3 4.0.1 4.1.0 Summary|[3.4/4.0/4.1 Regression] C99|[3.4 Regression] C99 array |array of variable length use|of variable length use |causes segmentation fault |causes segmentation fault http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21536
[Bug c++/21864] ICE on invalid command line
--- Additional Comments From bangerth at dealii dot org 2005-06-01 19:00 --- This is a dup of PR 15259, which is already fixed in 4.0. *** This bug has been marked as a duplicate of 15259 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21864
[Bug middle-end/15259] [3.4/4.0 regression] segv
--- Additional Comments From bangerth at dealii dot org 2005-06-01 19:00 --- *** Bug 21864 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||cheinan at atg dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15259
[Bug tree-optimization/21734] [4.1 regression] ICE: -ftree-vectorize, segfault
--- Additional Comments From dorit at il dot ibm dot com 2005-06-01 19:14 --- > Please, remember to add both the new and the old testcase to the testsuite. patch: http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00110.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21734
[Bug other/21863] strange code generation
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-01 19:15 --- Use -fomit-frame-pointer. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21863
[Bug rtl-optimization/21138] wrong code in sixtrack for -fmodulo-sched
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-01 19:17 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21138
[Bug fortran/21729] ICE in gfc_typenode_for_spec
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-01 19:20 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21729
[Bug middle-end/21858] [4.1 Regression] ICE in compare_values, at tree-vrp.c:301
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-01
19:31 ---
Confirmed, reduced testcase:
unsigned int dsdblm_GetBlockAddress();
void error_LocalAssert(void);
int dsdblm_CreateBlock(unsigned int address)
{
address = dsdblm_GetBlockAddress();
if (address >= (void*)0x0002)
error_LocalAssert();
return address;
}
This is either a front-end bug or a fold bug.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|tree-optimization |middle-end
Ever Confirmed||1
GCC host triplet|i486-elf-linux |
GCC target triplet|arm-elf && i686-pc-linux-gnu|
Last reconfirmed|-00-00 00:00:00 |2005-06-01 19:31:22
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21858
[Bug java/21867] New: failling to build libjava
final stage gcc building fail in libjava --disable-libgcj allow to create the crosscompiler but libjava isn't build then -- Summary: failling to build libjava Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jlm_devel at laposte dot net CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21867
[Bug libgcj/21867] failling to build libjava
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-01 19:35 --- How did it fail? -- What|Removed |Added Component|java|libgcj http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21867
[Bug tree-optimization/21847] [4.0/4.1 Regression] misscompiling of the following java code
-- What|Removed |Added Target Milestone|4.0.0 |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21847
[Bug middle-end/21858] [4.1 Regression] ICE in compare_values, at tree-vrp.c:301
--- Additional Comments From dnovillo at redhat dot com 2005-06-01 19:38
---
Subject: Re: [4.1 Regression] ICE in compare_values, at tree-vrp.c:301
On Wed, Jun 01, 2005 at 07:31:24PM -, pinskia at gcc dot gnu dot org wrote:
>
> --- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-01
> 19:31 ---
> Confirmed, reduced testcase:
> unsigned int dsdblm_GetBlockAddress();
> void error_LocalAssert(void);
> int dsdblm_CreateBlock(unsigned int address)
> {
>address = dsdblm_GetBlockAddress();
>if (address >= (void*)0x0002)
> error_LocalAssert();
>return address;
> }
> This is either a front-end bug or a fold bug.
>
Is this legal C?
vrp15.c: In function `dsdblm_CreateBlock':
vrp15.c:6: warning: comparison between pointer and integer
This is very similar to what I found in the Fortran FE a few days
ago. The .gimple form is already "wrong":
D.1242 = dsdblm_GetBlockAddress ();
address = D.1242;
if (address > 131071B)
We lose, or never emit, the cast to convert the constant to integer.
However, the optimizers should probably not be ICEing here. I
will remove the assert in compare_values, to simply refuse to do
anything when pointers and non-pointers are mixed in the same
predicate.
Diego.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21858
[Bug libgcj/21867] failling to build libjava
--- Additional Comments From jlm_devel at laposte dot net 2005-06-01 19:40 --- Created an attachment (id=9009) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9009&action=view) compilation log with env and bash debug activated -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21867
[Bug middle-end/21858] [4.1 Regression] ICE in compare_values, at tree-vrp.c:301
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-01 19:40 --- (In reply to comment #3) > Is this legal C? This is not valid C but valid GNU C. The front-end should be converting the types correctly Please don't remove the assert, it catches things like this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21858
[Bug libgcj/21867] failling to build libjava
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-01 19:44 --- /prims.Tpo -c ../../../libjava/prims.cc -fPIC -DPIC -o .libs/prims.o ../../../libjava/prims.cc: In function 'void _Jv_catch_segv(int, siginfo_t*, void*)': ../../../libjava/prims.cc:151: error: 'volatile struct sigcontext' has no member named 'rip' ./include/java-signal.h: At global scope: ./include/java-signal.h:62: warning: 'void restore_rt()' declared 'static' but never defined This is a bug in your configuration as it is picking up the 32bit headers. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21867
[Bug target/21719] program using "initgroups()" fails with stack corruption
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-01 19:52 --- Not a GCC bug. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21719
[Bug libgcj/21785] [4.1 regression] ClassNotFound during deserialization
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-01 19:58 --- Subject: Bug 21785 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-01 19:58:26 Modified files: libjava: ChangeLog libjava/java/io: ObjectInputStream.java natObjectInputStream.cc Added files: libjava/testsuite/libjava.lang: pr21785.java pr21785.out Log message: PR libgcj/21785: * java/io/natObjectInputStream.cc (currentClassLoader): Removed. (currentLoader): New method. * java/io/ObjectInputStream.java (resolveProxyClass): Use currentLoader. (currentLoader): Now native. (currentClassLoader): Removed. * testsuite/libjava.lang/pr21785.java: New file. * testsuite/libjava.lang/pr21785.out: New file. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&r1=1.3641&r2=1.3642 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/io/ObjectInputStream.java.diff?cvsroot=gcc&r1=1.41&r2=1.42 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/io/natObjectInputStream.cc.diff?cvsroot=gcc&r1=1.9&r2=1.10 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/testsuite/libjava.lang/pr21785.java.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/testsuite/libjava.lang/pr21785.out.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21785
[Bug libgcj/21785] [4.1 regression] ClassNotFound during deserialization
--- Additional Comments From tromey at gcc dot gnu dot org 2005-06-01 20:01 --- I've checked in the fix. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21785
[Bug libgcj/20169] Serialization: readResolve does not work
-- Bug 20169 depends on bug 21785, which changed state. Bug 21785 Summary: [4.1 regression] ClassNotFound during deserialization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21785 What|Old Value |New Value Status|UNCONFIRMED |NEW Status|NEW |ASSIGNED Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20169
[Bug java/21868] New: [4.1 regression] can't build mauve
I can't build current cvs mauve with current cvs head gcj. I see this: gcj -g -O2 -c -o gnu/testlet/BinaryCompatibility/BinaryCompatibilityTest.o ../mauve/gnu/testlet/BinaryCompatibility/BinaryCompatibilityTest.java ../mauve/gnu/testlet/BinaryCompatibility/BinaryCompatibilityTest.java:32: error: Class or interface gnu.testlet.SimpleTestHarness not found in import. import gnu.testlet.SimpleTestHarness; ^ ../mauve/gnu/testlet/BinaryCompatibility/BinaryCompatibilityTest.java:35: error: Superinterface Testlet of class gnu.testlet.BinaryCompatibility.BinaryCompatibilityTest not found. public class BinaryCompatibilityTest implements Testlet ^ ../mauve/gnu/testlet/BinaryCompatibility/BinaryCompatibilityTest.java:37: error: Type TestHarness not found in declaration of field harness. protected static TestHarness harness; ^ ../mauve/gnu/testlet/BinaryCompatibility/BinaryCompatibilityTest.java:44: error: Type SimpleTestHarness not found in the declaration of the local variable sth. SimpleTestHarness sth = (SimpleTestHarness) harness; ^ ../mauve/gnu/testlet/BinaryCompatibility/BinaryCompatibilityTest.java:77: error: Type TestHarness not found in the declaration of the argument the_harness of method test. public void test (TestHarness the_harness) ^ 5 errors This is incorrect. -- Summary: [4.1 regression] can't build mauve Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tromey at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21868
[Bug java/21856] null pointer check elimination
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-01 20:29 --- Confirmed, see PR 20318 for information about an attribute which we should be adding soon. -- What|Removed |Added BugsThisDependsOn||20318 Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-06-01 20:29:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21856
[Bug java/21722] gcj miscompiles accesses to static final vars with indirect dispatch
--- Additional Comments From tromey at gcc dot gnu dot org 2005-06-01 20:30 --- Interestingly, if I compile the two .class files separately and then link the results, it works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21722
[Bug tree-optimization/21855] array bounds checking elimination
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-01 20:31 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Component|java|tree-optimization Ever Confirmed||1 Keywords||alias, missed-optimization Last reconfirmed|-00-00 00:00:00 |2005-06-01 20:31:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21855
[Bug target/19923] openssl is slower when compiled with gcc 4.0 than 3.3
--- Additional Comments From yx at cs dot ucla dot edu 2005-06-01 20:47 --- When we ran 'openssh speed md2', we did see that gcc-4.0 was slower than earlier versions, so we created a minimal test case, which we will attach. Here is how long it took to run a 34 megabyte file through the test program when compiled with various compilers and options: gcc-2.95.3 -fPIC -O1 4.940s gcc-4.0.0 -fPIC -O1 3.510s gcc-3.4.3 -fPIC -O1 5.190s gcc-2.95.3 -fPIC -O2 3.470s gcc-3.4.3 -fPIC -O2 3.460s gcc-4.0.0 -fPIC -O2 4.050s gcc-2.95.3 -fPIC -O3 3.400s gcc-3.4.3 -fPIC -O3 3.740s gcc-4.0.0 -fPIC -O3 4.010s This test was done on a pentium 4 workstation, and no smoothing was done on the resulting times, but they seemed to be repeatable. We also tried without -fPIC, but did not see as large a regression there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19923
[Bug target/19923] openssl is slower when compiled with gcc 4.0 than 3.3
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-01 20:55 --- I would not doubt this is just not using the i386 address mode -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19923
[Bug java/21722] gcj miscompiles accesses to static final vars with indirect dispatch
--- Additional Comments From matz at suse dot de 2005-06-01 20:59 --- Yes. I think this is because the compiler needs to see the definition and the use site to exhibit this bug. Without the def it will correctly emit the code walking the table to get to the member. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21722
[Bug middle-end/21275] [4.0/4.1 Regression] gcc 4.0.0 crash with mingw when using stdout in global var
--- Additional Comments From dannysmith at users dot sourceforge dot net 2005-06-01 21:02 --- The patch referred to in comment #9 had missing hunks. Complete patch here: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02945.html Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21275
[Bug java/1259] string constants not handled properly
--- Additional Comments From tromey at gcc dot gnu dot org 2005-06-01 21:12 --- One example of a failure is the test case in PR 21722. In this PR we generate this bytecode in A.class: 0: ldc #9= 2: astore_1 3: getstatic #15= 6: aload_1 7: invokevirtual #21= However, as B.FOO is a compile-time constant, we should not have a 'getstatic' here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1259
[Bug middle-end/21478] Improve initialization of sparse local arrays
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-01 21:34 --- Subject: Bug 21478 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-01 21:34:28 Modified files: gcc: ChangeLog gimplify.c Log message: PR 21478 * gimplify.c (gimplify_init_constructor): Don't spill initializer to read-only memory if it's sparse. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8987&r2=2.8988 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gimplify.c.diff?cvsroot=gcc&r1=2.130&r2=2.131 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21478
[Bug java/21722] gcj miscompiles accesses to static final vars with indirect dispatch
--- Additional Comments From tromey at gcc dot gnu dot org 2005-06-01 21:36 --- I'm testing a patch. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-05-23 18:03:47 |2005-06-01 21:36:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21722
[Bug middle-end/21059] Bogus warning about clobbered variable
--- Additional Comments From sje at cup dot hp dot com 2005-06-01 22:08 --- It is not clear to me if this bug is about whether or not we should put out the message or if it is about the format of the message, I.e. that the quotes are messed up. -- What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21059
[Bug libgcj/20435] regex pattern compiling bug
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-01 22:11 --- Subject: Bug 20435 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-01 22:11:00 Modified files: libjava: ChangeLog libjava/gnu/regexp: RE.java RESyntax.java RETokenRepeated.java libjava/java/util/regex: Pattern.java Log message: 2005-06-01 Ziga Mahkovec <[EMAIL PROTECTED]> PR libgcj/20435: * gnu/regexp/RESyntax.java (RE_POSSESSIVE_OPS): New field. (static): Add possessive matching to JAVA_1_4 syntax. * gnu/regexp/RETokenRepeated.java (possessive): New field. (makePossessive, isPossessive): New methods. (match): Don't back off during possessive matching. * gnu/regexp/RE.java (initalize): Accept possessive quantifier. * java/util/regex/Pattern.java (constructor): Switch syntax from PERL5 to JAVA_1_4. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&r1=1.3643&r2=1.3644 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/gnu/regexp/RE.java.diff?cvsroot=gcc&r1=1.4&r2=1.5 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/gnu/regexp/RESyntax.java.diff?cvsroot=gcc&r1=1.1&r2=1.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/gnu/regexp/RETokenRepeated.java.diff?cvsroot=gcc&r1=1.1&r2=1.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/util/regex/Pattern.java.diff?cvsroot=gcc&r1=1.8&r2=1.9 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20435
[Bug target/20082] unrecognizable insn
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-01 22:47 --- No feedback in 3 months. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20082
[Bug target/19923] openssl is slower when compiled with gcc 4.0 than 3.3
--- Additional Comments From giovannibajo at libero dot it 2005-06-01 22:55 --- Confirmed. The regression appears only with -fPIC, and it's pretty evident. The core is md2_block, the inner loop: GCC 3.4 = .L29: xorl%edx, %edx .p2align 2,,3 .L28: movl[EMAIL PROTECTED](%ebx,%eax,4), %esi xorl-216(%ebp,%edx,4), %esi movl[EMAIL PROTECTED](%ebx,%esi,4), %eax xorl-212(%ebp,%edx,4), %eax movl[EMAIL PROTECTED](%ebx,%eax,4), %edi xorl-208(%ebp,%edx,4), %edi movl%esi, -216(%ebp,%edx,4) movl[EMAIL PROTECTED](%ebx,%edi,4), %esi xorl-204(%ebp,%edx,4), %esi movl%eax, -212(%ebp,%edx,4) movl[EMAIL PROTECTED](%ebx,%esi,4), %eax xorl-200(%ebp,%edx,4), %eax movl%edi, -208(%ebp,%edx,4) movl[EMAIL PROTECTED](%ebx,%eax,4), %edi xorl-196(%ebp,%edx,4), %edi movl%esi, -204(%ebp,%edx,4) movl[EMAIL PROTECTED](%ebx,%edi,4), %esi xorl-192(%ebp,%edx,4), %esi movl%eax, -200(%ebp,%edx,4) movl[EMAIL PROTECTED](%ebx,%esi,4), %eax xorl-188(%ebp,%edx,4), %eax movl%edi, -196(%ebp,%edx,4) movl%esi, -192(%ebp,%edx,4) movl%eax, -188(%ebp,%edx,4) addl$8, %edx cmpl$47, %edx jle .L28 addl%ecx, %eax incl%ecx andl$255, %eax cmpl$17, %ecx jle .L29 = GCC 4.0 = .L16: movl-384(%ebp), %eax movl-208(%ebp), %esi incl-384(%ebp) addl%esi, %eax movl-456(%ebp), %esi andl$255, %eax movl(%edi,%eax,4), %ecx movl-464(%ebp), %eax xorl%ecx, %esi movl(%edi,%esi,4), %edx movl%esi, -368(%ebp) movl%esi, -456(%ebp) movl-488(%ebp), %esi xorl%edx, %eax movl-472(%ebp), %edx movl(%edi,%eax,4), %ecx movl(%edi,%eax,4), %ecx movl%eax, -364(%ebp) movl%eax, -464(%ebp) xorl%ecx, %edx movl-480(%ebp), %ecx movl(%edi,%edx,4), %eax movl%edx, -360(%ebp) movl%edx, -472(%ebp) xorl%eax, %ecx movl(%edi,%ecx,4), %eax movl%ecx, -356(%ebp) movl%ecx, -480(%ebp) xorl%eax, %esi movl-496(%ebp), %eax movl(%edi,%esi,4), %edx movl%esi, -352(%ebp) movl%esi, -488(%ebp) xorl%edx, %eax movl-504(%ebp), %edx movl(%edi,%eax,4), %ecx movl%eax, -348(%ebp) movl%eax, -496(%ebp) xorl%ecx, %edx movl-512(%ebp), %ecx movl(%edi,%edx,4), %eax movl%edx, -344(%ebp) movl%edx, -504(%ebp) xorl%eax, %ecx movl%ecx, -340(%ebp) movl(%edi,%ecx,4), %eax movl-520(%ebp), %esi movl%ecx, -512(%ebp) xorl%eax, %esi movl-528(%ebp), %eax movl(%edi,%esi,4), %edx movl%esi, -336(%ebp) movl%esi, -520(%ebp) movl-552(%ebp), %esi xorl%edx, %eax movl-536(%ebp), %edx movl(%edi,%eax,4), %ecx movl%eax, -332(%ebp) movl%eax, -528(%ebp) xorl%ecx, %edx movl-544(%ebp), %ecx movl(%edi,%edx,4), %eax movl%edx, -328(%ebp) movl%edx, -536(%ebp) xorl%eax, %ecx movl(%edi,%ecx,4), %eax movl%ecx, -324(%ebp) movl%ecx, -544(%ebp) xorl%eax, %esi movl-556(%ebp), %eax movl(%edi,%esi,4), %edx movl%esi, -320(%ebp) movl%esi, -552(%ebp) movl-568(%ebp), %esi xorl%edx, %eax movl-560(%ebp), %edx movl(%edi,%eax,4), %ecx movl%eax, -316(%ebp) movl%eax, -556(%ebp) xorl%ecx, %edx movl-564(%ebp), %ecx movl(%edi,%edx,4), %eax movl%edx, -312(%ebp) movl%edx, -560(%ebp) xorl%eax, %ecx movl(%edi,%ecx,4), %eax movl%ecx, -308(%ebp) movl%ecx, -564(%ebp) xorl%eax, %esi movl%esi, -304(%ebp) movl(%edi,%esi,4), %edx movl-572(%ebp), %eax movl%esi, -568(%ebp) movl-396(%ebp), %esi xorl%edx, %eax movl-576(%ebp), %edx movl(%edi,%eax,4), %ecx movl%eax, -300(%ebp) movl%eax, -572(%ebp) xorl%ecx, %edx movl-580(%ebp), %ecx
[Bug target/19923] openssl is slower when compiled with gcc 4.0 than 3.3
--- Additional Comments From giovannibajo at libero dot it 2005-06-01 22:59 --- I wonder if this is fixed by TARGET_MEM_REF. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19923
[Bug middle-end/21059] Bogus warning about clobbered variable
--- Additional Comments From schwab at suse dot de 2005-06-01 23:03 --- The warning is just wrong. There is nothing that can be clobbered by longjmp. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21059
