[Bug libfortran/37839] st_parameter_dt has unwanted padding, is out of sync with compiler
--- Comment #16 from jakub at gcc dot gnu dot org 2008-11-22 08:12 --- Subject: Bug 37839 Author: jakub Date: Sat Nov 22 08:10:41 2008 New Revision: 142111 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142111 Log: PR libfortran/37839 * trans-io.c (gfc_build_io_library_fndecls): Decrease pad size back to 16 pointers plus 32 integers. Don't use max integer kind alignment, only gfc_intio_kind's alignment. (gfc_trans_inquire): Only set flags2 if mask2 is non-zero. * ioparm.def: Fix order, bitmasks and types of inquire round, sign and pending fields. Move u in dt before id. * io.c (gfc_free_inquire): Free decimal and size exprs. (match_inquire_element): Match size instead of matching blank twice. (gfc_resolve_inquire): Resolve size. * gfortran.dg/f2003_inquire_1.f03: New test. * gfortran.dg/f2003_io_1.f03: Remove xfail. * gfortran.dg/f2003_io_4.f03: Likewise. * gfortran.dg/f2003_io_5.f03: Likewise. * gfortran.dg/f2003_io_6.f03: Likewise. * gfortran.dg/f2003_io_7.f03: Likewise. * io/io.h (IOPARM_INQUIRE_HAS_ROUND, IOPARM_INQUIRE_HAS_SIGN, IOPARM_INQUIRE_HAS_PENDING): Adjust values. (st_parameter_inquire): Reorder and fix types of round, sign and pending fields. (st_parameter_43, st_parameter_44): Removed. (st_parameter_dt): Put back struct definition directly to u.p declaration. Change type of u.p.size_used from gfc_offset to GFC_IO_INT. Decrease back size of u.pad to 16 pointers and 32 ints. Put id, pos, asynchronous, blank, decimal, delim, pad, round and sign fields after the union. * io/inquire.c (inquire_via_unit, inquire_via_filename): Only read flags2 if it is defined. * io/transfer.c (read_sf, read_block_form, write_block): Cast additions to size_used to GFC_IO_INT instead of gfc_offset. (data_transfer_init): Clear whole u.p struct. Adjust for moving id, pos, asynchronous, blank, decimal, delim, pad, round and sign fields from u.p directly into st_parameter_dt. (finalize_transfer): Don't cast size_used to GFC_IO_INT. * io/file_pos.c (st_endfile): Clear whole u.p struct. Added: trunk/gcc/testsuite/gfortran.dg/f2003_inquire_1.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/fortran/ioparm.def trunk/gcc/fortran/trans-io.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/f2003_io_1.f03 trunk/gcc/testsuite/gfortran.dg/f2003_io_4.f03 trunk/gcc/testsuite/gfortran.dg/f2003_io_5.f03 trunk/gcc/testsuite/gfortran.dg/f2003_io_6.f03 trunk/gcc/testsuite/gfortran.dg/f2003_io_7.f03 trunk/libgfortran/ChangeLog trunk/libgfortran/io/file_pos.c trunk/libgfortran/io/inquire.c trunk/libgfortran/io/io.h trunk/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37839
[Bug tree-optimization/38224] New: libdecnumber/bid/host-ieee32.c:50: internal compiler error: fold check: original tree changed by fold
With SVN r142097, configured with checking enabled: $ ../gcc/configure --disable-multilib --disable-static --prefix=/home/edwin/gcc_inst/ --enable-languages=c,c++ --enable-checking=assert,df,fold,gc,misc,rtl,rtlflag,runtime,tree $ source='../../gcc/libdecnumber/bid/host-ieee32.c' object='host-ieee32.o' libtool=no /home/edwin/gcc-obj/./prev-gcc/xgcc -B/home/edwin/gcc-obj/./prev-gcc/ -B/home/edwin/gcc_inst//x86_64-unknown-linux-gnu/bin/ -I../../gcc/libdecnumber -I. -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -Wcast-qual -pedantic -Wno-long-long -Werror -I../../gcc/libdecnumber -I. -c ../../gcc/libdecnumber/bid/host-ieee32.c ../../gcc/libdecnumber/bid/host-ieee32.c: In function __host_to_ieee_32: ../../gcc/libdecnumber/bid/host-ieee32.c:50: internal compiler error: fold check: original tree changed by fold Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: libdecnumber/bid/host-ieee32.c:50: internal compiler error: fold check: original tree changed by fold Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38224
[Bug tree-optimization/38224] libdecnumber/bid/host-ieee32.c:50: internal compiler error: fold check: original tree changed by fold
--- Comment #1 from edwintorok at gmail dot com 2008-11-22 08:21 ---
Testcase:
$ /home/edwin/gcc-obj/./prev-gcc/xgcc -B/home/edwin/gcc-obj/./prev-gcc/
-B/home/edwin/gcc_inst//x86_64-unknown-linux-gnu/bin/ -Wfatal-errors -c -O1
testcase-min.i
/* testcase */
typedef unsigned int UINT32;
typedef struct {} decimal32;
void __host_to_ieee_32 (UINT32 in, decimal32 * out)
{
memcpy ((char *) out, (char *) in, 4);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38224
[Bug target/37880] Documentation of option -mcmodel=medium is wrong
--- Comment #4 from jakub at gcc dot gnu dot org 2008-11-22 08:22 --- Subject: Bug 37880 Author: jakub Date: Sat Nov 22 08:21:04 2008 New Revision: 142112 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142112 Log: PR target/37880 * doc/invoke.texi: Adjust wording of -mcmodel=medium description. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37880
[Bug target/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c
--- Comment #85 from jakub at gcc dot gnu dot org 2008-11-22 08:24 --- Subject: Bug 37170 Author: jakub Date: Sat Nov 22 08:22:52 2008 New Revision: 142113 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142113 Log: PR target/37170 * final.c (mark_symbol_refs_as_used): New function. * output.h (mark_symbol_refs_as_used): New prototype. * config/s390/s390.c (s390_mark_symbol_ref_as_used): Removed. (s390_output_pool_entry): Use mark_symbol_refs_as_used. * config/arm/arm.md (consttable_4): Likewise. Modified: trunk/gcc/config/arm/arm.md trunk/gcc/config/s390/s390.c trunk/gcc/final.c trunk/gcc/output.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37170
[Bug target/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c
--- Comment #86 from jakub at gcc dot gnu dot org 2008-11-22 08:27 --- Subject: Bug 37170 Author: jakub Date: Sat Nov 22 08:26:24 2008 New Revision: 142114 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142114 Log: PR target/37170 * final.c (mark_symbol_refs_as_used): New function. * output.h (mark_symbol_refs_as_used): New prototype. * config/s390/s390.c (s390_mark_symbol_ref_as_used): Removed. (s390_output_pool_entry): Use mark_symbol_refs_as_used. * config/arm/arm.md (consttable_4): Likewise. Modified: trunk/gcc/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37170
[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*
--- Comment #26 from jakub at gcc dot gnu dot org 2008-11-22 08:28 --- Subject: Bug 37316 Author: jakub Date: Sat Nov 22 08:27:04 2008 New Revision: 142115 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142115 Log: PR middle-end/37316 * function.c (assign_parm_remove_parallels): Pass data-passed_type as third argument to emit_group_store. Modified: trunk/gcc/ChangeLog trunk/gcc/function.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37316
[Bug middle-end/37323] [4.4 Regression] __builtin_apply failures
--- Comment #13 from jakub at gcc dot gnu dot org 2008-11-22 08:30 --- Subject: Bug 37323 Author: jakub Date: Sat Nov 22 08:28:44 2008 New Revision: 142116 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142116 Log: PR middle-end/37323 * builtins.c (expand_builtin_apply_args): Emit sequence before parm_birth_insn instead of after entry_of_function's first insn. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37323
[Bug libfortran/37839] st_parameter_dt has unwanted padding, is out of sync with compiler
--- Comment #17 from jakub at gcc dot gnu dot org 2008-11-22 08:30 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37839
[Bug target/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c
--- Comment #87 from jakub at gcc dot gnu dot org 2008-11-22 08:31 --- Fixed even on the arm. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37170
[Bug middle-end/37323] [4.4 Regression] __builtin_apply failures
--- Comment #14 from jakub at gcc dot gnu dot org 2008-11-22 08:32 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37323
[Bug fortran/37735] Allocatable components in vectors of derived types cause ICE on assignment
-- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-22 09:00:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37735
[Bug fortran/37735] Allocatable components in vectors of derived types cause ICE on assignment
--- Comment #2 from pault at gcc dot gnu dot org 2008-11-22 09:09 --- Oddly, type Path type(Spline), allocatable :: r(:) end type Path compiles OK:-) Given that the ICE is caused by gcc_assert (GFC_DESCRIPTOR_TYPE_P (type)) it must be that the type(Spline) :: r(3), which is definitely not a descriptor type, is incorrectly being treated as if it is. The allocatable component code in trans-array.c is meant to handle this, so there is a coding error somewhere. I'm on to it:-) Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2008-11-22 09:00:28 |2008-11-22 09:09:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37735
[Bug tree-optimization/21485] [4.2/4.3/4.4 Regression] missed load PRE, PRE makes i?86 suck
--- Comment #37 from steven at gcc dot gnu dot org 2008-11-22 09:13 --- Re: comment #35 and comment #36 That is code hoisting, again. See Bug 23286 and some the bugs closed as a duplicate of Bug 23286. Looks like it's time to implement tree-level hoisting :-) -- steven at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||23286 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485
[Bug regression/38223] segfault in glib testsuite with trunk
--- Comment #2 from dirtyepic at gentoo dot org 2008-11-22 09:35 --- Created an attachment (id=16747) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16747action=view) relation-test-min03.i minimal testcase. this also fails with 4.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38223
[Bug middle-end/30521] if (i == n) ++i; or i += i == n;?
--- Comment #5 from steven at gcc dot gnu dot org 2008-11-22 09:51 ---
I created a t.c with both functions in it:
unsigned int f1(unsigned int i, unsigned int n) {++i; if (i == n) ++i; return
i;}
unsigned int f2(unsigned int i, unsigned int n) {++i; i += i == n; return i;}
With today's trunk on x86_64, I get:
.file t.c
.text
.align 16
.globl f1
.type f1, @function
f1:
.LFB0:
leal1(%rdi), %eax
addl$2, %edi
cmpl%esi, %eax
cmove %edi, %eax
ret
.LFE0:
.size f1, .-f1
.align 16
.globl f2
.type f2, @function
f2:
.LFB1:
addl$1, %edi
xorl%eax, %eax
cmpl%esi, %edi
sete%al
addl%edi, %eax
ret
.LFE1:
.size f2, .-f2
.section.eh_frame,aw,@progbits
.Lframe1:
.long .LECIE1-.LSCIE1
.LSCIE1:
.long 0x0
.byte 0x1
.string zR
.byte 0x1
.byte 0x78
.byte 0x10
.byte 0x1
.byte 0x3
.byte 0xc
.byte 0x7
.byte 0x8
.byte 0x11
.byte 0x10
.byte 0x1
.align 8
.LECIE1:
.LSFDE1:
.long .LEFDE1-.LASFDE1
.LASFDE1:
.long .LASFDE1-.Lframe1
.long .LFB0
.long .LFE0-.LFB0
.byte 0x0
.align 8
.LEFDE1:
.LSFDE3:
.long .LEFDE3-.LASFDE3
.LASFDE3:
.long .LASFDE3-.Lframe1
.long .LFB1
.long .LFE1-.LFB1
.byte 0x0
.align 8
.LEFDE3:
.ident GCC: (GNU) 4.4.0 20081122 (experimental) [trunk revision
142117]
.section.note.GNU-stack,,@progbits
So still not the same functions.
For x86 (32bit) with -march=core2, I get similar code (f1 with a cmove).
Without a -march option, I get code with a jump.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|2007-01-22 00:29:40 |2008-11-22 09:51:57
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30521
[Bug middle-end/30521] if (i == n) ++i; or i += i == n;?
--- Comment #6 from steven at gcc dot gnu dot org 2008-11-22 10:04 ---
Ah, now I see what Pinski meant at comment #2.
Before CSE, we still have the original code for f1:
unsigned int f(unsigned int i, unsigned int n)
{
i.20 = i + 1;
if (i.20 == n) i.20 = i.20 + 1;
return i.20;
}
After CSE (but before the first if-conversion pass) it's been transformed to:
unsigned int f(unsigned int i, unsigned int n)
{
i.20 = i + 1;
if (i.20 == n) i.20 = i + 2;
return i.20;
}
The form of the code before CSE is caught in noce_try_addcc. The second form
obviously not (because we don't know that the value of i.20 is i + 1).
So this comes down to a pass ordering problem. Or, one could argue that CSE
should not perform this transformation if (say) i.20 = i + 1 is not made dead
code by the transformation to i.20 = i + 2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30521
[Bug testsuite/38221] FAIL: gcc.c-torture/compile/sync-3.c -O0 (test for warnings, line )
--- Comment #1 from ubizjak at gmail dot com 2008-11-22 10:11 --- This test is there to check that at least one message about changed NAND semantics per file is generated. x86_64 does: ~/gcc-build/gcc/cc1 -O0 -w -quiet sync-3.c sync-3.c: In function test_op_ignore: sync-3.c:74: note: __sync_fetch_and_nand changed semantics in GCC 4.4 Does PA somehow bypass standard expansion of __sync intrinsics? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38221
[Bug middle-end/30521] if (i == n) ++i; or i += i == n;?
--- Comment #7 from bonzini at gnu dot org 2008-11-22 10:15 --- Subject: Re: if (i == n) ++i; or i += i == n;? The form of the code before CSE is caught in noce_try_addcc. The second form obviously not (because we don't know that the value of i.20 is i + 1). So this comes down to a pass ordering problem. I'll just point out that the df merge allowed much better freedom in pass ordering. Ifconv1 could be anticipated before CSE and fwprop. Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30521
[Bug testsuite/38222] gcc.target/i386/sse4_2-popcntl.c fails on i686-apple-darwin9
--- Comment #2 from ubizjak at gmail dot com 2008-11-22 10:22 --- (In reply to comment #1) GNU assembler supports both popcntl %edx, %eax popcnt %edx, %eax I guess we can just generate popcnt %edx, %eax No, we won't cripple the output due to assembler bugs. I will add a configure check for broken assembler, it is the same situation as with sun as and ffreep insn (and some version of gnu as with sahf insn). -- ubizjak at gmail dot com changed: What|Removed |Added CC|ubizjak at gmail dot com| 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 |2008-11-22 10:22:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38222
[Bug tree-optimization/35639] [4.3/4.4 Regression] -fprofile-generate + PRE = big compile-time
--- Comment #7 from steven at gcc dot gnu dot org 2008-11-22 10:53 --- The last time this bug was reconfirmed, was in March 2008. PRE has been completely rewritten since then. With today's trunk, I still see PRE take most of the compile time, but it's only 20% (on x86 and on x86_64 with Richi's testcase from t3.c.gz). Paolo, do you still see this problem? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35639
[Bug rtl-optimization/21676] [4.2/4.3/4.4 Regression] Optimizer regression: SciMark sparse matrix benchmark
--- Comment #16 from steven at gcc dot gnu dot org 2008-11-22 10:31 --- See comment #7 and comment #13. -- steven at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||23286 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21676
[Bug target/34571] [4.3/4.4 Regression] Segfault in alpha_expand_mov at -O3
--- Comment #14 from steven at gcc dot gnu dot org 2008-11-22 11:17 --- Ping? Patch exists, tested and all, and just needs a re-test and then submit... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34571
[Bug tree-optimization/26243] [4.2/4.3/4.4 Regression] reassoc is not documented in passes.texi
--- Comment #5 from steven at gcc dot gnu dot org 2008-11-22 11:23 --- passes.texi *does* have documentation for the reassoc pass. Fixed by dnovillo in r114200: PR 26242 * doc/passes.texi: Add documentation for pass_vrp, pass_ipa_pta, pass_fre, pass_store_ccp, pass_copy_prop, pass_store_copy_prop, pass_merge_phi, pass_nrv, pass_return_slot, pass_object_size, pass_lim, pass_linear_transform, pass_empty_loop, pass_complete_unroll, pass_loop_prefetch and pass_stdarg. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26243
[Bug tree-optimization/21559] [4.2/4.3/4.4 Regression] missed jump threading
--- Comment #10 from steven at gcc dot gnu dot org 2008-11-22 11:36 ---
Trunk today generates the following code (this is the final_cleanup dump):
;; Function foo (foo)
foo ()
{
static char eof_reached = 0;
int bytes;
int toread;
bb 2:
toread = 4096;
bb 3:
bytes = bar (toread);
if (bytes = 0)
goto bb 4;
else
goto bb 5;
bb 4:
if (bytes != 0)
goto bb 6;
else
goto bb 7;
bb 5:
toread = toread - bytes;
bb 6:
if (toread != 0)
goto bb 3;
else
goto bb 8;
bb 7:
eof_reached = 1;
bb 8:
return;
}
Looks like we can't do any better than that -- can we??
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21559
[Bug tree-optimization/17116] Missed jump threading/bypassing optimization with loop and % (or ands)
--- Comment #8 from steven at gcc dot gnu dot org 2008-11-22 11:45 --- I don't think anyone is interested in fixing this - WONTFIX. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17116
[Bug libfortran/38225] New: [4.4 regression] RESHAPE bounds with multi-dimensional SOURCE
$ cat resh.f90 program main integer, dimension(2,2) :: a data a /1, 2, 3, 4/ print *,reshape(a,(/4/)) end program main $ gfortran -fbounds-check resh.f90 $ ./a.out Fortran runtime error: Incorrect size in SOURCE argument to RESHAPE intrinsic: is 2, should be 4 -- Summary: [4.4 regression] RESHAPE bounds with multi-dimensional SOURCE Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38225
[Bug libfortran/38225] [4.4 regression] RESHAPE bounds with multi-dimensional SOURCE
-- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-22 12:30:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38225
[Bug target/38151] structures with _Complex arguments are not passed correctly
--- Comment #21 from ubizjak at gmail dot com 2008-11-22 12:33 --- This is a trace what happens in the testcase, from .expand dump: (2) [frame + 8 ]- si (3) [frame + 16]- dx (4) r62 - di (8) r63 - virtual-incoming-args + 0 (9) r64 - virtual-stack-vars - 64 (10) [r64] - 8;; gp_offset (11) r65- virtual-stack-vars - 64 (12) [r65 + 8 ] - virtual-incoming-args;; overflow_arg_area (13) r66- virtual-stack-vars - 64 (14) [r66 + 16] - frame;; reg_save_area (15) r61- [virtual-stack-vars - 64];; gp_offset if (r61 39) goto label 27 (19) r67- virtual-stack-vars - 32 (20) r68- zext (r61) (21) r69- [virtual-stack-vars - 48];; reg_save_area (22) r70- [r69 + r68] (23) [r67] - r70 (24) r58- virtual-stack-vars - 32 goto label 32 label 27: (29) r72- [virtual-stack-vars - 56];; overflow_arg_area (30) r71- r72 + 15 (31) r58- r71 -16 label 32: (34) r73- [r58] (35) [virtual-stack-vars - 16] - r73 (36) r74- [r58 + 8] (37) [virtual-stack-vars - 8 ] - r74 (38) r60- [virual-stack-vars - 12] ;; arg$b$real (39) r59- [virual-stack-vars - 8 ] ;; arg$b$imag So, around insn (22), gcc forgets to copy dx register to reg_save_area. r74 is then read from uninitialized reg_save_area slot. I'm looking at va-arg handling implementation in i386.c. But I'm not familiar with this code, so a bit of help would be most welcome here. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|ubizjak at gmail dot com|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38151
[Bug debug/38226] New: Configure time option --with-stabs does not work
GCC 4.4.0 20081121. Was configured with --with-stabs, but produces DWARF-2 debug info by default. -- Summary: Configure time option --with-stabs does not work Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: d dot g dot gorbachev at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i386-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38226
[Bug c/38227] New: gcc fails to correctly pass arguments with ms_abi function pointers
When calling function pointers that have been marked with __attribute__((ms_abi)) the arguments will not be passed correctly. A simple testcase is enough to expose the wrong behavior. -- Summary: gcc fails to correctly pass arguments with ms_abi function pointers Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: m dot b dot lankhorst at gmail dot com GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38227
[Bug libfortran/38225] [4.4 regression] RESHAPE bounds with multi-dimensional SOURCE
-- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38225
[Bug c/38227] gcc fails to correctly pass arguments with ms_abi function pointers
--- Comment #1 from m dot b dot lankhorst at gmail dot com 2008-11-22 13:33 --- Created an attachment (id=16748) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16748action=view) Minimal testcase Compile with amd64 compiler without optimizations and run it. Expected: Number is: 1234567890abcdef Actual result: Number is: 0 (May vary) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38227
[Bug testsuite/38222] gcc.target/i386/sse4_2-popcntl.c fails on i686-apple-darwin9
--- Comment #3 from uros at gcc dot gnu dot org 2008-11-22 14:18 --- Subject: Bug 38222 Author: uros Date: Sat Nov 22 14:16:57 2008 New Revision: 142121 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142121 Log: PR target/38222 * config/i386/i386.md (SWI248): New mode iterator. (SWI32): Remove mode iterator. (popcountmode2): Rename from popcounthi2, popcountsi2 and popcounthi2 insn patterns. Macroize pattern using SWI248 mode iterator. Generate popcnt mnemonic without mode extensions for Darwin x86 targets. (*popcountmode2_cmp): Ditto. (*popcountsi2_cmp_zext): Generate popcnt mnemonic without mode extensions for Darwin x86 targets. testsuite/ChangeLog: PR target/38222 * gcc.target/i386/funcspec-3.c: Scan for popcnt on Darwin targets. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/funcspec-3.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38222
[Bug testsuite/38222] gcc.target/i386/sse4_2-popcntl.c fails on i686-apple-darwin9
--- Comment #4 from ubizjak at gmail dot com 2008-11-22 14:21 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||11/msg01175.html Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38222
[Bug target/38201] -mfma/-mavx and -msse5/-msse4a don't work together
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-11-22 15:03 --- We should have -mfma to enable a fused multiply-add instruction that is available when enabling either -msse5 or -mavx. -mfma should not itself enable any of the instruction set enabling features. HJ, why did you need -mfma and could not have used -mfused-madd for this? IMHO -mfma is confusing and should be removed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38201
[Bug tree-optimization/37416] [4.4 Regression] Failure to return number of loop iterations
--- Comment #2 from irar at il dot ibm dot com 2008-11-22 15:08 --- (In reply to comment #1) This bug is shamefully incomplete. There is no way anyone willing to give this a look can know what to look for. For example, a few things one would have to know before he/she can even begin to consider whether/how to analyze the problem: 1. What is the target where you see this? 2. What compiler flags are you using? -O3 3. Where do you look for the number of iterations (which dump)? vectorizer's dump 4. What missed-optimization does this cause (something not vectorized)? the loop is not vectorized because the number of iterations is unknown Please read http://gcc.gnu.org/bugs.html#report before filing more bugs. -- irar at il dot ibm dot com changed: What|Removed |Added GCC build triplet||x86_64-suse-linux GCC host triplet||x86_64-suse-linux GCC target triplet||x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37416
[Bug target/38201] -mfma/-mavx and -msse5/-msse4a don't work together
--- Comment #11 from hjl dot tools at gmail dot com 2008-11-22 15:09 --- (In reply to comment #10) We should have -mfma to enable a fused multiply-add instruction that is available when enabling either -msse5 or -mavx. -mfma should not itself enable any of the instruction set enabling features. HJ, why did you need -mfma and could not have used -mfused-madd for this? IMHO -mfma is confusing and should be removed. Intel FMA is a separate instruction set with its own feature bit in CPUID. Using -mfused-madd -mavx to enable an instruction set doesn't look appropriate to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38201
[Bug c++/38228] New: ICE when abusing std::function
hi, i just tried this for fun (yes i'm aware it doesnt work :P):
#include iostream
#include functional
struct foo
{
void bar(){std::couthistd::endl;}
};
int main()
{
foo f;
void (foo::*a)()=foo::bar;
std::functionvoid() funct=((f).*(a));
}
and it results in:
[EMAIL PROTECTED] ~/testcases/litb g++ main.cpp --std=gnu++0x
main.cpp: In function int main():
main.cpp:13: internal compiler error: in gimplify_expr, at gimplify.c:6864
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[EMAIL PROTECTED] ~/testcases/litb g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/usr --enable-shared
--enable-languages=c,c++,fortran,objc,obj-c++ --enable-threads=posix
--mandir=/usr/share/man --infodir=/usr/share/info --enable-__cxa_atexit
--disable-multilib --libdir=/usr/lib --libexecdir=/usr/lib --enable-clocale=gnu
--with-tune=generic
Thread model: posix
gcc version 4.4.0 20081107 (experimental) (GCC)
--
Summary: ICE when abusing std::function
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aep at exys dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38228
[Bug target/38201] -mfma/-mavx and -msse5/-msse4a don't work together
--- Comment #12 from hjl dot tools at gmail dot com 2008-11-22 15:15 --- Richard asked: Why should it (-mavx -msse5) be disallowed if a user asks for it? Do we disallow -msse4a -mssse4? Reply: -msse4a -mssse4 can generate code which runs if you check the feature bit in CPUID before calling an appropriate function. But -mavx -msse5 will generate codes which won't run on any machines. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38201
[Bug target/38201] -mfma/-mavx and -msse5/-msse4a don't work together
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-11-22 15:31 --- I see. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38201
[Bug regression/38223] segfault in glib testsuite with trunk
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-11-22 15:38 --- Your minimal testcase likely accesses the array out-of-bounds. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38223
[Bug c/25509] can't disable __attribute__((warn_unused_result))
--- Comment #20 from thomas at mich dot com 2008-11-22 15:42 --- There minimally needs to be a way of turning this warning off in GCC. GCC should not be trying to micromanage coding styles - either of the rest of gnu software or anywhere else, but at least until you clean up every bit of your own code, there should be a way of disabling the warning clutter. HUNDREDS OF WARNINGS ARE NO BETTER THAN NO WARNINGS AT ALL. I can't even find errors in the pages bilge that now spews out from a normal compile. It might be and probably is appropriate with -Wall turned on. And I really would like to be able to treat warnings as errors when they are legitimate warnings. For now, I've hexedited cc1 to change the string so it won't be found and have to add -Wno-attributes so I don't get errors from things I might need. I'm getting it even with -Wall turned off (version 4.3.2). And I still should be able to disable it. Somehow GCC and gnu thinks int dummy93857 = fwrite( buf, 1, 1, fp ); is so far superior code to just fwrite( buf, 1, 1, fp ); that it now must enforce it on every possible line. Sometimes ignoring returns is the right (or better) thing to do instead of cluttering up the code. Not every line of code is critical kernel or system code that can introduce security holes. Not every call needs to have its exact behavior on the particular instance carefully monitored. The author of the libraries can often make a bad choice. And there are hundreds of instances - maybe 99% of them are good, but the bad ones on common functions are causing a great deal of noise. And there is not a pedantic_warn_unused_result (with a -Wunused-result which would promote it), which would be perfect for the instances noted here and more easily made. And perhaps even an error_unused_result. I think it would be easy to argue for the large bodies of code that certain functions have return values that are conventionally ignored so should only warn at a higher level of checking than ordinary warnings. Right now I have to argue each individual case with the only options to keep it (and the pages of new warnings) or remove it (and in the few cases where it might be critical be silent). gcc currently has no middle option. Sometimes return values are at a point where you can't do anything anyway like the exit example. Somehow, if a printf, or an equivalent fwrite of a formatted string to stdout or stderr fails, what do you do? Errors have both probability and criticality. And there are a lot of highly improbable cases, and lots of non-critical sections. If my CPU is melting down or my memory giving errors, I have worse problems. If the number of parameters doesn't match a function declaration, it is likely an error that will cause things to fail 90% of the time. 99.99% of the time, f//read/write will return the expected value. If fclose fails, what do you do? And fwrite won't return the error, fflush might (but if it doesn't do a sync(), and writes are cached to a failing disk...). Perhaps it is because we don't have a finer gradation (an INFO or MAY equivalent to the SHOULD/WARNING, MUST/ERROR). The lack of checking a return, at least in the cases where the functions are mainly the side-effect (and if fwrite fails, perhaps there should be a signal or exception, and not depend on the return code if it is so critical) doesn't reach the threshold of a PERMANENTLY ENABLED warning. It does reach the threshold of the things I usually check with -pedantic. Like signed-unsigned mismatches. Subtle printf format errors. In my later QC checks I do turn everything on and verify every line of code. I would work on adding a pedantic_* (and maybe error_*) set of attributes, but until then, leave the choice to the author of the program. THIS WARNING IS A *GOOD* THING, but it doesn't apply to every program or every function, or every use of that function. Many functions are used both in critical and noncritical forms, and there are a lot of existing programs that instead of being clear are now cluttered. One of the reasons I don't normally use C++ is the stupidity where I am forced to lower the quality of my code because of what it enforces or doesn't enforce so instead of a concise function, it will only compile a bloated blob. This warning is something like that. I write code in C. I know better what I'm writing that you or the compiler does. I know when errors are critical and or likely at a specific point in my code. And all I want is the choice to either have this (or any other common but not critical warning) enabled or disabled. -- thomas at mich dot com changed: What|Removed |Added CC||thomas at mich dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509
[Bug tree-optimization/21559] [4.2/4.3 Regression] missed jump threading
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-11-22 15:47 --- I don't see how. Fixed thus, WONTFIX on the branches. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to fail|4.3.0 4.2.0 |4.3.2 4.2.4 Resolution||FIXED Target Milestone|4.2.5 |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21559
[Bug tree-optimization/37416] [4.4 Regression] Failure to return number of loop iterations
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-22 15:47:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37416
[Bug tree-optimization/35639] [4.3/4.4 Regression] -fprofile-generate + PRE = big compile-time
--- Comment #8 from bonzini at gnu dot org 2008-11-22 16:00 --- The problem was that without -fprofile-generate the time spent there was basically zero. Since the profiling code is building a MST of the control-flow graph, it should produce absolutely no PRE opportunity and it's a pity that it causes such a slowdown. I wonder if there is some low-hanging fruit to eliminate value numbers that cannot be redundant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35639
[Bug testsuite/38221] FAIL: gcc.c-torture/compile/sync-3.c -O0 (test for warnings, line )
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2008-11-22 16:00 --- Subject: Re: FAIL: gcc.c-torture/compile/sync-3.c -O0 (test for warnings, line ) Does PA somehow bypass standard expansion of __sync intrinsics? The hpux PA targets have no support for these intrinsics. There is a library implementation on linux using kernel support. However, this bug now seems fixed. Maybe this change: 2008-11-21 Ben Elliston [EMAIL PROTECTED] * gcc.c-torture/compile/sync-3.c: Remove dg-message directive. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38221
[Bug testsuite/38221] FAIL: gcc.c-torture/compile/sync-3.c -O0 (test for warnings, line )
--- Comment #3 from danglin at gcc dot gnu dot org 2008-11-22 16:08 --- Fixed by change. -- 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=38221
[Bug fortran/37735] Allocatable components in vectors of derived types cause ICE on assignment
--- Comment #3 from pault at gcc dot gnu dot org 2008-11-22 16:57 --- Created an attachment (id=16749) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16749action=view) Provisional fix for PR This is half way through regtesting - have to go to a movie, so will see later:-) Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37735
[Bug ada/38229] New: FAIL: c954a01
splitting /test/gnu/gcc/objdir/gcc/testsuite/ada/acats/tests/c9/c954a01.a into: c954a01_0.ads c954a01_0.adb c954a01.adb BUILD c954a01.adb gnatmake --GCC=/test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ -gnat ws -O2 -I/test/gnu/gcc/objdir/gcc/testsuite/ada/acats/support c954a01.adb -largs --GCC=/test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /test/gnu/gcc/objdir/gcc/xgcc -c -B/test/gnu/gcc/objdir/gcc/ -gnatws -O2 -I/test /gnu/gcc/objdir/gcc/testsuite/ada/acats/support c954a01.adb /test/gnu/gcc/objdir/gcc/xgcc -c -B/test/gnu/gcc/objdir/gcc/ -gnatws -O2 -I/test /gnu/gcc/objdir/gcc/testsuite/ada/acats/support c954a01_0.adb gnatbind -I/test/gnu/gcc/objdir/gcc/testsuite/ada/acats/support -x c954a01.ali gnatlink c954a01.ali --GCC=/test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/ gcc/ RUN c954a01 ,.,. C954A01 ACATS 2.5 08-11-22 10:46:18 C954A01 Requeue without abort - check that the abort is deferred until after the rendezvous completes. (Task to PO). * C954A01 Task not aborted following completion of entry call. C954A01 FAILED . FAIL: c954a01 -- Summary: FAIL: c954a01 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa2.0w-hp-hpux11.11 GCC host triplet: hppa2.0w-hp-hpux11.11 GCC target triplet: hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38229
[Bug target/38151] structures with _Complex arguments are not passed correctly
--- Comment #22 from ubizjak at gmail dot com 2008-11-22 17:07 ---
Aliasing problems, gcc shoots himself in the foot...
When container consists of registers in different modes (due to
X86_64_INTEGERSI_CLASS optimization):
(parallel:BLK [
(expr_list:REG_DEP_TRUE (reg:DI 0 ax)
(const_int 0 [0x0]))
(expr_list:REG_DEP_TRUE (reg:SI 1 dx)
(const_int 8 [0x8]))
])
then ix86_gimplify_va_arg happily creates code with invalid aliasing (from
_.gimple dump):
addr.0 = va_arg_tmp.3;
addr.4 = (long unsigned int *) addr.0;
int_addr.5 = (long unsigned int *) int_addr.1;
D.1615 = *int_addr.5;
*addr.4 = D.1615;
addr.6 = (unsigned int *) addr.0;
D.1617 = addr.6 + 8;
We access addr.0 as (long unsigned int *) and as (unsigned int *. Following
optimization passes are more than happy to remove the second access.
So to prove my point, testcase compiled with -fno-strict-aliasing works OK.
These problems also apply to FPmode parameters passing through SSE regs, so
following patch moves registers from register area to tmp area in generic mode
that fits argument passing registers best: DImode for integer and V4SFmode for
SSE registers. This avoids aliasing problems.
Index: i386.c
===
--- i386.c (revision 142120)
+++ i386.c (working copy)
@@ -6750,7 +6750,8 @@ ix86_gimplify_va_arg (tree valist, tree
{
rtx slot = XVECEXP (container, 0, i);
rtx reg = XEXP (slot, 0);
- enum machine_mode mode = GET_MODE (reg);
+ enum machine_mode mode
+ = SSE_REGNO_P (REGNO (reg)) ? V4SFmode : DImode;
tree piece_type = lang_hooks.types.type_for_mode (mode, 1);
tree addr_type = build_pointer_type (piece_type);
tree src_addr, src;
--
ubizjak at gmail dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com
|dot org |
Status|NEW |ASSIGNED
Last reconfirmed|2008-11-16 20:58:10 |2008-11-22 17:07:30
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38151
Re: [Bug c/25509] can't disable __attribute__((warn_unused_result))
Sent from my iPhone On Nov 22, 2008, at 7:42 AM, thomas at mich dot com [EMAIL PROTECTED] wrote: --- Comment #20 from thomas at mich dot com 2008-11-22 15:42 --- There minimally needs to be a way of turning this warning off in GCC. GCC should not be trying to micromanage coding styles - either of the rest of gnu software or anywhere else, but at least until you clean up every bit of your own code, there should be a way of disabling the warning clutter. Why GCC is not micromanaging at all, it just allows the developer of the API to have the warning. So your complaints here are useless. HUNDREDS OF WARNINGS ARE NO BETTER THAN NO WARNINGS AT ALL. I can't even find errors in the pages bilge that now spews out from a normal compile. It might be and probably is appropriate with -Wall turned on. And I really would like to be able to treat warnings as errors when they are legitimate warnings. For now, I've hexedited cc1 to change the string so it won't be found and have to add -Wno-attributes so I don't get errors from things I might need. I'm getting it even with -Wall turned off (version 4.3.2). And I still should be able to disable it. Somehow GCC and gnu thinks int dummy93857 = fwrite( buf, 1, 1, fp ); is so far superior code to just fwrite( buf, 1, 1, fp ); that it now must enforce it on every possible line. It is not GCC which thinks that, it is the providers of your headers for fwriye that thinks that. Sometimes ignoring returns is the right (or better) thing to do instead of cluttering up the code. Not every line of code is critical kernel or system code that can introduce security holes. Not every call needs to have its exact behavior on the particular instance carefully monitored. Again we just provide the author of the Api to say that. The author of the libraries can often make a bad choice. Yes and you should complain to them instead of us then. And there are hundreds of instances - maybe 99% of them are good, but the bad ones on common functions are causing a great deal of noise. And there is not a pedantic_warn_unused_result (with a -Wunused-result which would promote it), which would be perfect for the instances noted here and more easily made. And perhaps even an error_unused_result. I think it would be easy to argue for the large bodies of code that certain functions have return values that are conventionally ignored so should only warn at a higher level of checking than ordinary warnings. Right now I have to argue each individual case with the only options to keep it (and the pages of new warnings) or remove it (and in the few cases where it might be critical be silent). gcc currently has no middle option. Also this attribute is not on by default in glibc so you are asking to turn on the style based warnings. Sometimes return values are at a point where you can't do anything anyway like the exit example. Somehow, if a printf, or an equivalent fwrite of a formatted string to stdout or stderr fails, what do you do? Errors have both probability and criticality. And there are a lot of highly improbable cases, and lots of non-critical sections. If my CPU is melting down or my memory giving errors, I have worse problems. If the number of parameters doesn't match a function declaration, it is likely an error that will cause things to fail 90% of the time. 99.99% of the time, f//read/write will return the expected value. If fclose fails, what do you do? And fwrite won't return the error, fflush might (but if it doesn't do a sync(), and writes are cached to a failing disk...). Perhaps it is because we don't have a finer gradation (an INFO or MAY equivalent to the SHOULD/WARNING, MUST/ERROR). The lack of checking a return, at least in the cases where the functions are mainly the side-effect (and if fwrite fails, perhaps there should be a signal or exception, and not depend on the return code if it is so critical) doesn't reach the threshold of a PERMANENTLY ENABLED warning. It does reach the threshold of the things I usually check with -pedantic. Like signed-unsigned mismatches. Subtle printf format errors. In my later QC checks I do turn everything on and verify every line of code. I would work on adding a pedantic_* (and maybe error_*) set of attributes, but until then, leave the choice to the author of the program. THIS WARNING IS A *GOOD* THING, but it doesn't apply to every program or every function, or every use of that function. Many functions are used both in critical and noncritical forms, and there are a lot of existing programs that instead of being clear are now cluttered. One of the reasons I don't normally use C++ is the stupidity where I am forced to lower the quality of my code because of what it enforces or doesn't enforce so instead of a concise function, it will only compile a bloated
[Bug c/25509] can't disable __attribute__((warn_unused_result))
--- Comment #21 from pinskia at gmail dot com 2008-11-22 17:17 --- Subject: Re: can't disable __attribute__((warn_unused_result)) Sent from my iPhone On Nov 22, 2008, at 7:42 AM, thomas at mich dot com [EMAIL PROTECTED] wrote: --- Comment #20 from thomas at mich dot com 2008-11-22 15:42 --- There minimally needs to be a way of turning this warning off in GCC. GCC should not be trying to micromanage coding styles - either of the rest of gnu software or anywhere else, but at least until you clean up every bit of your own code, there should be a way of disabling the warning clutter. Why GCC is not micromanaging at all, it just allows the developer of the API to have the warning. So your complaints here are useless. HUNDREDS OF WARNINGS ARE NO BETTER THAN NO WARNINGS AT ALL. I can't even find errors in the pages bilge that now spews out from a normal compile. It might be and probably is appropriate with -Wall turned on. And I really would like to be able to treat warnings as errors when they are legitimate warnings. For now, I've hexedited cc1 to change the string so it won't be found and have to add -Wno-attributes so I don't get errors from things I might need. I'm getting it even with -Wall turned off (version 4.3.2). And I still should be able to disable it. Somehow GCC and gnu thinks int dummy93857 = fwrite( buf, 1, 1, fp ); is so far superior code to just fwrite( buf, 1, 1, fp ); that it now must enforce it on every possible line. It is not GCC which thinks that, it is the providers of your headers for fwriye that thinks that. Sometimes ignoring returns is the right (or better) thing to do instead of cluttering up the code. Not every line of code is critical kernel or system code that can introduce security holes. Not every call needs to have its exact behavior on the particular instance carefully monitored. Again we just provide the author of the Api to say that. The author of the libraries can often make a bad choice. Yes and you should complain to them instead of us then. And there are hundreds of instances - maybe 99% of them are good, but the bad ones on common functions are causing a great deal of noise. And there is not a pedantic_warn_unused_result (with a -Wunused-result which would promote it), which would be perfect for the instances noted here and more easily made. And perhaps even an error_unused_result. I think it would be easy to argue for the large bodies of code that certain functions have return values that are conventionally ignored so should only warn at a higher level of checking than ordinary warnings. Right now I have to argue each individual case with the only options to keep it (and the pages of new warnings) or remove it (and in the few cases where it might be critical be silent). gcc currently has no middle option. Also this attribute is not on by default in glibc so you are asking to turn on the style based warnings. Sometimes return values are at a point where you can't do anything anyway like the exit example. Somehow, if a printf, or an equivalent fwrite of a formatted string to stdout or stderr fails, what do you do? Errors have both probability and criticality. And there are a lot of highly improbable cases, and lots of non-critical sections. If my CPU is melting down or my memory giving errors, I have worse problems. If the number of parameters doesn't match a function declaration, it is likely an error that will cause things to fail 90% of the time. 99.99% of the time, f//read/write will return the expected value. If fclose fails, what do you do? And fwrite won't return the error, fflush might (but if it doesn't do a sync(), and writes are cached to a failing disk...). Perhaps it is because we don't have a finer gradation (an INFO or MAY equivalent to the SHOULD/WARNING, MUST/ERROR). The lack of checking a return, at least in the cases where the functions are mainly the side-effect (and if fwrite fails, perhaps there should be a signal or exception, and not depend on the return code if it is so critical) doesn't reach the threshold of a PERMANENTLY ENABLED warning. It does reach the threshold of the things I usually check with -pedantic. Like signed-unsigned mismatches. Subtle printf format errors. In my later QC checks I do turn everything on and verify every line of code. I would work on adding a pedantic_* (and maybe error_*) set of attributes, but until then, leave the choice to the author of the program. THIS WARNING IS A *GOOD* THING, but it doesn't apply to every program or every function, or every use of that function. Many functions are used both in critical and noncritical forms, and there are a lot of existing programs that instead of being clear are now cluttered. One of the
[Bug tree-optimization/37709] [4.4 Regression] inliner gone crazy
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-22 17:34:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37709
[Bug target/38151] structures with _Complex arguments are not passed correctly
--- Comment #23 from howarth at nitro dot med dot uc dot edu 2008-11-22 17:39 --- Patch in Comment 22 eliminates the va-arg test case failure at -m64 on i686-apple-darwin9. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38151
[Bug c++/35319] [4.3/4.4 regression] ICE throwing fixed-point types
--- Comment #5 from steven at gcc dot gnu dot org 2008-11-22 17:44 --- Is there a mangling convention now for fixed-point types, or not? If not, we should make this a sorry() and resolve this bug as SUSPENDED for now. If there is, well, you know, we should add it ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35319
[Bug tree-optimization/38207] Union in structs are not well optimized
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-11-22 17:47 --- The problem is a general defect in FRE that causes us to never CSE a load with the default definition of the virtual SSA name. after walking, that is. I have a patch that also makes PR38212 to be visible on the tree level :/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38207
[Bug fortran/38160] C Binding: Kind parameter checking too strict and too late
--- Comment #2 from burnus at gcc dot gnu dot org 2008-11-22 18:19 --- Subject: Bug 38160 Author: burnus Date: Sat Nov 22 18:18:05 2008 New Revision: 142124 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142124 Log: 2008-11-22 Tobias Burnus [EMAIL PROTECTED] PR fortran/38160 * trans-types.c (gfc_validate_c_kind): Remove function. * decl.c (gfc_match_kind_spec): Add C kind parameter check. (verify_bind_c_derived_type): Remove gfc_validate_c_kind call. (verify_c_interop_param): Update call. * gfortran.h (verify_bind_c_derived_type): Update prototype. (gfc_validate_c_kind): Remove. * symbol.c (verify_bind_c_derived_type): Update verify_c_interop * call. * resolve.c (gfc_iso_c_func_interface): Ditto. 2008-11-22 Tobias Burnus [EMAIL PROTECTED] PR fortran/38160 * gfortran.dg/bind_c_usage_18.f90: New test. * gfortran.dg/c_kind_tests_2.f03: Update dg-messages. * gfortran.dg/interop_params.f03: Ditto. Added: trunk/gcc/testsuite/gfortran.dg/bind_c_usage_18.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/c_kind_tests_2.f03 trunk/gcc/testsuite/gfortran.dg/interop_params.f03 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38160
[Bug target/38151] structures with _Complex arguments are not passed correctly
--- Comment #24 from rguenth at gcc dot gnu dot org 2008-11-22 18:20 --- The va-arg code should probably use ref-all pointers all over the place instead. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38151
[Bug c++/35335] [4.2/4.3/4.4 regression] Broken diagnostic: 'expr_stmt' not supported by dump_expr
--- Comment #3 from steven at gcc dot gnu dot org 2008-11-22 18:20 ---
With a trivial one-liner patch this could look a lot better:
$ ./cc1plus t.C
void foo()
t.C:6: error: no match for 'operator=' in 'a = ({...})'
t.C:1: note: candidates are: A A::operator=(const A)
Execution times (seconds)
name lookup : 0.01 (25%) usr 0.00 ( 0%) sys 0.01 (25%) wall
82 kB ( 5%) ggc
TOTAL : 0.03 0.00 0.03
1508 kB
Extra diagnostic checks enabled; compiler may run slowly.
Configure with --enable-checking=release to disable checks.
$
Of course, a message reproducing the source line with a carret and all that
would be even better -- hi Aldy! -- but for now this is probably the best we
can do.
Untested, I have no commitment to this patch ;-)
Index: ../../trunk/gcc/cp/error.c
===
--- ../../trunk/gcc/cp/error.c (revision 142123)
+++ ../../trunk/gcc/cp/error.c (working copy)
@@ -1976,6 +1976,7 @@
break;
case BIND_EXPR:
+case EXPR_STMT:
case STMT_EXPR:
case STATEMENT_LIST:
/* We don't yet have a way of dumping statements in a
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35335
[Bug testsuite/38221] FAIL: gcc.c-torture/compile/sync-3.c -O0 (test for warnings, line )
--- Comment #4 from ubizjak at gmail dot com 2008-11-22 18:27 --- Ah, this is gcc-4.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38221
[Bug fortran/38160] C Binding: Kind parameter checking too strict and too late
--- Comment #3 from burnus at gcc dot gnu dot org 2008-11-22 18:28 --- FIXED on the trunk (4.4.0). -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords||rejects-valid Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38160
[Bug target/36793] x86-64 does not get __sync_synchronize right
--- Comment #7 from ubizjak at gmail dot com 2008-11-22 18:29 --- Patch that implements memory_barrier for x86 at [1]. [1] http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01181.html -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||11/msg01181.html Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-22 18:29:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36793
[Bug c/25509] can't disable __attribute__((warn_unused_result))
--- Comment #22 from fche at redhat dot com 2008-11-22 18:35 --- (In reply to comment #21) Sent from my iPhone Good to know. GCC should not be trying to micromanage coding styles - either of the rest of gnu software or anywhere else, but at least until you clean up every bit of your own code, there should be a way of disabling the warning clutter. Why GCC is not micromanaging at all, it just allows the developer of the API to have the warning. So your complaints here are useless. What the poster seems to be requesting is another -Wno-unused-FOO flag to override this warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509
[Bug fortran/37779] Missing RECURSIVE not detected
--- Comment #2 from burnus at gcc dot gnu dot org 2008-11-22 19:03 --- Another code which is not rejected. If the parent procedure is called by a contained procedure there must be a recursion: subroutine test() call sub() contains subroutine sub() call test() end subroutine sub end subroutine test NAG f95 detects this: Error: hfjf.f90, line 7: Invalid recursive self-reference to TEST as does openf95: openf95-343 openf95: ERROR SUB, File = hfjf.f90, Line = 5, Column = 10 A RECURSIVE keyword must be declared for a subprogram so that the subprogram can be called recursively. ifort, g95 and gfortran accept this program. (Can be also moved into a different PR.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37779
[Bug tree-optimization/38230] New: SCCVN doesn't do expression lookups during stmt walks
Related to PR38207, SCCVN doesn't CSE the load of c-a in
/* { dg-do compile } */
/* { dg-options -O -fdump-tree-fre } */
struct a
{
union
{
int a;
int b;
};
union
{
int c;
int d;
};
int e;
};
int f(struct a *c)
{
int d;
c-e = 2;
d = c-a;
c-c = 1;
return c-a + d;
}
/* We should have CSEd the load from c-a. */
/* { dg-final { scan-tree-dump-times c_.*\\\.a 1 fre } } */
/* { dg-final { cleanup-tree-dump fre } } */
which is because it doesn't do expression hashtable lookups for intermediate
VUSEs it walks. Without proper caching this will probably be too expensive.
--
Summary: SCCVN doesn't do expression lookups during stmt walks
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38230
[Bug tree-optimization/38230] SCCVN doesn't do expression lookups during stmt walks
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-11-22 19:12 --- Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-22 19:12:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38230
[Bug regression/38223] segfault in glib testsuite with trunk
--- Comment #4 from dirtyepic at gentoo dot org 2008-11-22 19:13 --- oops. is the original valid? i'll try to reduce it to something a bit smaller. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38223
[Bug target/38151] structures with _Complex arguments are not passed correctly
--- Comment #25 from ubizjak at gmail dot com 2008-11-22 19:30 --- Deassigning me, this is tree stuff. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|ubizjak at gmail dot com|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38151
[Bug target/36793] x86-64 does not get __sync_synchronize right
--- Comment #8 from samuel dot thibault at ens-lyon dot org 2008-11-22 19:41 --- Ah, well, by nop, I was thinking about things like what Linux does: lock; addl $0,0(%%esp) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36793
[Bug target/38151] structures with _Complex arguments are not passed correctly
--- Comment #26 from rguenth at gcc dot gnu dot org 2008-11-22 20:41
---
Even with ref-all pointers we end up with
bb 5:
# addr.0{0}_1 = PHI va_arg_tmp.3(3), addr.0{0}_22(4)
# ap_38 = PHI ap_56(3), ap_57(4)
# va_arg_tmp.3_39 = PHI va_arg_tmp.3_55(3), va_arg_tmp.3_50(4)
addr.8_25 = (struct S2848 * {ref-all}) addr.0{0}_1;
# VUSE fails_48, ap_38, SMT.26_53
# arg_59 = VDEF arg_58(D)
arg = *addr.8_25;
where the last stmt misses a VUSE of va_arg_tmp.3. This looks like a bug
in alias computation.
I have a fix for that parts. The gimplify_va_arg still needs to use ref-all
pointers properly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38151
[Bug target/38151] structures with _Complex arguments are not passed correctly
--- Comment #27 from rguenth at gcc dot gnu dot org 2008-11-22 20:41 --- I have patches. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-11-22 17:07:30 |2008-11-22 20:41:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38151
[Bug libfortran/38225] [4.4 regression] RESHAPE bounds with multi-dimensional SOURCE
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38225
[Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
--- Comment #38 from jakub at gcc dot gnu dot org 2008-11-22 20:58 --- Closing, if somebody comes up with a testcase, please reopen. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
[Bug fortran/37779] Missing RECURSIVE not detected
--- Comment #3 from burnus at gcc dot gnu dot org 2008-11-22 21:40 --- Before closing, one should check whether a recursive-related bug remains for http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/e0d04d755453a2a5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37779
[Bug fortran/38205] Tranformational function SUM rejected in initialization expressions
--- Comment #1 from burnus at gcc dot gnu dot org 2008-11-22 21:41 --- See also James' new c.l.f post: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/e0d04d755453a2a5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38205
[Bug fortran/38152] ICE for procedure pointer assignment
--- Comment #6 from burnus at gcc dot gnu dot org 2008-11-22 21:42 --- See also test cases at: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/e0d04d755453a2a5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38152
[Bug libfortran/38225] [4.4 regression] RESHAPE bounds with multi-dimensional SOURCE
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-11-22 21:42 --- Subject: Bug 38225 Author: tkoenig Date: Sat Nov 22 21:41:27 2008 New Revision: 142125 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142125 Log: 2008-11-22 Thomas Koenig [EMAIL PROTECTED] PR libfortran/38225 * intrinsics/reshape_generic.c (reshape_internal): Use all dimensions of source for bounds checking. * m4/reshape.m4: Likewise. * generated/reshape_c10.c Regenerated. * generated/reshape_c16.c Regenerated. * generated/reshape_c4.c Regenerated. * generated/reshape_c8.c Regenerated. * generated/reshape_i16.c Regenerated. * generated/reshape_i4.c Regenerated. * generated/reshape_i8.c Regenerated. * generated/reshape_r10.c Regenerated. * generated/reshape_r16.c Regenerated. * generated/reshape_r4.c Regenerated. * generated/reshape_r8.c Regenerated. 2008-11-22 Thomas Koenig [EMAIL PROTECTED] PR libfortran/38225 * gfortran.dg/reshape_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/reshape_3.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/generated/reshape_c10.c trunk/libgfortran/generated/reshape_c16.c trunk/libgfortran/generated/reshape_c4.c trunk/libgfortran/generated/reshape_c8.c trunk/libgfortran/generated/reshape_i16.c trunk/libgfortran/generated/reshape_i4.c trunk/libgfortran/generated/reshape_i8.c trunk/libgfortran/generated/reshape_r10.c trunk/libgfortran/generated/reshape_r16.c trunk/libgfortran/generated/reshape_r4.c trunk/libgfortran/generated/reshape_r8.c trunk/libgfortran/intrinsics/reshape_generic.c trunk/libgfortran/m4/reshape.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38225
[Bug libfortran/38225] [4.4 regression] RESHAPE bounds with multi-dimensional SOURCE
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-11-22 21:44 --- Fixed. Closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38225
[Bug fortran/27766] [meta] -fbounds-check related bugs
--- Comment #5 from tkoenig at gcc dot gnu dot org 2008-11-22 23:52 --- Current failures with bounds checking: FAIL: gfortran.dg/array_memset_2.f90 -O0 scan-tree-dump-times original memset 2 FAIL: gfortran.dg/array_memset_2.f90 -O1 scan-tree-dump-times original memset 2 FAIL: gfortran.dg/array_memset_2.f90 -O2 scan-tree-dump-times original memset 2 FAIL: gfortran.dg/array_memset_2.f90 -O3 -fomit-frame-pointer scan-tree-dump-times original memset 2 FAIL: gfortran.dg/array_memset_2.f90 -O3 -fomit-frame-pointer -funroll-loops scan-tree-dump-times original memset 2 FAIL: gfortran.dg/array_memset_2.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions scan-tree-dump-times original memset 2 FAIL: gfortran.dg/array_memset_2.f90 -O3 -g scan-tree-dump-times original memset 2 FAIL: gfortran.dg/array_memset_2.f90 -Os scan-tree-dump-times original memset 2 FAIL: gfortran.dg/bound_2.f90 -O0 execution test FAIL: gfortran.dg/bound_2.f90 -O1 execution test FAIL: gfortran.dg/bound_2.f90 -O2 execution test FAIL: gfortran.dg/bound_2.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/bound_2.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/bound_2.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/bound_2.f90 -O3 -g execution test FAIL: gfortran.dg/bound_2.f90 -Os execution test FAIL: gfortran.dg/forall_13.f90 -O0 execution test FAIL: gfortran.dg/forall_13.f90 -O1 execution test FAIL: gfortran.dg/forall_13.f90 -O2 execution test FAIL: gfortran.dg/forall_13.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/forall_13.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/forall_13.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/forall_13.f90 -O3 -g execution test FAIL: gfortran.dg/forall_13.f90 -Os execution test FAIL: gfortran.dg/ldist-1.f90 -O scan-tree-dump-times ldist distributed: split to 4 loops 1 FAIL: gfortran.dg/ltrans-7.f90 -O scan-tree-dump-times ltrans transformed loop 1 FAIL: gfortran.dg/pr37243.f -O0 execution test FAIL: gfortran.dg/pr37243.f -O1 execution test FAIL: gfortran.dg/pr37243.f -O2 execution test FAIL: gfortran.dg/pr37243.f -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/pr37243.f -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/pr37243.f -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/pr37243.f -O3 -g execution test FAIL: gfortran.dg/pr37243.f -Os execution test FAIL: gfortran.dg/reassoc_4.f -O scan-tree-dump-times reassoc1 [0-9] \* 22 FAIL: gfortran.dg/g77/dnrm2.f -O0 execution test FAIL: gfortran.dg/g77/dnrm2.f -O1 execution test FAIL: gfortran.dg/g77/dnrm2.f -O2 execution test FAIL: gfortran.dg/g77/dnrm2.f -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/g77/dnrm2.f -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/g77/dnrm2.f -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/g77/dnrm2.f -O3 -g execution test FAIL: gfortran.dg/g77/dnrm2.f -Os execution test Running /home/ig25/gcc/trunk/gcc/testsuite/gfortran.dg/gomp/gomp.exp ... Running /home/ig25/gcc/trunk/gcc/testsuite/gfortran.dg/graphite/graphite.exp ... Running /home/ig25/gcc/trunk/gcc/testsuite/gfortran.dg/vect/vect.exp ... FAIL: gfortran.dg/vect/vect-3.f90 -O scan-tree-dump-times vect Alignment of access forced using peeling 1 FAIL: gfortran.dg/vect/vect-3.f90 -O scan-tree-dump-times vect Vectorizing an unaligned access 1 FAIL: gfortran.dg/vect/vect-5.f90 -O scan-tree-dump-times vect vectorized 1 loops 1 FAIL: gfortran.dg/vect/vect-5.f90 -O scan-tree-dump-times vect Alignment of access forced using peeling 1 FAIL: gfortran.dg/vect/vect-5.f90 -O scan-tree-dump-times vect Vectorizing an unaligned access 1 FAIL: gfortran.dg/vect/pr19049.f90 -O scan-tree-dump-times vect complicated access pattern 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27766
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #73 from jason at redhat dot com 2008-11-23 00:02 ---
Subject: Re: exception_defines.h #defines try/catch
pinskia at gcc dot gnu dot org wrote:
I think this patch will not handle:
int main(void)
{
try {
}catch (int a)
{
a = 1;
}
}
Ah yes, I probably still need to push the declaration of a.
I am working on a patch which adds -fignore-exceptions which has to be used
with -fno-exceptions which handles this correctly.
This sounds like the wrong approach to me. libstdc++ needs to work with
or without -fno-exceptions, it shouldn't require another flag. And I
don't see the point in allowing 'throw expr;' under -fno-exceptions; I
don't think the compiler can come up with another error reporting
mechanism by itself.
Jason
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug fortran/27766] [meta] -fbounds-check related bugs
--- Comment #6 from dominiq at lps dot ens dot fr 2008-11-23 00:32 ---
(1) It seems that the failure of gfortran.dg/array_memset_2.f90 comes from a
too broad regexp for scan-tree-dump-times: grep memset
array_memset_2.f90.003t.original gives
_gfortran_runtime_error_at (At line 8 of file
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/array_memset_2.f90[1]{lb: 1 sz:
1}, Array reference out of bounds, upper bound of dimension 2 of array \'a\'
exceeded (%ld %ld)[1]{lb: 1 sz: 1}, 1, (unnamed-signed:32) ubound.2);
_gfortran_runtime_error_at (At line 8 of file
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/array_memset_2.f90[1]{lb: 1 sz:
1}, Array reference out of bounds, upper bound of dimension 2 of array \'a\'
exceeded (%ld %ld)[1]{lb: 1 sz: 1}, (unnamed-signed:32) NON_LVALUE_EXPR
D.1514, (unnamed-signed:32) ubound.2);
_gfortran_runtime_error_at (At line 8 of file
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/array_memset_2.f90[1]{lb: 1 sz:
1}, Array reference out of bounds for array \'a\', upper bound of dimension 1
exceeded (%ld %ld)[1]{lb: 1 sz: 1}, 1, (unnamed-signed:32) ubound.0);
(void) __builtin_memset ((void *) b, 0, 8);
(void) __builtin_memset ((void *) c, 0, 8);
Either the regexp or the name of the test should be changed.
(2) The failure of gfortran.dg/bound_2.f90 comes from Incorrect size in
SOURCE argument to RESHAPE intrinsic: is 9, should be 4. This is wrong, the
standard says:
If PAD is absent or of size zero, the size of SOURCE shall be greater than or
equal to PRODUCT (SHAPE).
(3) I think the failure of gfortran.dg/forall_13.f90: Array reference out of
bounds for array 'p', upper bound of dimension 1 exceeded (4 3), is also
wrong.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27766
[Bug c/38231] New: Improperly parsing -g -o causes bad info to be passed to ld on FreeBSD and ld segfaults
I was in a hurry and passed the wrong arguments to gcc and this is what happened (proper execution would have been: `gcc -g -o ft format_test.c'): [EMAIL PROTECTED] ~]$ gcc -o -g ft format_test.c ft(.data+0x8): multiple definition of `__dso_handle' /usr/lib/crtbegin.o(.data+0x0): first defined here ft(.init+0x0): In function `_init': /usr/src/lib/csu/amd64/crti.S:31: multiple definition of `_init' /usr/lib/crti.o(.init+0x0):/usr/src/lib/csu/amd64/crti.S:31: first defined here ft(.data+0x0): multiple definition of `__progname' /usr/lib/crt1.o(.data+0x0):/usr/src/lib/csu/amd64/crt1.c:61: first defined here ft(.text+0x0): In function `_start': /usr/src/lib/csu/amd64/crt1.c:61: multiple definition of `_start' /usr/lib/crt1.o(.text+0x0):/usr/src/lib/csu/amd64/crt1.c:61: first defined here ft(.fini+0x0): In function `_fini': /usr/src/lib/csu/amd64/crti.S:38: multiple definition of `_fini' /usr/lib/crti.o(.fini+0x0): first defined here /var/tmp//ccHhrlAz.o(.text+0x0): In function `main': : multiple definition of `main' ft(.text+0x100): first defined here /usr/lib/crt1.o(.dynamic+0x0): In function `_start': /usr/src/lib/csu/amd64/crt1.c:61: multiple definition of `_DYNAMIC' ft(.dynamic+0x0): first defined here /usr/lib/crt1.o(.got.plt+0x0): In function `_start': /usr/src/lib/csu/amd64/crt1.c:61: multiple definition of `_GLOBAL_OFFSET_TABLE_' ft(.got+0x0): first defined here gcc: Internal error: Segmentation fault: 11 (program ld) Please submit a full bug report. See URL:http://gcc.gnu.org/bugs.html for instructions. [EMAIL PROTECTED] ~]$ ld --version GNU ld version 2.15 [FreeBSD] 2004-05-23 Copyright 2002 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This doesn't occur with gcc v4.3.0 and the version of ld released with Fedora 9. -- Summary: Improperly parsing -g -o causes bad info to be passed to ld on FreeBSD and ld segfaults Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: yanegomi at gmail dot com GCC build triplet: amd64-undermydesk-freebsd GCC host triplet: amd64-undermydesk-freebsd GCC target triplet: amd64-undermydesk-freebsd http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38231
[Bug c/38231] Improperly parsing -g -o causes bad info to be passed to ld on FreeBSD and ld segfaults
--- Comment #1 from yanegomi at gmail dot com 2008-11-23 01:26 --- Also, ft was a precompiled C app without debug symbols. I noticed that made a difference in the reproducing the error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38231
[Bug c/38231] Improperly parsing -g -o causes bad info to be passed to ld on FreeBSD and ld segfaults
--- Comment #2 from yanegomi at gmail dot com 2008-11-23 01:36 ---
Ok, here's a shorter means of reproducing the issue:
echo 'int main () { return 0; }' test.c
gcc -o test test.c
gcc -o -g test test.c
This issue doesn't occur as horribly with the gcc and ld versions that are
available on FreeBSD, but it still comes up with a confusing error on Fedora 9:
[EMAIL PROTECTED] regression_test]# echo 'int main () { return 0; }' test.c
[EMAIL PROTECTED] regression_test]# gcc -o test test.c
[EMAIL PROTECTED] regression_test]# gcc -o -g test test.c
test: In function `_start':
(.text+0x0): multiple definition of `_start'
/usr/lib/gcc/i386-redhat-linux/4.3.0/../../../crt1.o:(.text+0x0): first defined
here
test:(.rodata+0x0): multiple definition of `_fp_hw'
/usr/lib/gcc/i386-redhat-linux/4.3.0/../../../crt1.o:(.rodata+0x0): first
defined here
test: In function `_fini':
(.fini+0x0): multiple definition of `_fini'
/usr/lib/gcc/i386-redhat-linux/4.3.0/../../../crti.o:(.fini+0x0): first defined
here
test:(.rodata+0x4): multiple definition of `_IO_stdin_used'
/usr/lib/gcc/i386-redhat-linux/4.3.0/../../../crt1.o:(.rodata.cst4+0x0): first
defined here
test: In function `__data_start':
(.data+0x0): multiple definition of `__data_start'
/usr/lib/gcc/i386-redhat-linux/4.3.0/../../../crt1.o:(.data+0x0): first defined
here
test:(.rodata+0x8): multiple definition of `__dso_handle'
/usr/lib/gcc/i386-redhat-linux/4.3.0/crtbegin.o:(.rodata+0x0): first defined
here
test: In function `_init':
(.init+0x0): multiple definition of `_init'
/usr/lib/gcc/i386-redhat-linux/4.3.0/../../../crti.o:(.init+0x0): first defined
here
/tmp/cc4jnyB9.o: In function `main':
test.c:(.text+0x0): multiple definition of `main'
test:(.text+0xb4): first defined here
/usr/lib/gcc/i386-redhat-linux/4.3.0/crtend.o:(.dtors+0x0): multiple definition
of `__DTOR_END__'
test:(.dtors+0x4): first defined here
/usr/bin/ld: warning: Cannot create .eh_frame_hdr section, --eh-frame-hdr
ignored.
/usr/bin/ld: error in test(.eh_frame); no .eh_frame_hdr table will be created.
collect2: ld returned 1 exit status
So it appears that the root cause is instead with ld, not gcc. Sorry for the
noise.
--
yanegomi at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38231
[Bug target/34587] gcc.dg/initpri1.c fails on *-apple-darwin
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2008-11-23 04:43 --- This backtraces on i686 darwin as... jack-howarths-macbook-pro-17:temp6 howarth$ gcc-4 -g -ansi -pedantic-errors -lm -m32 initpri1.c jack-howarths-macbook-pro-17:temp6 howarth$ gdb ./a.out GNU gdb 6.3.50-20050815 (Apple version gdb-1309) (Fri Oct 10 03:38:53 UTC 2008) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as x86_64-apple-darwin...Reading symbols for shared libraries ... done (gdb) r Starting program: /Users/howarth/temp6/a.out Reading symbols for shared libraries ++. done Program received signal SIGABRT, Aborted. 0x981d8ffe in __kill () (gdb) bt #0 0x981d8ffe in __kill () #1 0x981d8ff1 in kill$UNIX2003 () #2 0x9824d39f in raise () #3 0x9825f190 in abort () #4 0x1dc1 in c2 () at initpri1.c:19 #5 0x8fe146d8 in __dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE () #6 0x8fe0ec6d in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj () #7 0x8fe0ed59 in __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextE () #8 0x8fe052e2 in __dyld__ZN4dyld24initializeMainExecutableEv () #9 0x8fe083e9 in __dyld__ZN4dyld5_mainEPK11mach_headermiPPKcS5_S5_ () #10 0x8fe01960 in __dyld__ZN13dyldbootstrap5startEPK11mach_headeriPPKcl () #11 0x8fe01057 in __dyld__dyld_start () (gdb) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34587
[Bug target/34587] gcc.dg/initpri1.c fails on *-apple-darwin
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2008-11-23 04:47 --- I am mainly trying to determine if this is a flaw in darwin linker or assembler rather than a bug in gcc. If the former, we can at least file a radar bug report with Apple. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34587
[Bug c++/38076] FAIL: g++.dg/other/anon5.C
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2008-11-23 05:21 --- Patch submitted at http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01191.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38076
[Bug c++/38232] New: value-initialization of reference warning too strict
gcc version 4.4.0 20081123 (experimental) (GCC) rejects the code:
class base {
public:
base();
virtual ~base();
private:
int int_ref; // initialized by base ctor, not visible here
};
class derived : public base {
};
base *make_derived() {
return new derived();
}
with the error:
test.cc: In function 'base* make_derived()':
test.cc:14: error: value-initialization of reference
4.3.2 accepts this code, the Comeau test drive accepts it, and AFAICT there's
nothing wrong with it.
Adding a user-supplied default ctor to 'derived' fixes it.
This was build from a GCC trunk checkout as of this evening:
Using built-in specs.
Target: i686-linux
Configured with: ../trunk/configure --enable-languages=c,c++ --build=i686-linux
--host=i686-linux --target=i686-linux
--prefix=/g/users/cgd/proj/gcc-trunk/bld/../inst
Thread model: posix
gcc version 4.4.0 20081123 (experimental) (GCC)
--
Summary: value-initialization of reference warning too strict
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cgd at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: i686-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38232
