[Bug awt/19843] AWT program ignores System.exit()
--- Additional Comments From fitzsim at redhat dot com 2005-08-21 05:39 --- Fixed, closing. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19843
[Bug awt/19839] Repaint-loop due to createImage() and non-null ImageObserver
--- Additional Comments From fitzsim at redhat dot com 2005-08-21 05:38 --- This prints: Got the image: [EMAIL PROTECTED] paint 1 1 repaints, probably ok. Fixed by Sven's image work. Closing. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19839
[Bug awt/16824] GdkPixbufDecoder crashes with image loading programs
--- Additional Comments From fitzsim at redhat dot com 2005-08-21 05:35 --- Do you have an example program for this? I suspect this was fixed by Sven's image work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16824
[Bug awt/16822] Graphics.setClip(null) should remove clip
--- Additional Comments From fitzsim at redhat dot com 2005-08-21 05:32 --- Fixed by: 2005-08-21 Thomas Fitzsimmons <[EMAIL PROTECTED]> * gnu/java/awt/peer/gtk/GdkGraphics.java (setClip(Shape)): Clear clip when clip == null. * gnu/java/awt/peer/gtk/GdkGraphics2D.java (setClip(Shape)): Likewise. Closing. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16822
[Bug awt/19840] drawImage bug
--- Additional Comments From fitzsim at redhat dot com 2005-08-21 05:08 --- Fixed in GNU Classpath by Sven de Marothy. Closing. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19840
[Bug swing/16540] GlassPane intercepting of MouseEvents flaky.
-- What|Removed |Added AssignedTo|graydon at redhat dot com |langel at redhat dot com Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16540
[Bug swing/21635] GLib-GObject-WARNING with jython
--- Additional Comments From fitzsim at redhat dot com 2005-08-21 00:58 --- I tried to run this under JamVM+Classpath: $ jamvm -Dpython.home="/home/fitzsim/jython-2.1" -classpath "/home/fitzsim/jython-2.1/jython.jar" "org.python.util.jython" Jython 2.1 on java1.4.2 (JIT: ) >>> import javax.swing as swing Traceback (innermost last): File "", line 1, in ? ImportError: no module named javax >>> Any idea what I'm missing? -- What|Removed |Added AssignedTo|graydon at redhat dot com |fitzsim at redhat dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-21 00:58:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21635
[Bug libgcj/23499] [4.1 regression] libgcj/classpath create empty directory $PREFIX/share/classpath/api/
--- Additional Comments From tromey at gcc dot gnu dot org 2005-08-21 00:31 --- Thanks, I'll handle this -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-08-20 18:40:09 |2005-08-21 00:31:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23499
[Bug libgcj/23498] [4.1 regression] libgcj/classpath add two undesired info files: hacking.info, vmintegration.info
--- Additional Comments From tromey at gcc dot gnu dot org 2005-08-21 00:31 --- Thanks, I'll handle this. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-08-20 18:40:00 |2005-08-21 00:31:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23498
[Bug java/20597] [meta-bug] missing Java 1.4 support
-- Bug 20597 depends on bug 17463, which changed state. Bug 17463 Summary: new methods introduced in JDK 1.4 missing in java.awt.Window http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17463 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20597
[Bug awt/17463] new methods introduced in JDK 1.4 missing in java.awt.Window
--- Additional Comments From fitzsim at redhat dot com 2005-08-21 00:31 --- Fixed in GNU Classpath. Closing. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17463
[Bug awt/20782] jawt assertion failure
--- Additional Comments From fitzsim at redhat dot com 2005-08-21 00:12 --- This suggests that a paint event is being delivered to the Canvas before the canvas's peer has been shown. I don't think this should ever happen though. We'll re-test this when my latest round of jawt patches have beem imported into libgcj. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20782
[Bug c/8268] no compile time array index checking
--- Additional Comments From falk at debian dot org 2005-08-21 00:05 --- (In reply to comment #9) > If we really wanted to tackle this better a compile-time, we'd run a > pass to look at all the ARRAY_REFs for those which have an out-of-range > index. It wouldn't be terribly hard to stick one in just before we > leave SSA form. I'll give this a try. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |falk at debian dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug awt/21747] JAWT_X11DrawingSurfaceInfo missing depth field
--- Additional Comments From fitzsim at redhat dot com 2005-08-21 00:00 --- Fixed in Classpath. Closing. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21747
[Bug target/23485] [ia64]: Integer dvide by zero doesn't raise a signal
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-20 23:55 --- Subject: Bug 23485 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-20 23:55:07 Modified files: gcc: ChangeLog gcc/config/ia64: lib1funcs.asm Log message: 2005-08-20 H.J. Lu <[EMAIL PROTECTED]> PR target/23485 * config/ia64/lib1funcs.asm (__divdi3): Check divide by zero. (__moddi3): Likewise. (__udivdi3): Likewise. (__umoddi3): Likewise. (__divsi3): Likewise. (__modsi3): Likewise. (__udivsi3): Likewise. (__umodsi3): Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9790&r2=2.9791 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/lib1funcs.asm.diff?cvsroot=gcc&r1=1.17&r2=1.18 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23485
[Bug target/23463] [4.1 Regression] va-arg-22.c execution fails
-- What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23463
[Bug target/23464] [4.1 Regression] compat tests fail
-- What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23464
[Bug target/23504] 22_locale/money_get/get/char/5.cc fails on ppc-darwin7. because libstdc++ believes long double returns works
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-20 23:36 --- Radar 4225347. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23504
[Bug target/23504] New: 22_locale/money_get/get/char/5.cc fails on ppc-darwin7. because libstdc++ believes long double returns works
The problem here is that strtold does not work correctly on ppc-darwin because the ABI changed for long double and the size. This is just one of the problems darwin 7.0's headers and libraries. the fortran failure for large_real_kind_1.f90 is the same issue except there is no header at all because fortran does not use the C headers. The fortran failure is also on darwin8 too. I will be filing a radar (Apple's bug database) for this issue too. Though I really doubt they will fix this issue. -- Summary: 22_locale/money_get/get/char/5.cc fails on ppc-darwin7. because libstdc++ believes long double returns works Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: minor Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: powerpc-darwin7.x http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23504
[Bug tree-optimization/23396] [4.1 Regression] profiledbootstrap is broken (again)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-20 22:21 --- It sounds like this also effects i686-pc-linux-gnu also with a similar error and the same backtrace. -- What|Removed |Added GCC build triplet|powerpc-*-darwin7.9.0 | GCC host triplet|powerpc-*-darwin7.9.0 | GCC target triplet|powerpc-*-darwin7.9.0 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23396
[Bug bootstrap/22313] [4.1 Regression] gcc HEAD as of 2005/07/05 fails to profiledbootstrap
-- What|Removed |Added CC||ctice at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22313
[Bug bootstrap/22313] [4.1 Regression] gcc HEAD as of 2005/07/05 fails to profiledbootstrap
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-20 22:20 --- Actually this effects x86_64 only or if you have a local patch to turn on omit frame pointer all the time and -fasynchronous-unwind-tables which is why only x86_64 is effected on a pure sources. -- What|Removed |Added GCC build triplet|i686-ark-linux-gnu | GCC host triplet|i686-ark-linux-gnu | GCC target triplet|i686-ark-linux-gnu |x86_64-*-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22313
[Bug bootstrap/22313] [4.1 Regression] gcc HEAD as of 2005/07/05 fails to profiledbootstrap
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-20 22:18 --- *** Bug 23502 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||zlynx at acm dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22313
[Bug c/23502] GCC 4.1 generated assembly subtracts between labels in text and text.unlikely
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-20 22:18 --- There are still questions if this is a bug in binutils or gcc. *** This bug has been marked as a duplicate of 22313 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED GCC host triplet|x86_64-pc-linux-gnu |x86_64-pc-linux-gnu Resolution||DUPLICATE Summary|GCC 4.1 generated assembly |GCC 4.1 generated assembly |subtracts between labels in |subtracts between labels in |text and text.unlikely |text and text.unlikely http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23502
[Bug c/23502] New: GCC 4.1 generated assembly subtracts between labels in text and text.unlikely
During the bootstrap, the GCC build fails at gcc/attribs.c with this error:
attribs.s:514: Error: can't resolve `.text.unlikely' {.text.unlikely section} -
`.LFB96' {.text section}
Line 514 in the .s file is:
.long .LFE96-.LFB96
One label is in a .text section and the other label is in a .text.unlikely
section. I tried placing the .text.unlikely label into .text and it assembled
correctly.
The failed command is:
stage1/xgcc -Bstage1/ -B/usr/x86_64-pc-linux-gnu/bin/ -c -m64 -march=athlon64
-O2 -pipe -fprefetch-loop-arrays -fprofile-use -freorder-blocks-and-partition
-DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition
-Wmissing-format-attribute -DHAVE_CONFIG_H-I. -I.
-I/var/tmp/portage/gcc-4.1.0_beta20050819/work/gcc-4.1-20050819/gcc
-I/var/tmp/portage/gcc-4.1.0_beta20050819/work/gcc-4.1-20050819/gcc/.
-I/var/tmp/portage/gcc-4.1.0_beta20050819/work/gcc-4.1-20050819/gcc/../include
-I/var/tmp/portage/gcc-4.1.0_beta20050819/work/gcc-4.1-20050819/gcc/../libcpp/include
/var/tmp/portage/gcc-4.1.0_beta20050819/work/gcc-4.1-20050819/gcc/attribs.c -o
attribs.o
This is in the last bit of the build, using profile feedback to optimize.
--
Summary: GCC 4.1 generated assembly subtracts between labels in
text and text.unlikely
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zlynx at acm dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23502
[Bug middle-end/23462] [4.1 Regression] 27_io/basic_filebuf/sgetn/char/[12]-i[no].cc execution tests fail
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-20 22:10 --- Which might mean that libstdc++ is mis-compiled. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23462
[Bug middle-end/23462] [4.1 Regression] 27_io/basic_filebuf/sgetn/char/[12]-i[no].cc execution tests fail
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-20 22:08 --- These also fail at -O0. -- What|Removed |Added Component|tree-optimization |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23462
[Bug c++/23172] [4.1 Regression] ICE on integer initialization
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-20 21:51 --- I am going to punt as the last example did not work in 2.95.3-4.0.0 also and that is the only example in this whole bug which is really valid C99. -- What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |giovannibajo at libero dot |org |it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23172
[Bug c++/23172] [4.1 Regression] ICE on integer initialization
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-20
21:47 ---
Another testcase:
int *f = &(int){0};
This one is valid C99 also.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23172
[Bug c++/23172] [4.1 Regression] ICE on integer initialization
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-20 21:29 --- I have a fix for this (really I am writting a fix). -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23172
[Bug c++/23172] [4.1 Regression] ICE on integer initialization
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-20
21:27 ---
_Complex double i = (_Complex double){0.,1.0};
Also ICE but with a differnet error message:
t.cc:1: internal compiler error: in process_init_constructor, at
cp/typeck2.c:1041
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
Complex should be handled the same as a scalar.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23172
[Bug target/22093] Unaligned access to HI values causes unrecognizable insn error
--- Additional Comments From falk at debian dot org 2005-08-20 21:10 --- (In reply to comment #0) > If I change line 3043 in alpha.c to load unaligned address of operand[0] into > the > register and pass it to unaligned_storehi() everything works. That seems like the right thing to do. Can you please send a patch to gcc-patches, preferably with test suite results? -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22093
[Bug c++/23172] [4.1 Regression] ICE on integer initialization
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-20 21:09 --- Hmm, this is not even valid C99, and we reject it in the C front-end with "-std=c99 -pedantic-errors": t.c:1: error: initializer element is not constant Though we should not seg fault. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23172
[Bug rtl-optimization/22239] [4.0 Regression] i-cobol.adb:482: error: unrecognizable insn
-- What|Removed |Added GCC build triplet|hppa-unknown-linux-gnu |hppa-*-linux-gnu GCC host triplet|hppa-unknown-linux-gnu |hppa-*-linux-gnu GCC target triplet|hppa-unknown-linux-gnu |hppa-*-linux-gnu Summary|[4.0/4.1 Regression] i- |[4.0 Regression] i- |cobol.adb:482: error: |cobol.adb:482: error: |unrecognizable insn |unrecognizable insn http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22239
[Bug c/23501] pp_base_format_text ought to recognise "m$" directives
--- Additional Comments From goeran at uddeborg dot se 2005-08-20 20:52 --- Great! (That answer was quick! :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23501
[Bug target/21623] [4.0 regression] ICE in reload_cse_simplify_operands, at postreload.c:391
-- What|Removed |Added GCC target triplet|sh4-unknown-gnu-linux |sh4-*-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21623
[Bug c/23501] pp_base_format_text ought to recognise "m$" directives
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-20 20:40 --- Already fixed for 4.1.0 by: 2005-06-30 Zack Weinberg <[EMAIL PROTECTED]> Jakub Jelinek <[EMAIL PROTECTED]> * pretty-print.h (PP_NL_ARGMAX): New. (text_info): Add locus. (struct chunk_info): New. (output_buffer): Add formatted_obstack, chunk_obstack, and cur_chunk_array. Change obstack to a pointer. (pp_wrapping_mode_t, pp_wrapping_mode, pp_set_verbatim_wrapping): New. (struct pretty_print_info): Replace ideal_maximum_length and prefixing_rule with wrapping. (pp_line_cutoff, pp_prefixing_rule): Update to match. Update prototypes and wrapper macros throughout. * pretty-print.c (pp_formatted_text_data, pp_append_r) (pp_base_clear_output_area, pp_construct, pp_base_formatted_text) (pp_base_last_position_in_text, pp_base_newline, pp_base_character): Update for changes to pp structure. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23501
[Bug c++/23172] [4.1 Regression] ICE on integer initialization
--- Additional Comments From phython at gcc dot gnu dot org 2005-08-20
20:38 ---
int i = (int){1, 2} segfaults as well, and no longer gives an error.
I suspect it was the following patch:
2005-07-20 Giovanni Bajo <[EMAIL PROTECTED]>
Make CONSTRUCTOR use VEC to store initializers.
...
(digest_init): Rewrite.
...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23172
[Bug c++/20624] [4.0 Regression] wrong "control reaches end of non-void function" warning
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-20 20:37 --- Fixed in 4.0.2 and above. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20624
[Bug c++/20624] [4.0 Regression] wrong "control reaches end of non-void function" warning
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-20 20:37 --- Subject: Bug 20624 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-08-20 20:37:14 Modified files: gcc: ChangeLog gimple-low.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/warn: Wreturn-3.C Log message: 2005-08-20 Andrew Pinski <[EMAIL PROTECTED]> PR middle-end/20624 * gimple-low.c (block_may_fallthru): Handle CLEANUP_POINT_EXPR by looking past it. 2005-08-20 Andrew Pinski <[EMAIL PROTECTED]> PR middle-end/20624 * g++.dg/warn/Wreturn-3.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.379&r2=2.7592.2.380 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gimple-low.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.22&r2=2.22.8.1 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.340&r2=1.5084.2.341 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/warn/Wreturn-3.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=20624
[Bug c/23501] New: pp_base_format_text ought to recognise "m$" directives
When translating the message %s ignored with %s and %<%%%c%> %s format I wanted to switch order of the arguments to get a natural message in Swedish. So I tried with %1$s ignorerad med %2$s och %4$s-format %<%%%3$c%> That fails, however, with a message c.c:5: internal compiler error: in pp_base_format_text, at pretty-print.c:374 And looking at the code, it does indeed not seem to recognise the "m$" construct. But I think it would be reasonable for it to do so. It will be hard to translate all messages passed through that function to all languages without changing the order of the arguments in any of them. -- Summary: pp_base_format_text ought to recognise "m$" directives Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: goeran at uddeborg dot se CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23501
[Bug c/23493] += operator does now work as expected, I have gdb session saved
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-20 20:32 --- Closing as invalid then. -- What|Removed |Added Status|SUSPENDED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23493
[Bug c/23493] += operator does now work as expected, I have gdb session saved
--- Additional Comments From communa at ua dot fm 2005-08-20 20:30 --- Sorry I can not reproduce the bug :( I just recompile binary and it works fine :( I lose old binary and maybe some changes in source files I made in order to catch the bug Sorry, Dmytro P.S. if you still need my source - tell me, I think it does nothing to you without a bug (this is a useless program) -- What|Removed |Added Status|WAITING |SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23493
[Bug libgcj/21692] [4.1 Regression] unexpected java.lang.NoClassDefFoundError
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-20 20:26 --- Subject: Bug 21692 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-20 20:26:26 Modified files: libjava: ChangeLog configure.host Added files: libjava/sysdep/pa: descriptor.h Log message: PR libgcj/21692 * sysdep/pa/descriptor.h: New file. * configure.host: Use sysdep/pa/descriptor.h on hppa*-*. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&r1=1.3722&r2=1.3723 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/configure.host.diff?cvsroot=gcc&r1=1.70&r2=1.71 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/sysdep/pa/descriptor.h.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21692
[Bug java/23500] Optimization: Skip _Jv_InitClass for intra-class static method calls
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-20 20:10 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2005-08-20 20:10:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23500
[Bug tree-optimization/23486] [4.1 Regression] ICE in execute_todo, at passes.c:677
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-08-20 20:05 --- Caused by http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00283.html, ssa update needs to be added to final value replacement pass. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23486
[Bug java/23500] New: Optimization: Skip _Jv_InitClass for intra-class static method calls
Java requires a class initialization check when any public static method is called. But when we are calling from another method in the _same_ class, we already know that the class has been initialized, so we can optimize away the call to _Jv_InitClass, even if we're not inlining. Here's how: Reorder the call, so that this (on x86): .globl _ZN4Test10assertHackEb .type _ZN4Test10assertHackEb, @function _ZN4Test10assertHackEb: .LFB5: .file 1 "Test.java" .loc 1 43 0 .LVL0: pushl %ebp .LCFI0: movl%esp, %ebp .LCFI1: pushl %ebx .LCFI2: subl$16, %esp .LCFI3: movb8(%ebp), %bl .loc 1 43 0 pushl $_ZN4Test6class$E .LCFI4: call_Jv_InitClass becomes something like this: .globl _ZN4Test10assertHackEb .type _ZN4Test10assertHackEb, @function _ZN4Test10assertHackEb: .LFB5: .file 1 "Test.java" .loc 1 43 0 pushl $_ZN4Test6class$E .LCFI4: call_Jv_InitClass .LVL0: pushl %ebp .LCFI0: movl%esp, %ebp .LCFI1: pushl %ebx .LCFI2: subl$16, %esp .LCFI3: movb8(%ebp), %bl and intra-class method calls to that method, call to .LVL0 instead of _ZN4Test10assertHackEb. -- Summary: Optimization: Skip _Jv_InitClass for intra-class static method calls Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: greenrd at greenrd 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=23500
[Bug libstdc++/23497] [4.1 regression] Bogus 'is used uninitialized...' warning about std::complex
--- Additional Comments From jan at etpmod dot phys dot tue dot nl 2005-08-20 19:58 --- (In reply to comment #1) > I can confirm this on alphaev68-linux, even without -g. C test case: > -g should have been -Wall. Sorry about that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23497
[Bug libgcj/23495] java.lang.String.equals is suboptimal
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-20 19:41 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-20 19:41:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23495
[Bug java/18399] Class initialization optimization does not work with the inliner
-- What|Removed |Added Target Milestone|4.0.1 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18399
[Bug java/18399] Class initialization optimization does not work with the inliner
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-20 19:31 --- I should copy and paste the full tree dump: : _Jv_InitClass (&t.class); n = 0; :; _Jv_InitClass (&t.class); n = n + 1; ; if (n == 1000) goto ; else goto ; The call to _Jv_InitClass is in the inner loop which causes a slow down and use not to be able to remove the loop. -- What|Removed |Added Status|REOPENED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18399
[Bug java/17574] [meta-bug] gcj and libgcj 4.0 tracking PR
-- Bug 17574 depends on bug 18399, which changed state. Bug 18399 Summary: Class initialization optimization does not work with the inliner http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18399 What|Old Value |New Value Status|RESOLVED|REOPENED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17574
[Bug java/18399] Class initialization optimization does not work with the inliner
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-20 19:29 --- Actually this still does not work: >From .final_cleanup: :; _Jv_InitClass (&t.class); ; i = i + 1; if (i == 1000) goto ; else goto ; -- What|Removed |Added Severity|minor |enhancement Status|RESOLVED|REOPENED Resolution|WONTFIX | Summary|[4.0/4.1 Regression] Class |Class initialization |initialization optimization |optimization does not work |does not work with the |with the inliner |inliner | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18399
[Bug middle-end/22366] [meta-bug] issues holding up the removal of loop.c
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-08-20 19:21 --- Sorry, haven't read the instructions (only the title of the metabug :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22366
[Bug middle-end/22366] [meta-bug] issues holding up the removal of loop.c
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-08-20 19:18 --- This is not an issue blocking removal of loop.c (if anything, it is in favor of removal of loop.c). -- What|Removed |Added BugsThisDependsOn|13300 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22366
[Bug libgcj/23495] java.lang.String.equals is suboptimal
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-20 19:10 --- Hmm, doing a profiling, I noticed that equals does its own loop instead of using memcmp which is most likely more efficient as memcmp is optimized for each target by the OS. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23495
[Bug libstdc++/23494] std::basic_string <> capacity weirdness
--- Additional Comments From pogonyshev at gmx dot net 2005-08-20 18:48 --- Because it defeats the effect of reserve() call on `s1'. I'm not saying I know how to avoid it, but I wonder if there is some strict policy behind `std::basic_string' reallocation behavior in GNU STL. Maybe this example shows that the policy is not implemented properly. I think this example shows a perfectly common usage of strings where you reserve space for all the things you are going to stuff in the string and then make a copy of an intermediate results. With current GNU STL behavior, this doesn't work as expected, though, of course, it *will* give the correct result, it is only about optimizations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23494
[Bug libgcj/23499] [4.1 regression] libgcj/classpath create empty directory $PREFIX/share/classpath/api/
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-20 18:40:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23499
[Bug libgcj/23498] [4.1 regression] libgcj/classpath add two undesired info files: hacking.info, vmintegration.info
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-20 18:40:00 date|| Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23498
[Bug libgcj/23499] [4.1 regression] libgcj/classpath create empty directory $PREFIX/share/classpath/api/
-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23499
[Bug c/18851] IMA is slow and could be sped up
--- Additional Comments From andreas dot meier_ at gmx dot de 2005-08-20 18:39 --- Under http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02316.html the patch was okayed with small changes. Can it be in 4.1.0? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18851
[Bug libstdc++/23494] std::basic_string <> capacity weirdness
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-20 18:34 --- Why do you think this is a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23494
[Bug target/23485] [ia64]: Integer dvide by zero doesn't raise a signal
--- Additional Comments From hjl at lucon dot org 2005-08-20 18:33 --- A patch for inlined calls is posted at http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01223.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23485
[Bug libstdc++/23497] [4.1 regression] Bogus 'is used uninitialized...' warning about std::complex
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-20 18:27 --- This is a bug in libstdc++ headers. Since complex has been come a "scalar" and cannot be loaded piece wise. -- What|Removed |Added Component|c++ |libstdc++ Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23497
[Bug c++/23496] gcc cant find base class template members
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-20 18:23 --- (In reply to comment #0) > i'd be happy if someone could rethink the decisions on this. If you can get the standard committe to, then we will. Other than that, we will not. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23496
[Bug c++/23497] [4.1 regression] Bogus 'is used uninitialized...' warning about std::complex
--- Additional Comments From falk at debian dot org 2005-08-20 17:38
---
I can confirm this on alphaev68-linux, even without -g. C test case:
void f() {
__complex__ double t;
__imag__ t = 0;
}
Was introduced somewhere between 2005-05-17 and 2005-06-30.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Keywords||diagnostic
Known to fail||4.1.0
Known to work||3.4.5 4.0.2
Summary|[REGRESSION] Bogus 'is used |[4.1 regression] Bogus 'is
|uninitialized...' warning |used uninitialized...'
|about std::complex |warning about
||std::complex
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23497
[Bug libgcj/23499] New: [4.1 regression] libgcj/classpath create empty directory $PREFIX/share/classpath/api/
After the classpath/libgcj import, installation creates a new directory $PREFIX/share/classpath/api/ which is empty. -- Summary: [4.1 regression] libgcj/classpath create empty directory $PREFIX/share/classpath/api/ Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gerald at pfeifer dot com CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org,tromey at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23499
[Bug libgcj/23498] New: [4.1 regression] libgcj/classpath add two undesired info files: hacking.info, vmintegration.info
After the classpath merge mid-July two undesired info files are being installed: hacking.info and vmintegration.info. See http://gcc.gnu.org/ml/gcc/2005-07/msg00779.html for the original report and Tom Tromey's confirmation that these are undesirable. -- Summary: [4.1 regression] libgcj/classpath add two undesired info files: hacking.info, vmintegration.info Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gerald at pfeifer dot com CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org,tromey at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23498
[Bug c++/23497] New: [REGRESSION] Bogus 'is used uninitialized...' warning about std::complex
With today's trunk,
#include
void f()
{
std::complex c1(.0),c2(.0);
c1*=c2;
}
g++ -c -O2 -Wall uninit.cpp
Gives:
/home/jan/local/gcc-head/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../include/c++/4.1.0/complex:1289:
warning: ‘__t’ is used uninitialized in this function
Which is bogus. This hapens only when optimizing with -O[123] AND -g.
--
Summary: [REGRESSION] Bogus 'is used uninitialized...' warning
about std::complex
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan at etpmod dot phys dot tue dot nl
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-suse-linux
GCC host triplet: i686-suse-linux
GCC target triplet: i686-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23497
[Bug middle-end/22366] [meta-bug] issues holding up the removal of loop.c
--- Additional Comments From falk at debian dot org 2005-08-20 16:56 --- Bug 13300 is about a bad assumption with respect to overflow and sign extensions in loop.c. -- What|Removed |Added BugsThisDependsOn||13300 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22366
[Bug c++/23496] New: gcc cant find base class template members
following minimal reproduce fails with gcc 4.0.1:
template
class TVector
{
public:
T x,y,z,w;
};
template
class TQuaternion : public TVector
{
public:
T Sum()
{
return x+y+z+w;
}
};
the output produced is:
g++ -rdynamic -c -o test.o test.cpp
test.cpp: In member function 'T TQuaternion::Sum()':
test.cpp:15: error: 'x' was not declared in this scope
test.cpp:15: error: 'y' was not declared in this scope
test.cpp:15: error: 'z' was not declared in this scope
test.cpp:15: error: 'w' was not declared in this scope
this should better work. it does e.g. in msvc.
i'm aware of e.g.
http://developer.apple.com/documentation/DeveloperTools/gcc-4.0.0/gcc/Name-lookup.html
requirements as mentioned in the document above clutter the code tremendously.
the complete code that this reproduce bases on also includes complex matrix
operation code, imagine how it looks after its made valid.
i'd be happy if someone could rethink the decisions on this.
--
Summary: gcc cant find base class template members
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gccbugs at paniq dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23496
[Bug libgcj/23495] java.lang.String.equals is suboptimal
--- Additional Comments From greenrd at greenrd dot org 2005-08-20 16:29 --- Created an attachment (id=9549) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9549&action=view) Benchmark This is the equality benchmark I used. Uncomment the //ca [0] = 'b'; line and negate the assertion to convert it into an inequality benchmark. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23495
[Bug libgcj/23495] New: java.lang.String.equals is suboptimal
I can see a way to improve the speed of java.lang.String.equals. On x86, sizeof(void *) is 2*sizeof(jchar), whilst on x86_64, sizeof (void *) is 4*sizeof(jchar). So it should be more efficient to compare as many elements as possible in batches of 2 (on e.g. x86) or 4 (on e.g. x86_64), by casting the arrays to void **. (If length % 2 != 0, it is not possible to compare all the elements in this way, of course, but all but the last can be.) My LD_PRELOAD tests show performance improvements of up to 49% for comparing two equal 10-character strings with this change, and up to 91% for comparing two equal 110-character strings. There is no significant degradation for the common case where the two strings differ in the first character, nor for the case of very small equal strings. These results were obtained on x86 with -O2 -g -march=athlon-xp (without -march=athlon-xp the improvements are smaller). I would expect the improvements to be even better on x86_64, because it can compare 4 jchars at a time. I haven't investigated alignment issues, however. It's possible that this change will not be faster for all arches, in which case it could be maybe #ifdef'd. -- Summary: java.lang.String.equals is suboptimal Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: minor Priority: P2 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: greenrd at greenrd 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=23495
[Bug libstdc++/23494] New: std::basic_string <> capacity weirdness
Whether capacity of strings shrinks depends on whether the strings are shared.
I believe this also true for 4.0.1, but I only have the sources of it, didn't
compile.
To reproduce (note that `s2' is not shared at the time of push):
int
main()
{
string s1;
s1.reserve (1);
string s2 = s1;
s1.push_back ('!');
s2.push_back ('!');
cout << "s1 capacity: " << s1.capacity () << endl;
cout << "s2 capacity: " << s2.capacity () << endl;
return 0;
}
Output (here):
s1 capacity: 1
s2 capacity: 12259
--
Summary: std::basic_string <> capacity weirdness
Product: gcc
Version: 3.2
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pogonyshev at gmx dot net
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23494
[Bug c/23493] += operator does now work as expected, I have gdb session saved
--- Additional Comments From falk at debian dot org 2005-08-20 16:19 --- (In reply to comment #0) > Oh! You have a t complicated way to report bug. We are always eager to improve the process. Maybe you could tell us what you tried to report this bug and where you had trouble? > If you need my full program - let me know - I'll save it for you. We need your full program. Please use the "Create a New Attachment" function at the URL below. -- What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23493
[Bug middle-end/23369] [4.0/4.1 regression] build_range_check generates wrong code for funcptr comparison
--- Additional Comments From danglin at gcc dot gnu dot org 2005-08-20 16:15 --- Fixed in 4.0.2 and 4.1.0. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23369
[Bug testsuite/23239] gcc.dg/tree-prof/val-prof-5.c scan-tree-dump Div.mod by constant b..=997 transformation on insn fails
--- Additional Comments From danglin at gcc dot gnu dot org 2005-08-20 16:11 --- Fixed by patch. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23239
[Bug testsuite/23239] gcc.dg/tree-prof/val-prof-5.c scan-tree-dump Div.mod by constant b..=997 transformation on insn fails
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-20 16:09 --- Subject: Bug 23239 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-20 16:08:52 Modified files: gcc/testsuite : ChangeLog gcc/testsuite/gcc.dg/tree-prof: val-prof-5.c Log message: PR testsuite/23239 * gcc.dg/tree-prof/val-prof-5.c: Fix scan-tree-dump regexp. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5941&r2=1.5942 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-prof/val-prof-5.c.diff?cvsroot=gcc&r1=1.1&r2=1.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23239
[Bug tree-optimization/23476] [4.1 Regression] ICE in VRP, remove_range_assertions
--- Additional Comments From roger at eyesopen dot com 2005-08-20 15:27 --- My apologies for adding a comment to an already resolved PR, but I've some follow-up thoughts on Diego's recent solution to this regression. From a high-level perspective, it would probably be more efficient to require that conditions are always folded as an invariant of our tree-ssa data structures. It's better to fold a conditional once when it is constructed/modified, rather than need to call fold on it each time it is examined. Some places that build/modify conditionals may know that fold doesn't need to be (or has already been) called, whilst requiring the many places that examine CFGs to call fold themselves is pessimistic. This also fits well with our recent "folded by construction" philosophy, using fold_buildN instead of build. I appreciate that this a meta-issue, and Diego's fix is fine for this problem, but ultimately I think that placing stricter invariants on our data structures will reduce the number of unnecessary calls to fold, and speed up the compiler. Eventually, most calls to build* should be fold_build*, and it should rarely be necessary to call fold() without a call to build (or in place modification of a tree). But perhaps there a valid tree-ssa reasons why this shouldn't be a long-term goal? -- What|Removed |Added CC||roger at eyesopen dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23476
[Bug target/23485] [ia64]: Integer dvide by zero doesn't raise a signal
--- Additional Comments From hjl at lucon dot org 2005-08-20 15:18 --- We also need to check divide-by-zero for -minline-int-divide-min-latency and -minline-int-divide-max-throughput. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23485
[Bug c/23493] New: += operator does now work as expected, I have gdb session saved
Oh! You have a t complicated way to report bug.
Ok, += operator works only one time in my program later this act as simple =
I'll send you my saved gdb session. I saved the full session, but only last
5-10 lines are important. If you will have a trouble with undersanding fill
free to leave message to [EMAIL PROTECTED] or [EMAIL PROTECTED] If you need my
full program - let me know - I'll save it for you.
Thank you for my Freedom,
Dmytro
start gdb session---
Starting
program: /home/project/communa/agitator/agitator ./test.agr ./test.nasm
j1
j2
j3
3
---
dvar
dima
barra
julia
kostik
5
---
Breakpoint 1, oper (sch=59 ';') at agitator.c:80
80 if(retword(buf)) { // LEFT OPERAND `if' structure
(gdb) n
84 var = -1;
(gdb)
85 for(c = 0; c < locsub; c++) {
(gdb)
86 if(iseq(buf, locs[c].name)) {
(gdb)
85 for(c = 0; c < locsub; c++) {
(gdb)
86 if(iseq(buf, locs[c].name)) {
(gdb)
85 for(c = 0; c < locsub; c++) {
(gdb)
86 if(iseq(buf, locs[c].name)) {
(gdb)
85 for(c = 0; c < locsub; c++) {
(gdb)
86 if(iseq(buf, locs[c].name)) {
(gdb)
85 for(c = 0; c < locsub; c++) {
(gdb)
92 if(var == -1) { // is our var not in `locs', then look
at `vars'
(gdb)
93 for(c = 0; c < varsub; c++) {
(gdb)
94 if(iseq(buf, vars[c].name)) {
(gdb)
93 for(c = 0; c < varsub; c++) {
(gdb)
94 if(iseq(buf, vars[c].name)) {
(gdb)
93 for(c = 0; c < varsub; c++) {
(gdb)
94 if(iseq(buf, vars[c].name)) {
(gdb)
95 var = c;
(gdb)
96 loc = 0;
(gdb)
97 break;
(gdb)
102 if(var == -1) { // not found
(gdb)
109 loper = find_free_ovar();
(gdb)
110 if(loc) {
(gdb)
116 setptr = &(vars[var]); // this is for set
member resolvation
(gdb)
117 ovars[loper].size =
types[vars[var].type].size;
(gdb)
118 ovars[loper].pos = vars[var].pos;
(gdb)
119 ovars[loper].AStype = AS_DATA;
(gdb)
124 if(retchar() == '.') {
(gdb)
125 if(!retword(buf)) {
(gdb)
131 loc = 1; // I reuse loc here as a
found flag
(gdb)
132 for(c = 0; c <
types[setptr->type].varsub; c++) {
(gdb)
133
if(iseq(types[setptr->type].vars[c].name, buf)) {
(gdb)
134 ovars[loper].pos +=
types[setptr->type].vars[c].pos;
(gdb) p ovars[loper].pos
$11 = 3
(gdb) p types[setptr->type].vars[c].pos
$12 = 0
(gdb) p ovars[loper].pos + types[setptr->type].vars[c].pos
$13 = 3
(gdb) n
135 ovars[loper].size =
types[types[setptr->type].vars[c].type].size;
(gdb) p ovars[loper].pos
$14 = 3
(gdb) n
136 setptr =
&(types[setptr->type].vars[c]); // this is for set member resolvation
(gdb)
137 loc = 0;
(gdb)
132 for(c = 0; c <
types[setptr->type].varsub; c++) {
(gdb)
133
if(iseq(types[setptr->type].vars[c].name, buf)) {
(gdb)
132 for(c = 0; c <
types[setptr->type].varsub; c++) {
(gdb)
133
if(iseq(types[setptr->type].vars[c].name, buf)) {
(gdb)
132 for(c = 0; c <
types[setptr->type].varsub; c++) {
(gdb)
140 if(loc) {
(gdb)
124 if(retchar() == '.') {
(gdb)
125 if(!retword(buf)) {
(gdb)
131 loc = 1; // I reuse loc here as a
found flag
(gdb)
132 for(c = 0; c <
types[setptr->type].varsub; c++) {
(gdb)
133
if(iseq(types[setptr->type].vars[c].name, buf)) {
(gdb)
134 ovars[loper].pos +=
types[setptr->type].vars[c].pos;
(gdb) p ovars[loper].pos
$15 = 3
(gdb) p ovars[loper].pos + types[setptr->type].vars[c].pos
$16 = 3
(gdb) p
[Bug middle-end/23237] [4.1 Regression] -O1 rejects valid code (xxx causes a section type conflict).
--- Additional Comments From jbglaw at lug-owl dot de 2005-08-20 14:04 --- I spotted this bug at some time before while doing VAX development. Taken from http://www.pergamentum.com/pipermail/linux-vax/2005-July/31.html, cvs HEAD was already broken (wrt. this bug) at Jul 24, 2005. I seem to remember that cvs HEAD was okay one or two months prior that date. Maybe this'll help you tracking it down. This issue ist still valid with current (Aug 20, 2005, 13:15 UTC) cvs HEAD. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23237
[Bug tree-optimization/23331] FIXME from tree-ssa-ccp: dealing with "a"[3]
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-20
13:54 ---
Testcase:
int f(void)
{
int a = 13;
return "a"[a];
}
This should be converted over to:
int f(void)
{
__builtin_trap ();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23331
[Bug middle-end/21990] Wrong code for 4.0 and head: Reload clobbers the frame pointer by using it as spill register without recognizing the clobbering
--- Additional Comments From bjoern dot m dot haase at web dot de 2005-08-20 13:49 --- I have re-investigated this bug today and observed that it no longer appears in mainline. It is also absent in today's cvs state of the 4.0 branch. Dunno whether the original problem has been fixed or whether something else has changed such that the bug is no longer exposed: Since the register allocator now seems to be smarter on both branches than it used to be, the function exposing the bug no longer needs the frame pointer. Yours, Björn -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21990
[Bug ada/23492] New: [4.1 Regression] ACATS c48009e SEGV in set_bb_for_stmt tree-cfg.c:2673 on x86_64
Started failing on x86_64-linux only (x86 is o) between LAST_UPDATED: Tue Aug 16 18:50:47 UTC 2005 LAST_UPDATED: Fri Aug 19 19:26:06 UTC 2005 (gdb) r -O2 -I/home/guerby/work/gcc/build/build-20050819T214115/gcc/testsuite/ada/acats/support c48009e.adb Starting program: /home/guerby/work/gcc/build/build-20050819T214115/gcc/gnat1 -O2 -I/home/guerby/work/gcc/build/build-20050819T214115/gcc/testsuite/ada/acats/support c48009e.adb C48009E C48009E.ALLOC1 C48009E.ALLOC2c48009e.adb:150:40: warning: too few elements for type "SA1_3" defined at line 65 c48009e.adb:150:40: warning: "Constraint_Error" will be raised at run time c48009e.adb:160:40: warning: upper bound of aggregate out of range c48009e.adb:160:40: warning: Constraint_Error will be raised at run-time c48009e.adb:180:40: warning: too few elements for subtype of "UA" defined at line 76 c48009e.adb:180:40: warning: "Constraint_Error" will be raised at run time c48009e.adb:190:40: warning: too many elements for subtype of "UA" defined at line 76 c48009e.adb:190:40: warning: "Constraint_Error" will be raised at run time Analyzing compilation unitPerforming intraprocedural optimizations Assembling functions: C48009E.ALLOC1 C48009E Program received signal SIGSEGV, Segmentation fault. set_bb_for_stmt (t=0x0, bb=0x2a95db3800) at /home/guerby/work/gcc/version-head/gcc/tree-cfg.c:2673 2673 if (TREE_CODE (t) == PHI_NODE) (gdb) bt #0 set_bb_for_stmt (t=0x0, bb=0x2a95db3800) at /home/guerby/work/gcc/version-head/gcc/tree-cfg.c:2673 #1 0x00980fdd in bsi_insert_after (i=0x7fb510, t=0x0, m=BSI_NEW_STMT) at /home/guerby/work/gcc/version-head/gcc/tree-cfg.c:2761 #2 0x0095f304 in setup_one_parameter (id=0x7fb5e0, p=0x2a95a74980, value=0x2a95a74980, fn=0x2a95de49a0, bb=0x2a95db3800, vars=0x7fb680) at /home/guerby/work/gcc/version-head/gcc/tree-inline.c:1142 #3 0x00961b2b in optimize_inline_calls (fn=0x2a95a45300) at /home/guerby/work/gcc/version-head/gcc/tree-inline.c:1177 #4 0x0064a268 in tree_rest_of_compilation (fndecl=0x2a95a45300) at /home/guerby/work/gcc/version-head/gcc/tree-optimize.c:393 #5 0x0041b845 in gnat_expand_body (gnu_decl=0x2a95a45300) at /home/guerby/work/gcc/version-head/gcc/ada/misc.c:636 #6 0x00964946 in cgraph_expand_function (node=0x2a95a5ff20) at /home/guerby/work/gcc/version-head/gcc/cgraphunit.c:1037 #7 0x00966a6b in cgraph_optimize () at /home/guerby/work/gcc/version-head/gcc/cgraphunit.c:1103 -- Summary: [4.1 Regression] ACATS c48009e SEGV in set_bb_for_stmt tree-cfg.c:2673 on x86_64 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: laurent at guerby dot net CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: x86_64-linux-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23492
