[Bug other/32229] New: gcc version 4 build fails with below errors
gcc: c-parse.c: No such file or directory gcc: no input files make[2]: *** [c-parse.o] Error 1 make[2]: Leaving directory `/opt/gcc-buil/gcc' make[1]: *** [stage1_build] Error 2 make[1]: Leaving directory `/opt/gcc-buil/gcc' make: *** [bootstrap] Error 2 -- Summary: gcc version 4 build fails with below errors Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tubal_d at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32229
[Bug tree-optimization/32146] Bad matrix layout transformations
--- Comment #4 from razya at il dot ibm dot com 2007-06-06 06:44 --- (In reply to comment #1) I get the same failure on powerpc64-linux-gnu. I committed the patch yesterday. ok to close the PR? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32146
[Bug tree-optimization/32230] New: [4.3 Regression] Segfault in set_bb_for_stmt with -O -ftree-vectorize
I'm getting the following segfault on trunk with -O -ftree-vectorize.
This was introduced between 20070422 and 20070515.
(sid)25522:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -O
-ftree-vectorize -c
glame-waveform.c
glame-waveform.c: In function 'const_f':
glame-waveform.c:18: warning: comparison of distinct pointer types lacks a cast
glame-waveform.c:12: internal compiler error: Segmentation fault
Please submit a full bug report, [...]
(sid)25523:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -ftree-vectorize
-c
glame-waveform.c
glame-waveform.c: In function 'const_f':
glame-waveform.c:18: warning: comparison of distinct pointer types lacks a cast
(sid)25524:[EMAIL PROTECTED]: ~]
Testcase:
typedef struct filter_buffer filter_buffer_t;
struct filter_buffer
{
char buf[1];
};
typedef struct sbuf_header sbuf_header_t;
struct sbuf_header
{
char buf[1];
}
const_f (filter_buffer_t *buf)
{
float val;
int i;
for (i = 0; i 10; i++)
((float
*) (((sbuf_header_t *) ((buf) == (buf)-buf[0]))-buf[0]))[i] = val;
}
--
Summary: [4.3 Regression] Segfault in set_bb_for_stmt with -O -
ftree-vectorize
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32230
[Bug tree-optimization/32230] [4.3 Regression] Segfault in set_bb_for_stmt with -O -ftree-vectorize
--- Comment #1 from tbm at cyrius dot com 2007-06-06 07:53 --- Program received signal SIGSEGV, Segmentation fault. set_bb_for_stmt (t=0x0, bb=0x2b91a13c9960) at gcc/gcc/tree-cfg.c:2629 2629 if (TREE_CODE (t) == PHI_NODE) (gdb) where #0 set_bb_for_stmt (t=0x0, bb=0x2b91a13c9960) at gcc/gcc/tree-cfg.c:2629 #1 0x00691a7d in bsi_insert_after (i=0x7fff0a04c690, t=0x0, m=BSI_NEW_STMT) at gcc/gcc/tree-cfg.c:2740 #2 0x00692a97 in bsi_insert_on_edge_immediate (e=value optimized out, stmt=0x0) at gcc/gcc/tree-cfg.c:3007 #3 0x00a1e309 in vect_do_peeling_for_alignment (loop_vinfo=0xf3f980) at gcc/gcc/tree-vect-transform.c:4946 #4 0x00a2c8b9 in vect_transform_loop (loop_vinfo=0xf3f980) at gcc/gcc/tree-vect-transform.c:5284 #5 0x007a7bd1 in vectorize_loops () at gcc/gcc/tree-vectorizer.c:2280 #6 0x0060c9a1 in execute_one_pass (pass=0xe370c0) at gcc/gcc/passes.c:1068 #7 0x0060cb5c in execute_pass_list (pass=0xe370c0) at gcc/gcc/passes.c:1120 #8 0x0060cb6e in execute_pass_list (pass=0xe36ee0) at gcc/gcc/passes.c:1121 #9 0x0060cb6e in execute_pass_list (pass=0xe36340) at gcc/gcc/passes.c:1121 #10 0x006da8ef in tree_rest_of_compilation (fndecl=0x2b91a13d8000) at gcc/gcc/tree-optimize.c:406 #11 0x0082cf70 in cgraph_expand_function (node=0x2b91a13d8100) at gcc/gcc/cgraphunit.c:1073 #12 0x0082eae5 in cgraph_optimize () at gcc/gcc/cgraphunit.c:1142 #13 0x00413cbe in c_write_global_declarations () at gcc/gcc/c-decl.c:7917 #14 0x006855c8 in toplev_main (argc=value optimized out, argv=value optimized out) at gcc/gcc/toplev.c:1064 #15 0x2b91a0dd28e4 in __libc_start_main () from /lib/libc.so.6 #16 0x00403f99 in _start () -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32230
[Bug tree-optimization/32231] New: [4.3 Regression] Segfault in verify_ssa_name
I'm getting the following segfault when I compile the beep-media-player application with the options -ffast-math -funroll-all-loops -g -O3: visualization.c: In function 'vis_send_data': visualization.c:270: internal compiler error: Segmentation fault Please submit a full bug report, The problem is that this segfault doesn't happen with the preprocessed source, so I've no idea how to report this properly. Any hints on this? -- Summary: [4.3 Regression] Segfault in verify_ssa_name Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32231
[Bug tree-optimization/32231] [4.3 Regression] Segfault in verify_ssa_name
--- Comment #1 from tbm at cyrius dot com 2007-06-06 08:06 ---
g_bit_nth_lsf g_bit_nth_msf g_bit_storage g_trash_stack_push g_trash_stack_pop
g_trash_stack_peek g_t
rash_stack_height g_string_append_c_inline strtod strtol strtoul strtoq strtouq
strtoll strtoull atof
atoi atol atoll gnu_dev_major {GC 5331k - 4258k} gnu_dev_minor gnu_dev_makedev
__strcspn_c1 __strcspn
_c2 __strcspn_c3 __strspn_c1 __strspn_c2 __strspn_c3 __strpbrk_c2 __strpbrk_c3
__strtok_r_1c __strsep_
1c __strsep_2c __strsep_3c {GC 5536k - 5068k} {GC 6589k - 6224k} vprintf
getchar getc_unlocked getch
ar_unlocked putchar fputc_unlocked putc_unlocked putchar_unlocked feof_unlocked
ferror_unlocked {GC 80
95k - 7683k} {GC 9991k - 9391k} {GC 12209k - 11320k} {GC 14717k - 13483k}
{GC 17529k - 16296k} ge
t_vis_list get_vis_enabled_list vis_disable_plugin vis_about vis_configure
vis_playback_start vis_play
back_stop enable_vis_plugin vis_enabled vis_stringify_enabled_list
vis_enable_from_stringified_list ca
lc_stereo_pcm calc_mono_pcm calc_freq calc_mono_freq calc_stereo_freq
vis_send_data
Analyzing compilation unit
Performing interprocedural optimizations
visibility early_local_cleanups inline static-var pure-const
type-escape-varAssembling fu
nctions:
get_vis_list get_vis_enabled_list vis_playback_start vis_playback_stop
vis_enable_from_stringified_li
st vis_stringify_enabled_list vis_configure vis_about vis_enabled
enable_vis_plugin vis_disable_plugin calc_mono_freq vis_send_data {GC 21223k -
16452k}
Program received signal SIGSEGV, Segmentation fault.
verify_ssa_name (ssa_name=0xa5a5a5a5a5a5a5a5, is_virtual=0 '\0')
at gcc/tree-ssa.c:109
109 if (TREE_CODE (ssa_name) != SSA_NAME)
(gdb) where
#0 verify_ssa_name (ssa_name=0xa5a5a5a5a5a5a5a5, is_virtual=0 '\0')
at gcc/tree-ssa.c:109
#1 0x0079905b in verify_ssa (check_modified_stmt=1 '\001')
at gcc/tree-ssa.c:716
#2 0x0060c795 in execute_function_todo (data=value optimized out)
at gcc/passes.c:921
#3 0x0060c51b in execute_todo (flags=1053) at gcc/passes.c:945
#4 0x0060c9fa in execute_one_pass (pass=0xe37ae0) at gcc/passes.c:1090
#5 0x0060cb5c in execute_pass_list (pass=0xe37ae0)
at gcc/passes.c:1120
#6 0x0060cb6e in execute_pass_list (pass=0xe370c0)
at gcc/passes.c:1121
#7 0x0060cb6e in execute_pass_list (pass=0xe36ee0)
at gcc/passes.c:1121
#8 0x0060cb6e in execute_pass_list (pass=0xe36340)
at gcc/passes.c:1121
#9 0x006da8ef in tree_rest_of_compilation (fndecl=0x2b0eb8ddd800)
at gcc/tree-optimize.c:406
#10 0x0082cf70 in cgraph_expand_function (node=0x2b0eb9a8c800)
at gcc/cgraphunit.c:1073
#11 0x0082eae5 in cgraph_optimize () at gcc/cgraphunit.c:1142
#12 0x00413cbe in c_write_global_declarations () at gcc/c-decl.c:7917
#13 0x006855c8 in toplev_main (argc=value optimized out, argv=value
optimized out)
at gcc/toplev.c:1064
#14 0x2b0eb84478e4 in __libc_start_main () from /lib/libc.so.6
#15 0x00403f99 in _start ()
(gdb) call debug_tree (ssa_name)
Program received signal SIGSEGV, Segmentation fault.
print_node (file=0x2b0eb8775840, prefix=0xa8c5c1 , node=0xa5a5a5a5a5a5a5a5,
indent=0)
at gcc/print-tree.c:185
185 code = TREE_CODE (node);
The program being debugged was signaled while in a function called from GDB.
...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32231
[Bug tree-optimization/32231] [4.3 Regression] Segfault in verify_ssa_name
--- Comment #2 from tbm at cyrius dot com 2007-06-06 08:09 --- (In reply to comment #0) I'm getting the following segfault when I compile the beep-media-player application with the options -ffast-math -funroll-all-loops -g -O3: Sorry, I forgot one option that's also needed: -ftree-vectorize -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32231
[Bug tree-optimization/32231] [4.3 Regression] Segfault in verify_ssa_name
--- Comment #3 from tbm at cyrius dot com 2007-06-06 08:10 --- For the record, the command to see this is: /usr/lib/gcc-snapshot/bin/gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/X11R6/include -DPNG_NO_MMX_CODE -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/libpng12 -DPNG_NO_MMX_CODE -I/usr/include/libglade-2.0 -I/usr/include/gtk-2.0 -I/usr/include/libxml2 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12 -DDATA_DIR=\/usr/share/bmp\ -DPLUGIN_DIR=\/usr/lib/bmp\ -DPLUGINSUBS=\Output\,\Input\,\Effect\,\General\,\Visualization\ -DLOCALEDIR=\/usr/share/locale\ -I../intl -I.. -ffast-math -funroll-all-loops -g -O3 -ftree-vectorize-cvisualization.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32231
[Bug libgcj/32227] ../gcc/libjava/classpath/include/config-int.h:7:20: error: stdint.h: No such file or directory
--- Comment #1 from doko at ubuntu dot com 2007-06-06 08:13 --- likele a merge error: classpath/ChangeLog.gcj: 2006-05-19 Andreas Tobler [EMAIL PROTECTED] * include/config-int.h: Delete, it is a generated file. could you try to remove the file and rebuild? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32227
[Bug target/30315] optimize unsigned-add overflow test on x86 to use cpu flags from addl
--- Comment #2 from ubizjak at gmail dot com 2007-06-06 08:15 --- (In reply to comment #0) After the addition, which sets the ALU flags, the compiler issues two compare instructions and conditional branches. This sequence could be replaced by a conditional branch following the addl, testing one of the flags (overflow? carry? I forget which) set by it. in config/i386/i386-modes.def, documentation says: Add CCGOC to indicate comparisons against zero that allows unspecified garbage in the Carry and Overflow flag. This mode is used to simulate comparisons of (a-b) and (a+b) against zero using sub/cmp/add operations. addl operates in CCGOCmode, but you are requesting GTU conditional jump that requires Carry flag=0 and Zero flag=0. GTU is incompatible with CCGOCmode due to Carry flag handling. Change one of conditions to if (sum == 0) abort(); and you will see insn elimination in action. And BTW - wrapping is undefined operation. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30315
[Bug tree-optimization/32216] [4.3 Regression] ICE: verify_stmts failed (invalid reference prefix) with -ftree-vectorize
--- Comment #4 from ubizjak at gmail dot com 2007-06-06 08:29 --- (In reply to comment #3) Probably something similar is required for the VEC_UNPACK_FLOAT_*_EXPR tree-codes ? But these tree-codes are already there: 118577 dorit if (code == WIDEN_SUM_EXPR 118577 dorit || code == VEC_WIDEN_MULT_HI_EXPR 118577 dorit || code == VEC_WIDEN_MULT_LO_EXPR 118577 dorit || code == VEC_UNPACK_HI_EXPR 118577 dorit || code == VEC_UNPACK_LO_EXPR 124784 uros || code == VEC_UNPACK_FLOAT_HI_EXPR 124784 uros || code == VEC_UNPACK_FLOAT_LO_EXPR 124045 uros || code == VEC_PACK_TRUNC_EXPR 124784 uros || code == VEC_PACK_SAT_EXPR 124784 uros || code == VEC_PACK_FIX_TRUNC_EXPR) 109954 dorit type = TREE_TYPE (TREE_OPERAND (rhs, 0)); 109954 dorit -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32216
[Bug tree-optimization/32216] [4.3 Regression] ICE: verify_stmts failed (invalid reference prefix) with -ftree-vectorize
--- Comment #5 from dorit at il dot ibm dot com 2007-06-06 08:33 --- (In reply to comment #4) (In reply to comment #3) Probably something similar is required for the VEC_UNPACK_FLOAT_*_EXPR tree-codes ? But these tree-codes are already there: sorry, I guess I was looking at autovect-branch or something -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32216
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #170 from rguenther at suse dot de 2007-06-06 08:41 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should On Wed, 6 Jun 2007, ian at airs dot com wrote: --- Comment #169 from ian at airs dot com 2007-06-06 05:33 --- What options are you using when you compile? I don't see the symbol you mention, although I do see _ZNK10ScalarCodeIN4Adv51Z13MomentumfluxZILi3clI5FieldI22UniformRectilinearMeshI10MeshTraitsILi3Ed21UniformRectilinearTag12CartesianTagLi3EEEd10MultiPatchI7GridTag6RemoteI5BrickEEESJ_SJ_EEvRKT_RK8IntervalIXsrSK_10dimensionsEERKT0_RKT1_ This was simply with -O2. Note that the above is on 64bit x86_64-linux. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug tree-optimization/32216] [4.3 Regression] ICE: verify_stmts failed (invalid reference prefix) with -ftree-vectorize
--- Comment #6 from ubizjak at gmail dot com 2007-06-06 08:46 --- Oh, we mixed signed and unsigned modes here, as we (again) look into FP for sign. The testcase works if wlookup2 is changed to signed int. Patch is in the works. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-06 08:46:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32216
[Bug c++/30252] [4.2 regression] miscompilation of sigc++-2.0 based code with -fstrict-aliasing
--- Comment #41 from rguenther at suse dot de 2007-06-06 08:49 --- Subject: Re: [4.2 regression] miscompilation of sigc++-2.0 based code with -fstrict-aliasing On Wed, 5 Jun 2007, dberlin at dberlin dot org wrote: q_2 = q_1 + 1 q_3 = q_2 + 1 q_4 = q_3 + 1 q_5 = q_4 + 1 p2 = q_5 Will become the set of constraints q_2 = q_1 q_2 = q_1 + 1 q_3 = q_2 q_3 = q_2 + 1 q_4 = q_3 q_4 = q_3 + 1 q_5 = q_4 q_5 = q_4 +1 Hmmm. You are right, we should give up here and collapse the variable. Sigh. Well, we can always just make it give up on all direct pointer arithmetic, rather than try to handle it at all :) Somehow it doesn't cause problems to fall back to p[0] for p[0] + 1B, but it would be nice to have some more confidence in that parts :) TBQH, the only way i'll ever have confidence in these parts is if we make it stop trying to come up with everything a pointer to a structure could deref. Now, this is of course only because of aliasing. It should be completely irrelevant for points-to. So, if points-to comes up with only struct as a solution we would need some intermediate processing to translate it to the correct alias set, possibly looking at the type hierarchy again. Note that this also prevents us from doing cool things. Too bad ;) In particular, because we say a pointer to struct p points to all it's members, we can never simply propagate the object it does point to if it points to a single object. So we seem to agree the current solution is ugly and doesn't really work. Enough time to fix it for 4.3 then ;) Btw, how does a patch to disable field sensitivity look like for the 4.2 branch? Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30252
[Bug other/32229] gcc version 4 build fails with below errors
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-06 09:00 --- c-parse.c: No such file or directory -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32229
[Bug tree-optimization/32231] [4.3 Regression] Segfault in verify_ssa_name
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-06 09:01 --- Since this is obviously caused by GC (look at the backtrace and you have 0xa5a5a5a5), use --param ggc-min-expand=0 --param ggc-min-heapsize=0 as options to get a reduced testcase (it might take a little while but you should be able to reproduce it easier). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||GC, ice-on-valid-code Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32231
[Bug tree-optimization/32231] [4.3 Regression] Segfault in verify_ssa_name
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-06-06 09:02 ---
{GC 21223k - 16452k}
Program received signal SIGSEGV, Segmentation fault.
verify_ssa_name (ssa_name=0xa5a5a5a5a5a5a5a5, is_virtual=0 '\0')
at gcc/tree-ssa.c:109
109 if (TREE_CODE (ssa_name) != SSA_NAME)
so it just got collected. I bet you'll get an ICE instead with checking
enabled. So, can you nevertheless provide preprocessed source?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org
Keywords|GC, ice-on-valid-code |
Target Milestone|4.3.0 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32231
Re: [Bug target/30315] optimize unsigned-add overflow test on x86 to use cpu flags from addl
And BTW - wrapping is undefined operation. One for signed integers for unsigned it is actually defined as wrapping and the reporter used unsigned integers here. Thanks, Andrew Pinski
[Bug target/30315] optimize unsigned-add overflow test on x86 to use cpu flags from addl
--- Comment #3 from pinskia at gmail dot com 2007-06-06 09:10 --- Subject: Re: optimize unsigned-add overflow test on x86 to use cpu flags from addl And BTW - wrapping is undefined operation. One for signed integers for unsigned it is actually defined as wrapping and the reporter used unsigned integers here. Thanks, Andrew Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30315
[Bug c++/29365] Unnecessary anonymous namespace warnings
--- Comment #27 from pinskia at gcc dot gnu dot org 2007-06-06 09:23 --- 4.2.1 won't have dataflow merge. we need a fix, or switch to disable this broken feature. Seongbae knows dataflow will not be in 4.2, what he is trying to say, which I think you misunderstood, is that he will be working on this again after the merge happens as he is busy with that. It is not like GCC is a closed source program either, you can try to make a fix for the issue too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29365
[Bug c++/31960] Premature hiding of symbols makes a copy constructor shooting at its own foot
--- Comment #3 from waldemar dot rachwal at gmail dot com 2007-06-06 09:44 --- [3 weeks went by, but i've not forgotten about my bug report ;] as about the last comment (#2) I can't fully agree. -Winit-self works, but only in case of builtin scalar data types. For objects the compiler is almost quiet. Please don't misunderstand me: I don't really want any options to signal a warning on self-initializers (more options, much headache). I really expect well defined, desirable semantics for such constructs because there are cases they are very helpful. Of course, if the current standard says nothing about this or leave up to implementors, and we want to have G++ semantics here defined, there is a room for some options in the meantime until the standard becomes definite. Please note that scripting languages are well defined here. Below is a simple Perl code (strictness checks if vars are defined, while -w option add extra warning level). Regards, WR. $ perl -Mstrict -e 'my $z = 1; my $z = $z + 1; print $z\n' 2 $ perl -w -Mstrict -e 'my $z = 1; my $z = $z + 1; print $z\n' my variable $z masks earlier declaration in same scope at -e line 1. 2 -- waldemar dot rachwal at gmail dot com changed: What|Removed |Added CC||waldemar dot rachwal at ||gmail dot com Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31960
[Bug tree-optimization/32231] [4.3 Regression] Segfault in verify_ssa_name
--- Comment #6 from tbm at cyrius dot com 2007-06-06 09:51 --- (In reply to comment #4) Since this is obviously caused by GC (look at the backtrace and you have 0xa5a5a5a5), use --param ggc-min-expand=0 --param ggc-min-heapsize=0 as options to get a reduced testcase (it might take a little while but you should be able to reproduce it easier). You're right, and now I remember you telling me before. I wonder why I didn't think of this. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32231
[Bug tree-optimization/32231] [4.3 Regression] Segfault in verify_ssa_name
--- Comment #7 from tbm at cyrius dot com 2007-06-06 09:54 --- I wonder if this is the same or related to PR29975, see comment 100: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975#c100 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32231
[Bug tree-optimization/32231] [4.3 Regression] Segfault in verify_ssa_name
--- Comment #9 from tbm at cyrius dot com 2007-06-06 10:12 --- Reducing, but this will take a while... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32231
[Bug tree-optimization/32231] [4.3 Regression] Segfault in verify_ssa_name
--- Comment #8 from tbm at cyrius dot com 2007-06-06 10:12 --- Created an attachment (id=13660) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13660action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32231
[Bug c++/29365] Unnecessary anonymous namespace warnings
--- Comment #28 from pluto at agmk dot net 2007-06-06 10:08 --- (In reply to comment #27) It is not like GCC is a closed source program either, you can try to make a fix for the issue too. Andrew, real world is not so simple ;) some time ago Manuel López-Ibáñez helps me create official patch: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7302#c22 patch was submitted: http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01347.html added to tracker: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7302#c23 and pinged: http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00604.html http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00110.html c.a. 3 months and no effects for tested trivial patch. no accecpt, no reject, no commit, no fun. in current situation i feel no reason to working on another patch while the GCC-Team redirect external patches to /dev/null. moreover, gcc lists are full of patch-ping^N-noeffects. i think people are not motivated to cooperate with GCC-Team. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29365
[Bug c++/32232] New: [4.1/4.2/4.3 Regression] ICE in resolve_overloaded_unification
// { dg-do compile }
templatetypename T struct A;
templatetypename T struct B {};
templatetypename T AT operator(AT, const BT);
templatetypename T
struct A
{
AT operator(AT (*)(AT));
};
templatetypename T AT foo(AT);
extern Achar c;
int
main()
{
c (1, foo);
}
ICEs in resolve_overloaded_unification with 3.4, 4.1.2 and the trunk, compiles
fine with 3.2.3.
--
Summary: [4.1/4.2/4.3 Regression] ICE in
resolve_overloaded_unification
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32232
[Bug target/30315] optimize unsigned-add overflow test on x86 to use cpu flags from addl
--- Comment #4 from rask at sygehus dot dk 2007-06-06 10:33 ---
I see no reason to mark this enhancement request as invalid.
As to generating reasonable x86 code for overflow checks written in C, it
isn't completely hopeless. I did an experiment with my 16-bit x86 port. First,
I wrote the overflow check differently (and of course changed the data size to
16-bits):
#include limits.h
void abort (void);
unsigned short int foo (unsigned short int a, unsigned short int b)
{
unsigned short int sum;
sum = a + b;
if ((unsigned long int) a + (unsigned long int) b USHRT_MAX)
abort ();
return sum;
}
Second, I added new instructions, of which combine was asking for the first
one:
(define_insn_and_split *addsi3_cconly_highpart_ccz_nc
[(set (reg:CCZ_NC CC_REG)
(compare:CCZ_NC
(subreg:HI (plus:SI (match_operand:SI 1 general_operand 0)
(match_operand:SI 2 general_operand g)) 2)
(const_int 0)))
(clobber (match_scratch:HI 0 =r))]
ia16_arith_operands_p (PLUS, operands)
#
[(parallel
[(set (match_dup 0) (plus:HI (match_dup 3) (match_dup 4)))
(set (reg:CCZ_NC CC_REG)
(compare:CCZ_NC (subreg:HI (plus:SI (zero_extend:SI (match_dup 3))
(zero_extend:SI (match_dup 4))) 2)
(const_int 0)))]
)]
{
operands[3] = simplify_gen_subreg (HImode, operands[1], SImode, 0);
operands[4] = simplify_gen_subreg (HImode, operands[2], SImode, 0);
})
(define_insn *addhi3_cc_carry_ccz_nc
[(set (match_operand:HI 0 nonimmediate_operand =qm,r,m)
(plus:HI (match_operand:HI 1 nonimmediate_operand %0,0,0)
(match_operand:HI 2 general_operand Uo,g,ri)))
(set (reg:CCZ_NC CC_REG)
(compare:CCZ_NC
(subreg:HI (plus:SI (zero_extend:SI (match_dup 1))
(zero_extend:SI (match_dup 2))) 2)
(const_int 0)))]
ia16_arith_operands_p (PLUS, operands)
@
addb\t%H2,\t%H0
addw\t%2,\t%0
addw\t%2,\t%0
)
(define_insn *addhi3_cconly_carry_ccz_nc
[(set (match_scratch:HI 0 =qm,r,m)
(plus:HI (match_operand:HI 1 nonimmediate_operand %0,0,0)
(match_operand:HI 2 general_operand Uo,g,ri)))
(set (reg:CCZ_NC CC_REG)
(compare:CCZ_NC
(subreg:HI (plus:SI (zero_extend:SI (match_dup 1))
(zero_extend:SI (match_dup 2))) 2)
(const_int 0)))]
ia16_arith_operands_p (PLUS, operands)
@
addb\t%H2,\t%H0
addw\t%2,\t%0
addw\t%2,\t%0
)
(define_insn *beq_ccz_nc
[(set (pc)
(if_then_else (eq (reg:CCZ_NC CC_REG)
(const_int 0))
(label_ref (match_operand 0))
(pc)))]
jnc\t%l0
)
Third, I created CCZ_NCmode and modified my SELECT_CC_MODE callback to use
it for the comparison in *addsi3_cconly_highpart_ccz_nc. Result:
foo:
pushw %cx ;# 69 *pushhi1_nonimm
pushw %si ;# 70 *pushhi1_nonimm
pushw %di ;# 71 *pushhi1_nonimm
pushw %bp ;# 72 *pushhi1_nonimm
movw%sp,%bp ;# 67 *movhi/1
movw10(%bp),%di ;# 2*movhi/1
movw%sp,%si ;# 68 *movhi/1
movw12(%si),%bp ;# 3*movhi/1
movw%bp,%ax ;# 7*movhi/1
addw%di,%ax ;# 63 *addhi3_cc_carry_ccz_nc/2
jnc .L7 ;# 15 *beq_ccz_nc
callabort ;# 25 *call
.L7:
popw%bp ;# 75 *pophi1
popw%di ;# 76 *pophi1
popw%si ;# 77 *pophi1
popw%cx ;# 78 *pophi1
ret ;# 79 *return
I see no reason the i386 back end can't be improved in a similiar fashion.
The original example is a lot more difficult because it uses two
comparisons. The middle end would have to recognize that the two comparisons
test the same thing.
--
rask at sygehus dot dk changed:
What|Removed |Added
CC||rask at sygehus dot dk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30315
[Bug c++/29365] Unnecessary anonymous namespace warnings
--- Comment #29 from manu at gcc dot gnu dot org 2007-06-06 11:23 --- (In reply to comment #28) (In reply to comment #27) It is not like GCC is a closed source program either, you can try to make a fix for the issue too. Andrew, real world is not so simple ;) [snip] c.a. 3 months and no effects for tested trivial patch. no accecpt, no reject, no commit, no fun. in current situation i feel no reason to working on another patch while the GCC-Team redirect external patches to /dev/null. It is true that patches get lost sometimes. But that is true for everybody, not only for external patches. If you check http://www.dberlin.org/patches/patches/list, there are patches pending since 2006 from top maintainers such as Andrew Pinski. I guess they forgot about them or just don't have time to keep pinging them. (That is why the patch tracker is such a great idea, I may decide to take his patch, update it and ping it myself). moreover, gcc lists are full of patch-ping^N-noeffects. i think people are not motivated to cooperate with GCC-Team. That may be true. (I think it is to some extent). But there are also lots of patches that get 5 pings and then get reviewed and committed. Sending a ping for a patch takes less than 1 second (at least with gmail). Sometimes you need to ping individual maintainers (CC them) one by one until someone replies (in your case, perhaps diagnostics maintainer and C++ front-end ones) but without being annoying because that will put reviewers off. Unfortunately, this penalises the sporadic contributor that wants to commit a patch before sending another. You don't need to wait. If you have 12 patches waiting approval, ping all of them. (It will make more noise than a lonely ping from time to time). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29365
[Bug tree-optimization/32216] [4.3 Regression] ICE: verify_stmts failed (invalid reference prefix) with -ftree-vectorize
--- Comment #7 from ubizjak at gmail dot com 2007-06-06 11:55 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00318.html -- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||06/msg00318.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32216
[Bug tree-optimization/32216] [4.3 Regression] ICE: verify_stmts failed (invalid reference prefix) with -ftree-vectorize
--- Comment #8 from uros at gcc dot gnu dot org 2007-06-06 12:12 --- Subject: Bug 32216 Author: uros Date: Wed Jun 6 12:12:32 2007 New Revision: 125482 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125482 Log: PR tree-optimization/32216 * tree-vectorizer.c (supportable_widening_operation): Determine signedness of FIX_TRUNC_EXPR from output operand. (supportable_narrowing_operation): Ditto. * tree-vect-generic.c (expand_vector_operations_1): Determine signedness of VEC_UNPACK_FLOAT_HI_EXPR and VEC_UNPACK_FLOAT_LO_EXPR from input operand. testsuite/ChangeLog: PR tree-optimization/32216 * gcc.dg/vect/pr32216.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/pr32216.c Modified: trunk/gcc/ChangeLog trunk/gcc/optabs.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-generic.c trunk/gcc/tree-vectorizer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32216
[Bug tree-optimization/32216] [4.3 Regression] ICE: verify_stmts failed (invalid reference prefix) with -ftree-vectorize
--- Comment #9 from ubizjak at gmail dot com 2007-06-06 12:13 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32216
[Bug c++/32232] [4.1/4.2/4.3 Regression] ICE in resolve_overloaded_unification
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-06 12:55 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||3.4.0 4.1.2 4.2.0 4.3.0 Known to work||3.3.6 Last reconfirmed|-00-00 00:00:00 |2007-06-06 12:55:38 date|| Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32232
[Bug target/30315] optimize unsigned-add overflow test on x86 to use cpu flags from addl
--- Comment #5 from ubizjak at gmail dot com 2007-06-06 13:00 --- (In reply to comment #4) I see no reason the i386 back end can't be improved in a similiar fashion. Interesting... I agree that this bugreport can be an enhancement request for the code you provided. We can perhaps operate in just introduced CCCmode, but it looks a lot of added functionality to cover this corner case. I'll try to code something. -- ubizjak at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30315
[Bug fortran/25104] [F2003] Non-initialization expr. as case-selector
--- Comment #7 from P dot Schaffnit at access dot rwth-aachen dot de 2007-06-06 13:21 --- If someone acts on FX's suggestion, Bug 32035 might also be tackeled at the same time... Philippe -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25104
[Bug libstdc++/32233] New: warning in stl_vector.h:832
This program:
#include vector
int main() {
std::vectorint v(10);
}
Triggers the following warning in recent SVN versions:
/home/wouter/gcc/local/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../../include/c++/4.3.0/bits/stl_vector.h:
In member function int std::vector_Tp, _Alloc::_M_fill_initialize(size_t,
const _Tp) [with _Tp = int, _Alloc = std::allocatorint]:
/home/wouter/gcc/local/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../../include/c++/4.3.0/bits/stl_vector.h:832:
warning: control reaches end of non-void function
--
Summary: warning in stl_vector.h:832
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wouter dot vermaelen at scarlet dot be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32233
[Bug middle-end/32209] Boot failure Comparing stages 2 and 3
--- Comment #10 from rakdver at gcc dot gnu dot org 2007-06-06 14:27 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00341.html -- rakdver at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||06/msg00341.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32209
[Bug target/30315] optimize unsigned-add overflow test on x86 to use cpu flags from addl
--- Comment #6 from raeburn at raeburn dot org 2007-06-06 14:51 --- Subject: Re: optimize unsigned-add overflow test on x86 to use cpu flags from addl On Jun 6, 2007, at 04:15, ubizjak at gmail dot com wrote: in config/i386/i386-modes.def, documentation says: Add CCGOC to indicate comparisons against zero that allows unspecified garbage in the Carry and Overflow flag. This mode is used to simulate comparisons of (a-b) and (a+b) against zero using sub/cmp/add operations. addl operates in CCGOCmode, but you are requesting GTU conditional jump that requires Carry flag=0 and Zero flag=0. GTU is incompatible with CCGOCmode due to Carry flag handling. Actually, I think the test I want is just for the carry flag, which can be done with one branch instruction using the flags set by addl. If gcc's description of addl doesn't support that, well, then that's what I'm requesting be enhanced. :-) Rask's approach looks interesting, though I wouldn't want to have to rewrite simple, portable tests for unsigned overflow to use wider types, especially if I'm adding unsigned long long values, where I don't have portable wider types. Ken -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30315
[Bug c++/31806] [4.0/4.1/4.2 Regression] miscompilation with -fschedule-insns2 -fno-threadsafe-statics
--- Comment #8 from mueller at gcc dot gnu dot org 2007-06-06 15:02 --- testcase works with gcc 3.4 and gcc 3.3 -- mueller at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.1.3 |4.1.3 4.0.4 Known to work|4.3.0 4.2.0 | Summary|miscompilation with - |[4.0/4.1/4.2 Regression] |fschedule-insns2 -fno- |miscompilation with - |threadsafe-statics |fschedule-insns2 -fno- ||threadsafe-statics http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31806
[Bug c++/31806] [4.1/4.2 Regression] miscompilation with -fschedule-insns2 -fno-threadsafe-statics
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2 Regression]|[4.1/4.2 Regression] |miscompilation with - |miscompilation with - |fschedule-insns2 -fno- |fschedule-insns2 -fno- |threadsafe-statics |threadsafe-statics Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31806
[Bug fortran/32195] [regression] ICE in get_array_ctor_strlen
--- Comment #2 from dominiq at lps dot ens dot fr 2007-06-06 15:32 --- Fixed by patch: http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00064.html -- dominiq at lps dot ens dot fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32195
[Bug ada/32234] New: Default pointer initialization not occuring - due to the use of
I see this problem with mainline and with GNAT GPL 2007. A pointer is not being default initialized to NULL in Ada.Containers.Hashed_Maps. This causes segmentation faults on large programs. On the small testcase (see end of message) you need valgrind to see it, since almost always you get NULL by accident. This problem seems awfully similar to ACT bug EA23-003. Note that in Ada.Containers.Hashed_Maps.Insert.New_Node there is return new Node_Type'(Key = Key, Element = , Next= Next); If I get rid of the then the problem goes away. $ gnatmake -gnat05 p gcc -c -gnat05 p.adb gnatbind -x p.ali gnatlink p.ali $ valgrind --tool=memcheck ./p ... ==25467== Conditional jump or move depends on uninitialised value(s) ==25467==at 0x804AA2F: _ada_p (in /home/duncan/Programming/Bugs/bug_103/p) ==25467==by 0x80497F6: main (in /home/duncan/Programming/Bugs/bug_103/p) Testcase: --chop here-- with Ada.Containers.Hashed_Maps; procedure P is function H (I : Integer) return Ada.Containers.Hash_Type is begin return Ada.Containers.Hash_Type'Mod (I); end; type Item_Pointer is access Boolean; package M is new Ada.Containers.Hashed_Maps (Integer, Item_Pointer, H, =); Z : M.Map; Position : M.Cursor; Inserted : Boolean; Item : Item_Pointer; begin M.Insert (Z, 2, Position, Inserted); -- default initialization for new item Item := M.Element (Position); if Item = null then -- Item contains a random value here Item := new Boolean; end if; end; -- Summary: Default pointer initialization not occuring - due to the use of Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: baldrick 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=32234
[Bug c++/30252] [4.2 regression] miscompilation of sigc++-2.0 based code with -fstrict-aliasing
--- Comment #42 from dberlin at gcc dot gnu dot org 2007-06-06 15:52 --- Subject: Re: [4.2 regression] miscompilation of sigc++-2.0 based code with -fstrict-aliasing On 6 Jun 2007 08:49:50 -, rguenther at suse dot de [EMAIL PROTECTED] wrote: --- Comment #41 from rguenther at suse dot de 2007-06-06 08:49 --- Subject: Re: [4.2 regression] miscompilation of sigc++-2.0 based code with -fstrict-aliasing On Wed, 5 Jun 2007, dberlin at dberlin dot org wrote: q_2 = q_1 + 1 q_3 = q_2 + 1 q_4 = q_3 + 1 q_5 = q_4 + 1 p2 = q_5 Will become the set of constraints q_2 = q_1 q_2 = q_1 + 1 q_3 = q_2 q_3 = q_2 + 1 q_4 = q_3 q_4 = q_3 + 1 q_5 = q_4 q_5 = q_4 +1 Hmmm. You are right, we should give up here and collapse the variable. Sigh. Well, we can always just make it give up on all direct pointer arithmetic, rather than try to handle it at all :) Somehow it doesn't cause problems to fall back to p[0] for p[0] + 1B, but it would be nice to have some more confidence in that parts :) TBQH, the only way i'll ever have confidence in these parts is if we make it stop trying to come up with everything a pointer to a structure could deref. Now, this is of course only because of aliasing. It should be completely irrelevant for points-to. So, if points-to comes up with only struct as a solution we would need some intermediate processing to translate it to the correct alias set, possibly looking at the type hierarchy again. Well, actually, you don't. At the point where you process it, we either have created SFT's or we haven't (if we haven't than the deref is going to touch the one variable we've created for the struct) The rest is more or less equivalent to what access_can_touch_variable does :) So we seem to agree the current solution is ugly and doesn't really work. Enough time to fix it for 4.3 then ;) Btw, how does a patch to disable field sensitivity look like for the 4.2 branch? The patch is trivial. We have static bool use_field_sensitive = true at the top of the file. Just set it to false and away you go. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30252
[Bug fortran/32235] New: gfortran - incorrectly position text file after backspace
g77, g95, Absoft 9.2, etc.. position the text file correctly, but gfortran is
off by one line -
[dranta:~/tests/gfortran-D] dir% gfortran -fno-automatic -std=legacy -o aRead01
aRead01.f
[dranta:~/tests/gfortran-D] dir% aRead01 aRead01.in
1one
2Two
3Three
read =Two
[dranta:~/tests/gfortran-D] dir% g77 -o aRead01 aRead01.f
[dranta:~/tests/gfortran-D] dir% aRead01 aRead01.in
1one
2Two
3Three
read =Three
[dranta:~/tests/gfortran-D] dir% cat aRead01.f
program main
character*10 a
ncards=2
read(5,1000)a
read(5,1000)a
call inlist(ncards)
read(5,1000)a
write(6,2000)a
stop
1000 format(a10)
2000 format('read =',a10)
end
subroutine inlist(ncards)
character*4 data(20)
input=5
c
if (ncards.eq.0) go to 20
do 15 i=1,ncards
backspace input
15 continue
c
20 continue
kard = 0
30 read(5,1000,end=60) data
40 kard=kard + 1
50 write (6,2020) kard,data
go to 30
60 continue
kard=kard - ncards + 1
do 70 i=1,kard
backspace input
70 continue
c
return
c
1000 format (20a4)
2020 format (8x,i15,8x,20a4)
c
end
[dranta:~/tests/gfortran-D] dir% cat aRead01.in
one
Two
Three
[dranta:~/tests/gfortran-D] dir% gfortran --v
Using built-in specs.
Target: powerpc-apple-darwin8.9.0
Configured with: ../gcc/configure --enable-checking --disable-multilib
--prefix=/usr/local/gfortran --enable-languages=c,fortran
Thread model: posix
gcc version 4.3.0 20070604 (experimental)
--
Summary: gfortran - incorrectly position text file after
backspace
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dir at lanl dot gov
GCC host triplet: powerpc-apple-darwin8.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32235
[Bug ada/32234] Default pointer initialization not occuring - due to the use of
--- Comment #1 from anhvofrcaus at gmail dot com 2007-06-06 17:44 --- Why shouldn't it happen in a small program? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32234
[Bug testsuite/31828] FAIL: gcc.dg/float-range-[3-5].c (test for excess errors)
--- Comment #1 from sje at gcc dot gnu dot org 2007-06-06 17:48 --- Subject: Bug 31828 Author: sje Date: Wed Jun 6 17:48:03 2007 New Revision: 125496 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125496 Log: PR testsuite/31828 * inclhack.def (hppa_hpux_fp_macros): New. * fixincl.x: Regenerate. * * tests/base/math.h: Update. Modified: trunk/fixincludes/ChangeLog trunk/fixincludes/fixincl.x trunk/fixincludes/inclhack.def trunk/fixincludes/tests/base/math.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31828
[Bug tree-optimization/32231] [4.3 Regression] Segfault in verify_ssa_name
--- Comment #10 from tbm at cyrius dot com 2007-06-06 17:58 ---
(sid)25696:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -ffast-math -O1
-ftree-vectorize --param ggc-min-expand=0 --param ggc-min-heapsize=0
beep-visualization.c
beep-visualization.c: In function 'calc_freq':
beep-visualization.c:3: internal compiler error: Segmentation fault
Testcase:
extern double sqrt (double __x);
calc_freq (int *dest)
{
float tmp_out[257];
int i;
for (i = 0; i 256; i++)
dest[i] = sqrt (tmp_out[i]);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32231
[Bug c++/32177] g++ crashes on some valid OpenMP code
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||06/msg00367.html Status|NEW |ASSIGNED Last reconfirmed|2007-06-01 11:28:27 |2007-06-06 18:02:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32177
[Bug tree-optimization/32087] ICE with FORTRAN and -fprefetch-loop-arrays
--- Comment #1 from jv244 at cam dot ac dot uk 2007-06-06 18:03 --- just wondering if this is related to PR 32176 (see comment 2 for a similar looking testcase), crashing with the same options, though a different location. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32087
[Bug libstdc++/32233] warning in stl_vector.h:832
--- Comment #1 from pcarlini at suse dot de 2007-06-06 18:23 --- Mine, fixed momentarily. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-06 18:23:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32233
[Bug fortran/32236] New: internal compiler error: in gfc_assign_data_value, at fortran/data.c:288
Crash occurs while compiling fortran code...error as indicated in summary. Compiler output: ssai13-larc-nasa-gov gfortran -v -save-temps tauaero.f Driving: /usr/local/bin/gfortran -v -save-temps tauaero.f -lgfortranbegin -lgfortran -shared-libgcc Using built-in specs. Target: i386-apple-darwin8.9.1 Configured with: ../gcc-4.3-20070316/configure --enable-languages=fortran Thread model: posix gcc version 4.3.0 20070316 (experimental) /usr/local/libexec/gcc/i386-apple-darwin8.9.1/4.3.0/f951 tauaero.f -ffixed-form -fPIC -mmacosx-version-min=10.4 -quiet -dumpbase tauaero.f -mtune=generic -march=nocona -auxbase tauaero -version -fintrinsic-modules-path /usr/local/lib/gcc/i386-apple-darwin8.9.1/4.3.0/finclude -o tauaero.s GNU F95 version 4.3.0 20070316 (experimental) (i386-apple-darwin8.9.1) compiled by GNU C version 4.3.0 20070316 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 tauaero.f:1517: internal compiler error: in gfc_assign_data_value, at fortran/data.c:288 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. Source code is available...let me know how to provide it to you. -- Summary: internal compiler error: in gfc_assign_data_value, at fortran/data.c:288 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: r dot f dot arduini at larc dot nasa dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32236
[Bug middle-end/32209] Boot failure Comparing stages 2 and 3
--- Comment #11 from andreast at gcc dot gnu dot org 2007-06-06 18:28 --- Bootstrap succeeded on both, ppc darwin and i686 darwin. disable-checking! Thank you! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32209
[Bug ada/32234] Default pointer initialization not occuring - due to the use of
--- Comment #2 from baldrick at gcc dot gnu dot org 2007-06-06 18:35 --- Why shouldn't it happen in a small program? It can cause a segfault also in small programs. However, memory areas often start out containing all zeros, so until the program has dirtied a bunch of memory uninitialized variables tend to contain zero by accident. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32234
[Bug fortran/32236] internal compiler error: in gfc_assign_data_value, at fortran/data.c:288
--- Comment #1 from r dot f dot arduini at larc dot nasa dot gov 2007-06-06 18:41 --- Created an attachment (id=13661) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13661action=view) part of fortran 77 package -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32236
[Bug libstdc++/32233] warning in stl_vector.h:832
--- Comment #2 from paolo at gcc dot gnu dot org 2007-06-06 18:44 --- Subject: Bug 32233 Author: paolo Date: Wed Jun 6 18:44:02 2007 New Revision: 125499 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125499 Log: 2007-06-06 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/32233 * include/bits/stl_vector.h (_M_fill_initialize): Fix return type. * testsuite/23_containers/vector/requirements/dr438/assign_neg.cc: Adjust dg-error line. * testsuite/23_containers/vector/requirements/dr438/insert_neg.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_vector.h trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/assign_neg.cc trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/insert_neg.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32233
[Bug libstdc++/32233] warning in stl_vector.h:832
--- Comment #3 from pcarlini at suse dot de 2007-06-06 18:45 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32233
[Bug c++/32237] New: can't compile when a vector is based on a local struct
I can't compile this code:
void f()
{
struct a { int i; };
std::vectora v;
}
Moving the struct declaration out of the function solves the problem.
--
Summary: can't compile when a vector is based on a local struct
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danielm77 at spray dot se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32237
[Bug c++/32237] can't compile when a vector is based on a local struct
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-06 19:01 --- That is correct, template arguments cannot be local classes/structs. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32237
[Bug tree-optimization/32225] [PTR-PLUS] ICE in alias.c with INDIRECT_REF to a INTEGER_TYPE
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-06 19:23 --- Subject: Bug 32225 Author: pinskia Date: Wed Jun 6 19:23:19 2007 New Revision: 125502 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125502 Log: 2007-06-06 Andrew Pinski [EMAIL PROTECTED] PR tree-opt/32225 * tree-scalar-evolution.c (follow_ssa_edge_in_rhs case POINTER_PLUS_EXPR): Do not change type_rhs. (follow_ssa_edge_in_rhs case POINTER_PLUS_EXPR, case PLUS_EXPR): Use the code of the orginal expression instead of just PLUS_EXPR. Also use type_rhs where TREE_TYPE (rhs) was used (reverting back to the trunk). 2007-06-06 Andrew Pinski [EMAIL PROTECTED] PR tree-opt/32225 * gcc.c-torture/compile/20070605-1.c: New test. Added: branches/pointer_plus/gcc/testsuite/gcc.c-torture/compile/20070605-1.c Modified: branches/pointer_plus/gcc/ChangeLog.ptr branches/pointer_plus/gcc/testsuite/ChangeLog.ptr branches/pointer_plus/gcc/tree-scalar-evolution.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32225
[Bug tree-optimization/32225] [PTR-PLUS] ICE in alias.c with INDIRECT_REF to a INTEGER_TYPE
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-06 19:24 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32225
[Bug fortran/32236] internal compiler error: in gfc_assign_data_value, at fortran/data.c:288
--- Comment #2 from burnus at gcc dot gnu dot org 2007-06-06 20:22 --- Your example file misses the param module; however, I found it via google: http://www.crseo.ucsb.edu/esrg/pauls_dir/sbdart_browser/html_code/sbdart/params.f.html The complete package is at: ftp://ftp.icess.ucsb.edu/pub/esrg/sbdart/sbdart_2.4.tar.gz Note: This is a fixed-format Fortran 90 file, not a Fortran 77 file. * * * Using NAG f95 I get the error: Error: tauaero.f, line 1601: WLBAER has already been completely initialised Using g95: In file tauaero.f:1601 data wlbaer/0.,0./ 1 Error: Variable 'wlbaer' at (1) already has an initialization (ifort simply accepts the code.) If one comments out that line 1601, the program actually compiles with gfortran. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-invalid-code Known to fail||4.2.0 4.1.3 4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-06-06 20:22:37 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32236
[Bug c++/32211] Compile error
--- Comment #2 from jimmyhappyi at gmail dot com 2007-06-06 20:27 --- (In reply to comment #1) g++: Internal error: Killed (program cc1plus) ... suggests that some external force terminated g++. Did you perhaps run out of memory? (If so, try 'ulimit') So should I run ulimit or ulimit [amount of MB to limit memory] jimhap -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32211
[Bug fortran/32235] gfortran - incorrectly position text file after backspace
--- Comment #1 from burnus at gcc dot gnu dot org 2007-06-06 20:31 --- I may do something wrong, but I get with this example always: read =Three I tried gfortran, g95, NAG f95, g77 and ifort with the same result. Additionally, I is a bit unclear how using backspace on standard in (stdin, unit=5) is supposed to work. However, I'm able to reporduce the difference with using: open(5,file='aRead01.in') In this case gfortran shows read =Two whereas with the other compilers read =Three is shown. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32235
[Bug ada/32234] Default pointer initialization not occuring - due to the use of
--- Comment #3 from anhvofrcaus at gmail dot com 2007-06-06 20:46 --- The test code works fine on GNAT-GPL-2007 (Linux and Windows). In addition, it works fine on Linux with GCC-4.3-2007070518 and GCC-4.3-20070601 also. -- anhvofrcaus at gmail dot com changed: What|Removed |Added CC||anhvofrcaus at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32234
[Bug tree-optimization/32230] [4.3 Regression] Segfault in set_bb_for_stmt with -O -ftree-vectorize
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||ice-on-valid-code Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32230
[Bug testsuite/25241] DejaGNU does not distinguish between errors and warnings
--- Comment #52 from manu at gcc dot gnu dot org 2007-06-06 20:49 --- Subject: Bug 25241 Author: manu Date: Wed Jun 6 20:49:09 2007 New Revision: 125505 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125505 Log: 2007-06-06 Manuel Lopez-Ibanez [EMAIL PROTECTED] PR testsuite/25241 testsuite/ * gcc.dg/simd-5.c: Mark output as a note. * gcc.dg/simd-6.c: Mark output as a note. Fix incorrect use of dg-message. * gcc.dg/simd-1.c: Likewise. * gcc.dg/always_inline.c: Mark output as a sorry. * gcc.dg/always_inline2.c: Likewise. * gcc.dg/always_inline3.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/always_inline.c trunk/gcc/testsuite/gcc.dg/always_inline2.c trunk/gcc/testsuite/gcc.dg/always_inline3.c trunk/gcc/testsuite/gcc.dg/simd-1.c trunk/gcc/testsuite/gcc.dg/simd-5.c trunk/gcc/testsuite/gcc.dg/simd-6.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25241
[Bug tree-optimization/32230] [4.3 Regression] Segfault in set_bb_for_stmt with -O -ftree-vectorize
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-06 20:52 --- Confirmed, there are two ways of fixing this bug, either check before calling bsi_insert_on_edge_immediate that we have a NULL statement or inside bsi_insert_on_edge_immediate, we could return NULL always if we don't have anything to insert on the edge. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-06 20:52:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32230
[Bug tree-optimization/32230] [4.3 Regression] Segfault in set_bb_for_stmt with -O -ftree-vectorize
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-06 20:53 --- In most of the cases we already check before calling bsi_insert_on_edge_immediate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32230
[Bug ada/32234] Default pointer initialization not occuring - due to the use of
--- Comment #4 from baldrick at gcc dot gnu dot org 2007-06-06 20:59 --- You have to run it under valgrind to see the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32234
[Bug fortran/32236] internal compiler error: in gfc_assign_data_value, at fortran/data.c:288
--- Comment #3 from r dot f dot arduini at larc dot nasa dot gov 2007-06-06 21:00 --- Subject: Re: internal compiler error: in gfc_assign_data_value, at fortran/data.c:288 Thank you for your quick and thorough response. I am now able to compile the program with gfortran and can proceed with verifying results. I am new to the Mac OS X and gfortran is what has been installed on the machine for me. Now, I am trying to build confidence in the software. Thanks again for your help. Bob On Jun 6, 2007, at 4:22 PM, burnus at gcc dot gnu dot org wrote: --- Comment #2 from burnus at gcc dot gnu dot org 2007-06-06 20:22 --- Your example file misses the param module; however, I found it via google: http://www.crseo.ucsb.edu/esrg/pauls_dir/sbdart_browser/html_code/ sbdart/params.f.html The complete package is at: ftp://ftp.icess.ucsb.edu/pub/esrg/sbdart/sbdart_2.4.tar.gz Note: This is a fixed-format Fortran 90 file, not a Fortran 77 file. * * * Using NAG f95 I get the error: Error: tauaero.f, line 1601: WLBAER has already been completely initialised Using g95: In file tauaero.f:1601 data wlbaer/0.,0./ 1 Error: Variable 'wlbaer' at (1) already has an initialization (ifort simply accepts the code.) If one comments out that line 1601, the program actually compiles with gfortran. -- burnus at gcc dot gnu dot org changed: What|Removed |Added -- -- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-invalid-code Known to fail||4.2.0 4.1.3 4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-06-06 20:22:37 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32236 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32236
[Bug tree-optimization/32224] [4.3 Regression] ICE in vect_analyze_operations, at tree-vect-analyze.c:374
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-06 21:03 --- Confirmed: t1.c:10: note: == examining statement: __asm__(bswap %q0:=r *__dst_4:0 D.2235_9) -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-06 21:03:34 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32224
[Bug c++/31960] Premature hiding of symbols makes a copy constructor shooting at its own foot
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-06 21:11 --- we want to have G++ semantics here defined The semantics are defined, just you are invoking other undefined behavior with respect of doing stuff like: b a; a = a; Which are what the semantics of C++ says the two are equaivant. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31960
[Bug libstdc++/32208] Patch for 32158 has bad code in std::vector::_M_fill_initialize
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-06 21:13 --- *** This bug has been marked as a duplicate of 32233 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32208
[Bug libstdc++/32233] warning in stl_vector.h:832
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-06 21:13 --- *** Bug 32208 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||mec at google dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32233
[Bug fortran/32238] New: ICE in gfc_conv_constant (where with complex arrays)
ICE with gcc version 4.3.0 20070606 (experimental) on where( ) with complex array; worked fine previously up until at least gcc version 4.3.0 20070111. Here is test case (taken from other code) with compiler info and messages embedded: module bug_test ! gfortran -v ! Using built-in specs. ! Target: i386-pc-linux-gnu ! Configured with: /home/fxcoudert/gfortran_nightbuild/trunk/configure ! -prefix=/home/fxcoudert/gfortran_nightbuild/irun-20070606 ! --enable-languages=c,fortran --build=i386-pc-linux-gnu ! --enable-checking=release ! -with-gmp=/home/fxcoudert/gfortran_nightbuild/software ! Thread model: posix ! gcc version 4.3.0 20070606 (experimental) ! gfortran -O3 -ffree-form -c bug.f ! ! bug.f: In function bug: ! bug.f:5: internal compiler error: in gfc_conv_constant, at fortran/trans-const.c:289 ! Please submit a full bug report, ! with preprocessed source if appropriate. ! See URL:http://gcc.gnu.org/bugs.html for instructions. ! compiles fine with gcc version 4.3.0 20070111 (experimental) ! ! same issue whether in module or not contains subroutine bug(c) ! subroutine bug(c,n) implicit none integer, parameter :: fp = selected_real_kind(13) !---different variants of defining array - all fail for complex complex(kind=fp) :: c(:,:) ! complex(kind=fp) :: c(:) ! integer :: n ! complex(kind=fp) :: c(1:n) ! real(kind=fp) :: c(:,:) !---get rid of dirty zeroes where( abs( aimag( c ) ) 1.e-10_fp ) c = cmplx( real( c , fp ) , 0._fp , fp ) where( abs( real( c , fp ) ) 1.e-10_fp ) c = cmplx( 0._fp , aimag( c ) , fp ) !---for real values, it works ! where( abs( c ) 1.e-10_fp ) c = 0._fp return end subroutine bug end module bug_test -- Summary: ICE in gfc_conv_constant (where with complex arrays) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: weinert at cmth dot phys dot uwm dot edu GCC build triplet: 386-pc-linux-gnu GCC target triplet: i386-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32238
[Bug fortran/32238] ICE in gfc_conv_constant (where with complex arrays)
--- Comment #1 from weinert at cmth dot phys dot uwm dot edu 2007-06-06 21:36 --- Created an attachment (id=13662) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13662action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32238
[Bug c++/32214] summary test
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-06 21:44 --- I can only assume this was a test bug so closing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32214
[Bug c++/32211] Compile error
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-06 21:46 --- First 3.4.x is no longer maintained, so you should upgrade. Second how much memory do you have? Third can you make sure you read http://gcc.gnu.org/bugs.html and supply all the required information there? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32211
[Bug c++/32205] defined but not used warning given or not depending on other errors
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-06 21:48 --- The main reason why is that we don't process the initializer for foo if we get an error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32205
[Bug c/32207] missing warnings about address of 'x'.
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-06 21:51 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2007-06-06 21:51:18 date|| Summary|inconsistent/missed warnings|missing warnings about |about address of 'x'. |address of 'x'. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32207
[Bug tree-optimization/32194] [4.3 Regression] ice for legal code with -O3 with complex in loop
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-06 21:52 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32194
[Bug tree-optimization/32169] [4.3 Regression] Ice in set_value_range, at tree-vrp.c:326
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-06 21:56 --- Reducing ... -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||ian at gcc dot gnu dot org Severity|normal |blocker Keywords||ice-on-valid-code Summary|Ice in set_value_range, at |[4.3 Regression] Ice in |tree-vrp.c:326 |set_value_range, at tree- ||vrp.c:326 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32169
[Bug fortran/31833] FAIL: gfortran.dg/integer_exponentiation_3.F90 at -O0 and above
--- Comment #3 from sje at cup dot hp dot com 2007-06-06 22:04 --- Here is a cutdown test case, it looks like we have a roundoff difference between the exponentiation done at compile time and the exponentiation done at run time and thus a and b are not 'exactly the same'. Maybe we should use the approximate check instead of the exact check in this case. subroutine check_c4 (a, b) complex(kind=4), intent(in) :: a, b print *, a print *, b if (a /= b) call abort() end subroutine check_c4 program test complex(kind=4) :: c4 c4 = (1.0,0.2) call check_c4(c4**9,(1.0,0.2)**9) end program test -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31833
[Bug fortran/31831] FAIL: gfortran.dg/assumed_charlen_function_5.f90 -O (test for excess errors)
--- Comment #1 from sje at cup dot hp dot com 2007-06-06 22:48 --- Dave, I am not seeing this in my recent PA runs. Do you still get this failure or can we close this defect out. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31831
[Bug fortran/31831] FAIL: gfortran.dg/assumed_charlen_function_5.f90 -O (test for excess errors)
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2007-06-06 22:56 --- Subject: Re: FAIL: gfortran.dg/assumed_charlen_function_5.f90 -O (test for excess errors) --- Comment #1 from sje at cup dot hp dot com 2007-06-06 22:48 --- Dave, I am not seeing this in my recent PA runs. Do you still get this failure or can we close this defect out. It's not failing anymore. Closing. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31831
[Bug libstdc++/32208] Patch for 32158 has bad code in std::vector::_M_fill_initialize
--- Comment #2 from reichelt at gcc dot gnu dot org 2007-06-06 22:57 --- Just a note: Also, shouldn't there also be an error about lack of return type for _M_fill_initialize? Well, here's the code snippet from the function grokdeclarator in decl.c that deals with missing return types: if (type_was_error_mark_node) /* We've already issued an error, don't complain more. */; else if (in_system_header || flag_ms_extensions) /* Allow it, sigh. */; else if (pedantic || ! is_main) pedwarn (ISO C++ forbids declaration of %qs with no type, name); else warning (OPT_Wreturn_type, ISO C++ forbids declaration of %qs with no type, name); As you can see, return types may be omitted in system headers (probably because there were too many systems with such headers around). Otherwise you should get a diagnostic. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32208
[Bug fortran/31831] FAIL: gfortran.dg/assumed_charlen_function_5.f90 -O (test for excess errors)
--- Comment #3 from danglin at gcc dot gnu dot org 2007-06-06 22:57 --- Not failing anymore. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31831
[Bug tree-optimization/32169] [4.3 Regression] Ice in set_value_range, at tree-vrp.c:326
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-06-06 23:04 ---
Reduced testcase, I cannot remove the inline function for some reason:
void f(char);
static inline
void * __memset_generic(char c)
{
f(c);
}
int prepare_startup_playback_urb(
int b,
int c
)
{
char d;
if (b)
__memset_generic(c == ( 1) ? 0x80 : 0);
else
__memset_generic (c == ( 1) ? 0x80 : 0);
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-06-06 23:04:14
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32169
[Bug other/32078] [4.3 Regression] Make FAILURE in 4.3.0 - `CXXFLAGS' has changed error causes libltdl: No such file or directory
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|Make FAILURE in 4.3.0 - |[4.3 Regression] Make |`CXXFLAGS' has changed error|FAILURE in 4.3.0 - |causes libltdl: No such|`CXXFLAGS' has changed error |file or directory |causes libltdl: No such ||file or directory Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32078
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Comment #29 from pinskia at gcc dot gnu dot org 2007-06-06 23:23 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug middle-end/32209] [4.3 Regression] Boot failure Comparing stages 2 and 3 with --disable-checking
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|Boot failure Comparing |[4.3 Regression] Boot |stages 2 and 3 |failure Comparing stages 2 ||and 3 with --disable- ||checking Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32209
[Bug libgcj/32227] [4.3 Regression] ../gcc/libjava/classpath/include/config-int.h:7:20: error: stdint.h: No such file or directory
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||build Summary|../gcc/libjava/classpath/inc|[4.3 Regression] |lude/config-int.h:7:20: |../gcc/libjava/classpath/inc |error: stdint.h: No such|lude/config-int.h:7:20: |file or directory |error: stdint.h: No such ||file or directory Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32227
[Bug ada/32234] Default pointer initialization not occuring - due to the use of
--- Comment #5 from anhvofrcaus at gmail dot com 2007-06-06 23:27 --- Valgrind is helful only if there is a crash (segmentation fault). However, there is no seg fault when executed in this case. Therefore, there would be exclusive conclusion. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32234
[Bug ada/32234] Default pointer initialization not occuring - due to the use of
--- Comment #6 from anhvofrcaus at gmail dot com 2007-06-06 23:29 --- Oop! I meant inclusive conclusion. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32234
[Bug target/32218] [4.2/4.3 Regression] segfault with -O1 -ftree-vectorize
-- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet||ia64-*-* Last reconfirmed|-00-00 00:00:00 |2007-06-06 23:44:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32218
[Bug fortran/32235] gfortran - incorrectly position text file after backspace
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-06-07 00:14 --- Investigating -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-07 00:14:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32235
[Bug preprocessor/23479] Implement binary constants with a 0b prefix
--- Comment #30 from manu at gcc dot gnu dot org 2007-06-07 00:31 --- (In reply to comment #29) Fixed. I was waiting for updating http://gcc.gnu.org/gcc-4.3/changes.html before closing, but whatever... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
[Bug tree-optimization/32231] [4.3 Regression] Segfault in verify_ssa_name
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32231
[Bug tree-optimization/32231] [4.3 Regression] Segfault in verify_ssa_name
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-06-07 01:45 --- (gdb) p debug_generic_expr (stmt) D.1980_10 = 0.0 (gdb) p *stmt_ann (stmt)-operands.use_ops.use_ptr.use $14 = 0xa5a5a5a5 So somebody forgot to update the use cache. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-07 01:45:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32231
