[Bug middle-end/36593] [4.4 Regression]: gfortran.dg/default_format_1.f90, 22_locale/num_get/get/char/2.cc
--- Comment #1 from hp at gcc dot gnu dot org 2008-06-22 08:39 --- These tests have also regressed for mmix-knuth-mmixware 132182 - 136827, so if it's a target-specific thing that went wrong (assuming it's the same reason; there are two more regressions in that range but that's it FWIW), it has to be at a high level, because those targets are about as different as they come. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36593
[Bug c/36594] New: [4.4 Regression] multiple regressions on powerpc at rev.136976
Multiple regressions have appeared at revision 136976 (last known working 136953), see: http://gcc.gnu.org/ml/gcc-testresults/2008-06/msg01644.html http://gcc.gnu.org/ml/gcc-testresults/2008-06/msg01650.html A typical failure is: [karma] f90/bug% /opt/gcc/gcc4.4w/bin/gcc /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/execute/nestfunc-5.c /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/execute/nestfunc-5.c: In function 'do_goto': /opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/execute/nestfunc-5.c:11: internal compiler error: Bus error -- Summary: [4.4 Regression] multiple regressions on powerpc at rev.136976 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC target triplet: powerpc-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36594
[Bug ada/36575] [4.3/4.4 Regression][Ada] ACATS c460011 runtime fails at -O3
--- Comment #3 from jsm28 at gcc dot gnu dot org 2008-06-22 11:03 --- Setting to P4 as an Ada bug, please restore to P3 if a C or C++ testcase is found. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36575
[Bug target/36584] [4.3/4.4 Regression] Stack is not aligned correctly in recursive function
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36584
[Bug bootstrap/36595] New: [4.4 Regression] Multiple warnings about C++ for C codes
From revision 136960 (not in 136942) I see multiple warnings during bootstrap: ... ../../gcc-4.4-work/gcc/objc/objc-act.c:6693: warning: request for implicit conversion from 'void *' to 'const char *' not permitted in C++ ../../gcc-4.4-work/gcc/collect2.c:849: warning: request for implicit conversion from 'void *' to 'char **' not permitted in C++ ../../gcc-4.4-work/gcc/collect2.c:850: warning: request for implicit conversion from 'void *' to 'char **' not permitted in C++ ../../gcc-4.4-work/gcc/collect2.c:851: warning: request for implicit conversion from 'void *' to 'char **' not permitted in C++ ../../gcc-4.4-work/gcc/collect2.c:878: warning: request for implicit conversion from 'void *' to 'char *' not permitted in C++ ../../gcc-4.4-work/gcc/collect2.c:896: warning: request for implicit conversion from 'void *' to 'char **' not permitted in C++ ../../gcc-4.4-work/gcc/collect2.c:1679: warning: request for implicit conversion from 'void *' to 'struct id *' not permitted in C++ ../../gcc-4.4-work/gcc/tlink.c:130: warning: request for implicit conversion from 'void *' to 'struct symbol_hash_entry *' not permitted in C++ ../../gcc-4.4-work/gcc/tlink.c:150: warning: request for implicit conversion from 'void *' to 'struct file_hash_entry *' not permitted in C++ ../../gcc-4.4-work/gcc/tlink.c:172: warning: request for implicit conversion from 'void *' to 'struct demangled_hash_entry *' not permitted in C++ ../../gcc-4.4-work/gcc/tlink.c:196: warning: request for implicit conversion from 'void *' to 'struct symbol_stack_entry *' not permitted in C++ ../../gcc-4.4-work/gcc/tlink.c:224: warning: request for implicit conversion from 'void *' to 'struct file_stack_entry *' not permitted in C++ ../../gcc-4.4-work/gcc/tlink.c:301: warning: request for implicit conversion from 'void *' to 'char *' not permitted in C++ ../../gcc-4.4-work/gcc/gengtype-lex.l:119: warning: request for implicit conversion from 'void *' to 'const char *' not permitted in C++ ../../gcc-4.4-work/gcc/gengtype-lex.l:130: warning: request for implicit conversion from 'void *' to 'const char *' not permitted in C++ ../../gcc-4.4-work/gcc/gengtype-lex.l:137: warning: request for implicit conversion from 'void *' to 'const char *' not permitted in C++ ../../gcc-4.4-work/gcc/gengtype-lex.l:142: warning: request for implicit conversion from 'void *' to 'const char *' not permitted in C++ ../../gcc-4.4-work/gcc/gengtype-lex.l:147: warning: request for implicit conversion from 'void *' to 'const char *' not permitted in C++ ../../gcc-4.4-work/gcc/gengtype-lex.l:151: warning: request for implicit conversion from 'void *' to 'const char *' not permitted in C++ ../../gcc-4.4-work/gcc/genautomata.c:1245: warning: request for implicit conversion from 'void *' to 'decl_t' not permitted in C++ ../../gcc-4.4-work/gcc/genautomata.c:1275: warning: request for implicit conversion from 'void *' to 'decl_t' not permitted in C++ ../../gcc-4.4-work/gcc/genautomata.c:1309: warning: request for implicit conversion from 'void *' to 'decl_t' not permitted in C++ ../../gcc-4.4-work/gcc/genautomata.c:1344: warning: request for implicit conversion from 'void *' to 'decl_t' not permitted in C++ ../../gcc-4.4-work/gcc/genautomata.c:1397: warning: request for implicit conversion from 'void *' to 'char ***' not permitted in C++ ... -- Summary: [4.4 Regression] Multiple warnings about C++ for C codes Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36595
[Bug c/36594] [4.4 Regression] multiple regressions on powerpc at rev.136976
--- Comment #1 from dominiq at lps dot ens dot fr 2008-06-22 11:18 --- If I revert revision 136959, the test in comment#0 passes. -- dominiq at lps dot ens dot fr changed: What|Removed |Added CC||ubizjak at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36594
[Bug c/36594] [4.4 Regression] multiple regressions on powerpc at rev.136976
--- Comment #2 from ubizjak at gmail dot com 2008-06-22 12:00 --- Author: hubicka Date: Thu Jun 19 18:00:12 2008 New Revision: 136959 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136959 Log: * builtins.c (expand_builtin_nonlocal_goto): Stabilize r_sp before clobbering framepointer. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c -- ubizjak at gmail dot com changed: What|Removed |Added CC|ubizjak at gmail dot com|hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36594
[Bug c/36596] New: occasional segfault in bitmap_elt_clear_from
only since some days I get a segfault with this backtrace: gdb cc1 r -fpreprocessed agfa_cl20.i -dumpbase agfa_cl20.i -mtune=generic -auxbase agfa_cl20 -g -O2 -Wall -Wmissing-declarations -version -fstack-protector -fPIC -o /tmp/ccqJyq0F.sQuit Program received signal SIGSEGV, Segmentation fault. bitmap_elt_clear_from (head=0x10eb670, elt=0x111d360) at /home/marcus/projects/gcc.trunk/gcc/bitmap.c:260 260 prev = elt-prev; (gdb) bt #0 bitmap_elt_clear_from (head=0x10eb670, elt=0x111d360) at /home/marcus/projects/gcc.trunk/gcc/bitmap.c:260 #1 0x0049f766 in bitmap_obstack_free (map=0x10eb670) at /home/marcus/projects/gcc.trunk/gcc/bitmap.c:296 #2 0x007fa62c in bitmap_set_free (set=0x10e7bd8) at /home/marcus/projects/gcc.trunk/gcc/tree-ssa-pre.c:621 #3 0x007fa99d in fini_pre () at /home/marcus/projects/gcc.trunk/gcc/tree-ssa-pre.c:2029 #4 0x00806e68 in execute_pre (do_fre=0 '\0') at /home/marcus/projects/gcc.trunk/gcc/tree-ssa-pre.c:4062 #5 0x0080733b in do_pre () at /home/marcus/projects/gcc.trunk/gcc/tree-ssa-pre.c:4072 #6 0x0065de4a in execute_one_pass (pass=0xfcdd60) at /home/marcus/projects/gcc.trunk/gcc/passes.c:1292 #7 0x0065e085 in execute_pass_list (pass=0xfcdd60) at /home/marcus/projects/gcc.trunk/gcc/passes.c:1342 #8 0x0065e09d in execute_pass_list (pass=0xfcc920) at /home/marcus/projects/gcc.trunk/gcc/passes.c:1343 #9 0x0074cd16 in tree_rest_of_compilation (fndecl=0x2b60b418d000) at /home/marcus/projects/gcc.trunk/gcc/tree-optimize.c:425 #10 0x008fbe12 in cgraph_expand_function (node=0x2b60b403df00) at /home/marcus/projects/gcc.trunk/gcc/cgraphunit.c:1158 #11 0x008fe884 in cgraph_optimize () at /home/marcus/projects/gcc.trunk/gcc/cgraphunit.c:1221 #12 0x00416b82 in c_write_global_declarations () at /home/marcus/projects/gcc.trunk/gcc/c-decl.c:8066 #13 0x006e3117 in toplev_main (argc=value optimized out, argv=value optimized out) at /home/marcus/projects/gcc.trunk/gcc/toplev.c:976 #14 0x2b60b3a3cb54 in __libc_start_main () from /lib64/libc.so.6 #15 0x004040f9 in _start () -- Summary: occasional segfault in bitmap_elt_clear_from Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: marcus at jet dot franken dot de 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=36596
[Bug c/36596] occasional segfault in bitmap_elt_clear_from
--- Comment #1 from marcus at jet dot franken dot de 2008-06-22 12:11 --- Created an attachment (id=15800) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15800action=view) agfa_cl20.i /home/marcus/projects/gcc.trunk/BIN/bin/gcc -Wall -g -fstack-protector -Wmissing-declarations -O2 -c agfa_cl20.i -fPIC -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36596
[Bug middle-end/36597] New: OpenMP 3: _OPENMP should be 200805 instead of 200505
http://www.openmp.org/mp-documents/spec30.pdf Version 3.0 May 2008 2.2 Conditional Compilation In implementations that support a preprocessor, the _OPENMP macro name is defined to have the decimal value mm where and mm are the year and month designations of the version of the OpenMP API that the implementation supports. Currently, GCC 4.4 returns 200505 (as do GCC 4.2 and 4.3): #define _OPENMP 200505 Expected: #define _OPENMP 200805 (-8- not -5-) -- Summary: OpenMP 3: _OPENMP should be 200805 instead of 200505 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: openmp Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36597
[Bug middle-end/36597] OpenMP 3: _OPENMP should be 200805 instead of 200505
--- Comment #1 from jakub at gcc dot gnu dot org 2008-06-22 12:27 --- Not sure where you are looking? http://gcc.gnu.org/viewcvs/trunk/gcc/c-cppbuiltin.c?r1=136425r2=136433 is the latest revision of c-cppbuiltin.c and that has: if (flag_openmp) cpp_define (pfile, _OPENMP=200805); Similarly, omp_lib.f90.in and omp_lib.h.in have been adjusted. Are you sure you aren't using your system preprocessor rather than the 4.4 one? -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36597
[Bug fortran/36590] internal error: Can't convert LOGICAL(1) to LOGICAL(1)
--- Comment #5 from burnus at gcc dot gnu dot org 2008-06-22 12:28 --- The error only occurs for logical(1), kind=2,4,8,16 all work. The program also works if one removes the .not. interface Near0 function Near0_dp (TestNumber) result (NumberNear0) real :: TestNumber(2) logical(1) :: NumberNear0(2) end function Near0_dp end interface real :: PolyMTFWeight(2) i = count (.not. Near0 (PolyMTFWeight(1:2))) end -- burnus at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Summary|internal error |internal error: Can't ||convert LOGICAL(1) to ||LOGICAL(1) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36590
[Bug middle-end/36597] OpenMP 3: _OPENMP should be 200805 instead of 200505
--- Comment #2 from burnus at gcc dot gnu dot org 2008-06-22 12:31 --- (In reply to comment #1) Not sure where you are looking? I'm a Fortran guy thus I looked here: fortran/cpp.c:cpp_define (pfile, _OPENMP=200505); -- burnus at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|-00-00 00:00:00 |2008-06-22 12:31:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36597
[Bug c/36598] New: Failed optimisation of return of struct argment in memcpy-1.c
Testcase gcc.dg/memcpy-1.c fails on AVR target.
Failure occurs because the return value is not simplified to avoid memcpy. This
test works on i686 and I can't see why same optimization should not apply to
AVR
Test is:
/* { dg-do compile } */
/* { dg-options -O2 -fdump-tree-optimized } */
/* { dg-final { scan-tree-dump-times nasty_local 0 optimized } } */
/* { dg-final { cleanup-tree-dump optimized } } */
struct a {int a,b,c;} a;
int test(struct a a)
{
struct a nasty_local;
__builtin_memcpy (nasty_local,a, sizeof(a));
return nasty_local.a;
}
On i686 we get:
;; Function test (test)
Analyzing Edge Insertions.
test (struct a a)
{
bb 2:
return a.a;
}
BUT on AVR we get:
;; Function test (test)
Analyzing Edge Insertions.
test (struct a a)
{
struct a nasty_local;
bb 2:
nasty_local = a;
return nasty_local.a;
}
I have confirmed the final AVR code is suboptimal.
--
Summary: Failed optimisation of return of struct argment in
memcpy-1.c
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hutchinsonandy at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: avr-unknown-none
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36598
[Bug c/36598] Failed optimisation of return of struct argment in memcpy-1.c
--- Comment #1 from joseph at codesourcery dot com 2008-06-22 13:32 --- Subject: Re: New: Failed optimisation of return of struct argment in memcpy-1.c On Sun, 22 Jun 2008, hutchinsonandy at gcc dot gnu dot org wrote: Testcase gcc.dg/memcpy-1.c fails on AVR target. Have you looked at bug 31677 which suggests using the option --param sra-max-structure-size=32? If that works for AVR, you could submit a patch to add it to the testcase for all targets. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36598
[Bug c/36598] Failed optimisation of return of struct argment in memcpy-1.c
--- Comment #2 from hutchinsonandy at gcc dot gnu dot org 2008-06-22 14:33 --- Thanks for information --param sra-max-structure-size=32 does indeed remove test failure and produces optimal code. But changing the testcase does not remove the optimization problem - unless sra-max-structure-size was always used. So there is problem somewhere else to fix. See also: http://gcc.gnu.org/ml/gcc-patches/2007-12/msg01144.html Andy -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36598
[Bug middle-end/36594] [4.4 Regression] multiple regressions on powerpc at rev.136976
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end Keywords||ice-on-valid-code Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36594
[Bug c/36596] occasional segfault in bitmap_elt_clear_from
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-06-22 14:46 --- I belive this was fixed by 2008-06-21 Bernhard Fischer [EMAIL PROTECTED] * tree-ssa-pre.c (fini_antic): Bitmap_sets have to be freed before the grand_bitmap_obstack. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36596
[Bug middle-end/34905] valgrind error indication from testsuite typeck.c:comptypes
--- Comment #3 from lauras at gcc dot gnu dot org 2008-06-22 14:49 --- Closing since valgrind errors are unreproducible now -- lauras at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34905
[Bug ada/36591] error: a-reatim.adb must be compiled
--- Comment #3 from danglin at gcc dot gnu dot org 2008-06-22 14:49 --- This was fixed by a library rebuild. There's probably a make file dependency that is not quite right but I am closing as invalid. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36591
[Bug c/36598] Failed optimisation of return of struct argment in memcpy-1.c
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-06-22 14:50 --- This is really not a task for SRA but for struct copy propagation (which we do not do). See PR14295. As this testcase was for SRA you can either XFAIL it for avr or see if the cost metrics need adjustment. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||14295 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36598
[Bug tree-optimization/14295] [tree-ssa] copy propagation for aggregates
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-06-22 15:05 ---
If we would disallow struct copies in the gimple IL and instead require a
register temporary that we would re-write into SSA form like
struct s temp_struct3;
struct s temp_struct2;
struct s temp_struct1;
struct s temp_struct3.3;
struct s temp_struct2.2;
struct s temp_struct1.1;
struct s r.0;
bb 2:
r.0_1 = r;
temp_struct1 ={v} r.0_1;
temp_struct1.1_2 = temp_struct1;
temp_struct2 ={v} temp_struct1.1_2;
temp_struct2.2_3 = temp_struct2;
temp_struct3 ={v} temp_struct2.2_3;
temp_struct3.3_4 = temp_struct3;
retval ={v} temp_struct3.3_4;
return retval;
then value-numbering can recognize the redundant copies and we end up
with
struct s temp_struct3.3;
struct s r.0;
bb 2:
r.0_1 = r;
retval = r.0_1;
return retval;
(and of course with the possibility of out-of-SSA having to deal with
overlapping life-ranges of struct-typed SSA names)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14295
[Bug tree-optimization/14295] [tree-ssa] copy propagation for aggregates
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-06-22 15:07 --- Created an attachment (id=15801) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15801action=view) aggregate temporary registers Like this simple, untested patch. Breaks tree-sra. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14295
[Bug c/34867] valgrind error indication in testsuite from c-lex.c:996:c_lex_with_flags for gcc.dg/cpp/charconst.c
--- Comment #1 from lauras at gcc dot gnu dot org 2008-06-22 15:23 --- Confirmed with r137000. To set unsignedp value, lex_charconst calls cpp_interpret_charconst. Here it quits early with an error, leaving unsignedp uninitialized. I will post a patch to fix. -- lauras at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |lauras at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-22 15:23:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34867
[Bug middle-end/34906] valgrind error indication from testsuite gimplify.c: gimplify_asm_expr
--- Comment #3 from lauras at gcc dot gnu dot org 2008-06-22 15:28 --- Subject: Bug 34906 Author: lauras Date: Sun Jun 22 15:28:04 2008 New Revision: 137020 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137020 Log: 2008-06-22 Laurynas Biveinis [EMAIL PROTECTED] PR middle-end/34906 * gimplify.c (gimplify_asm_expr): Check the return code of parse_output_constraint call, set function return and is_inout value if it failed. Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34906
[Bug middle-end/34906] valgrind error indication from testsuite gimplify.c: gimplify_asm_expr
--- Comment #4 from lauras at gcc dot gnu dot org 2008-06-22 15:30 --- Fixed on trunk. -- lauras at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34906
[Bug middle-end/36593] [4.4 Regression]: gfortran.dg/default_format_1.f90, 22_locale/num_get/get/char/2.cc
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-06-22 15:43 --- I certainly belive this was uncovered by my patch for PR36345. But I also believe newlib is at fault here ;) The fix simply makes strict-aliasing rules followed even more (thus, if you build newlib with -fno-strict-aliasing the failure should go away). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36593
[Bug middle-end/34906] valgrind error indication from testsuite gimplify.c: gimplify_asm_expr
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34906
[Bug c/36598] Failed optimisation of return of struct argment in memcpy-1.c
--- Comment #4 from hutchinsonandy at gcc dot gnu dot org 2008-06-22 16:11 --- Quite possibly due to cost metrics. They are far from ideal. Will mark test XFAIL until we can investigate and fix. -- hutchinsonandy at gcc dot gnu dot org changed: What|Removed |Added CC||eric dot weddington at atmel ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36598
[Bug fortran/36590] internal error: Can't convert LOGICAL(1) to LOGICAL(1)
--- Comment #6 from burnus at gcc dot gnu dot org 2008-06-22 16:26 --- Patch. The problem was that gfortran failed to find a conversion routine for logical(1) to logical(1), now it simply does nothing and reports success. I'm not sure whether BT_VOID needs some special care or not. (Cf. interface.c's gfc_compare_types. Probably BT_VOID can never happen - or can it?) Index: intrinsic.c === --- intrinsic.c (Revision 137011) +++ intrinsic.c @@ -3701,8 +3701,7 @@ gfc_convert_type_warn (gfc_expr *expr, g if (expr-ts.type == BT_UNKNOWN) goto bad; - if (expr-ts.type == BT_DERIVED ts-type == BT_DERIVED - gfc_compare_types (expr-ts, ts)) + if (gfc_compare_types (expr-ts, ts)) return SUCCESS; sym = find_conv (expr-ts, ts); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36590
[Bug other/36579] gcc refuses to recognize libraries on the command line
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-06-22 16:56 --- I think you're mad. I won't be reporting any bugs to gcc until I see signs of intelligence coming from you people. Huh? Also the linker is not part of GCC anyways. It comes from the binutils project. You can see that the gcc driver is just calling ld by adding -v. Also this is how linkers have worked with archives for 20+ years now on UNIX like systems. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36579
[Bug fortran/36599] New: major execution regression for induct.f90 polyhedron benchmark in 4.3.1 on Intel
There is a 20% execution regression on the polyhedron induct.f90 benchmark when compiled with gfortran in gcc 4.3.1 compared to gcc 4.2.4. This reduction appears to be triggered by the -fassociative-math (which appears to require -fno-signed-zeros -fno-trapping-math to actually be used by gfortran). I am attaching induct.s.good generated by... gfortran -fno-signed-zeros -fno-trapping-math --save-temps -O3 induct.f90 which doesn't show the speed regression and induct.s.bad generated by... gfortran -fassociative-math -fno-signed-zeros -fno-trapping-math --save-temps -O3 induct.f90 The induct.f90 and induct.inp data files for compiling this benchmark can be downloaded from http://www.polyhedron.com/web_images/documents/pb05.zip. -- Summary: major execution regression for induct.f90 polyhedron benchmark in 4.3.1 on Intel Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: i686-apple-darwin9 GCC host triplet: i686-apple-darwin9 GCC target triplet: i686-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36599
[Bug fortran/36599] major execution regression for induct.f90 polyhedron benchmark in 4.3.1 on Intel
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2008-06-22 16:58 --- Created an attachment (id=15802) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15802action=view) assembly file generate with -fno-signed-zeros -fno-trapping-math -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36599
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Comment #114 from pepalogik at seznam dot cz 2008-06-22 16:59 --- (In reply to comment #113) It is available when storing a result to memory. Yes, but this requires quite a complicated workaround (solution (4) in my comment #109). So you could say that the IEEE754 double precision type is available even on a processor without any FPU because this can be emulated using integers. Moreover, if we assess things pedantically, the workaround (4) still doesn't fully obey the IEEE single/double precision type(s), because there remains the problem of double rounding of denormals. The IEEE754-1985 allows this. Section 4.3: Normally, a result is rounded to the precision of its destination. However, some systems deliver results only to double or extended destinations. On such a system the user, which may be a high-level language compiler, shall be able to specify that a result be rounded instead to single precision, though it may be stored in the double or extended format with its wider exponent range. [...] [...] AFAIK, the IEEE754-1985 standard was designed from the x87 implementation, so it would have been very surprising that x87 didn't conform to IEEE754-1985. So it seems I was wrong but the IEEE754-1985 standard is also quite wrong. Do you mean that on Windows, long double has (by default) no more precision than double? I don't think so (it's confirmed by my experience). I don't remember my original reference, but here's a new one: http://msdn.microsoft.com/en-us/library/aa289157(vs.71).aspx In fact, this depends on the architecture. I quote: x86. Intermediate expressions are computed at the default 53-bit precision with an extended range [...] I quote, too: Applies To Microsoft#174; Visual C++#174; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug fortran/36599] major execution regression for induct.f90 polyhedron benchmark in 4.3.1 on Intel
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2008-06-22 17:00 --- Created an attachment (id=15803) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15803action=view) assembly file generate with -fassociative-math -fno-signed-zeros -fno-trapping-math -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36599
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Comment #115 from pepalogik at seznam dot cz 2008-06-22 17:28 --- That #174; should be (R). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug fortran/36599] major execution regression for induct.f90 polyhedron benchmark in 4.3.1 on Intel
--- Comment #3 from burnus at gcc dot gnu dot org 2008-06-22 17:54 --- Fortran requires that parenthesis are always honoured. All other associative maths operations are allowed in Fortran, but as IEEE is also allowed, this gives problems e.g. INF is involved or signed zeros. Therefore, gfortran does no associative operations by default, only if -ffinite-math-only is enabled. But in this case, there the parenthesis are still always honoured. At least this is my knowledge about the optimizations done at the moment. Though, at the moment it is unclear to me, why -O3 is slower than -O2. See also PR 35259. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36599
minor cc1 crash (SIGILL in my tests)
I ran into this on NetBSD 4.0; the crash said to report it to NetBSD. When I did so, they said Why don't you let _them_ know, then?, them referring to you people. However, gcc 4.0 does not have either the bugs.html or the BUGS referred to by bugreport.texi, as far as I can see. When I looked at the webpage named in bugreport.texi, it suggests using a gccbug script. There is no gccbug script as far as I can see; the closest thing I see is gccbug.in. When I run it, I get what I suspect is a somewhat malformed bug report; I'm including it below, after my signature, rather than sending it to gcc-gnats, to avoid dropping bogus information in your bug database (send it there yourself if you'd rather have it there). I'm not sure what the missing information should be, nor where to find it. This is the stock NetBSD 4.0 compiler, which reports itself with --version as being 4.1.2 20061021 prerelease, on i386, though I suspect the bug actually applies to any version using a recursive-descent parser. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML[EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B To: [EMAIL PROTECTED] Subject: [dM] cc1 crash (SIGILL) From: mouse X-send-pr-version: 3.113 X-GNATS-Notify: Submitter-Id: net Originator:der Mouse Organization: Dis- Confidential: no Synopsis: cc1 crash on certain input Severity: non-critical Priority: low Category: c Class: ice-on-legal-code Release: Environment: System: NetBSD NetBSD-4-0.Rodents.Montreal.QC.CA 4.0 NetBSD 4.0 (GENERIC) #0: Sun Dec 16 00:20:10 PST 2007 [EMAIL PROTECTED]:/home/builds/ab/netbsd-4-0-RELEASE/i386/200712160005Z-obj/home/builds/ab/netbsd-4-0-RELEASE/src/sys/arch/i386/compile/GENERIC i386 host: @host@ build: @build@ target: @target@ configured with: @gcc_config_arguments@ Description: cc1 crashes (with SIGILL in my test) on sufficiently extreme input. How-To-Repeat: echo int i = z.c yes \( | sed -e 1000q z.c echo 0 z.c yes \) | sed -e 1000q z.c echo \; z.c gcc -c z.c cc: Internal error: Illegal instruction (program cc1) This is presumably just running the recursive-descent parser out of stack space, and, as such, is expected, but bugreport.texi says If the compiler gets a fatal signal, for any input whatever, that is a compiler bug, so presumably you'd like to hear about it. (I'm not sure whether ANSI specifies a limit on paren nesting depth; this might actually be an ice-on-illegal-code if so. If there's any nesting construct without such a limit, a similar overflow can probably be constructed for it.) Fix: Unknown. Limit recursion depth? Switch to some other parser technology that makes it easier to handle such over-the-top input?
[Bug fortran/36599] major execution regression for induct.f90 polyhedron benchmark in 4.3.1 on Intel
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2008-06-22 18:30 --- If the problem is due to the honoring of parenthesis in fortran, why doesn't this issue manifest itself on powerpc-apple-darwin as well? http://gcc.gnu.org/ml/fortran/2008-06/msg00249.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36599
[Bug tree-optimization/36600] New: [4.3 Regression] ICE while building e2fsprogs with -fipa-pta -O2
Nico R. [EMAIL PROTECTED] reports that building e2fsprogs with gcc-4.3.1 and -fipa-pta triggers an ICE ... observed on both x86 and x86_64 gcc-4.2.4 seems to work fine CC tdb.c cc -I../../lib -I../../lib -DLOCALEDIR=\/usr/share/locale\ -DROOT_SYSCONFDIR=\/etc\ -DPACKAGE_NAME=\\ -DPACKAGE_TARNAME=\\ -DPACKAGE_VERSION=\\ -DPACKAGE_STRING=\\ -DPACKAGE_BUGREPORT=\\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DENABLE_HTREE=1 -DENABLE_SWAPFS=1 -DTLS=__thread -DUSE_UUIDD=1 -DPACKAGE=\e2fsprogs\ -DVERSION=\0.14.1\ -DHAVE_LONG_LONG=1 -DHAVE_LONG_DOUBLE=1 -DHAVE_WCHAR_T=1 -DHAVE_WINT_T=1 -DHAVE_INTTYPES_H_WITH_UINTMAX=1 -DHAVE_STDINT_H_WITH_UINTMAX=1 -DHAVE_INTMAX_T=1 -DHAVE_POSIX_PRINTF=1 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_STDLIB_H=1 -DHAVE_UNISTD_H=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1 -DINTDIV0_RAISES_SIGFPE=1 -DHAVE_UNSIGNED_LONG_LONG=1 -DHAVE_UINTMAX_T=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDINT_H=1 -DHAVE_ARGZ_H=1 -DHAVE_LIMITS_H=1 -DHAVE_LOCALE_H=1 -DHAVE_NL_TYPES_H=1 -DHAVE_MALLOC_H=1 -DHAVE_STDDEF_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_ASPRINTF=1 -DHAVE_FWPRINTF=1 -DHAVE_GETCWD=1 -DHAVE_GETEGID=1 -DHAVE_GETEUID=1 -DHAVE_GETGID=1 -DHAVE_GETUID=1 -DHAVE_MEMPCPY=1 -DHAVE_MUNMAP=1 -DHAVE_PUTENV=1 -DHAVE_SETENV=1 -DHAVE_SETLOCALE=1 -DHAVE_SNPRINTF=1 -DHAVE_STPCPY=1 -DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1 -DHAVE_STRTOUL=1 -DHAVE_TSEARCH=1 -DHAVE_WCSLEN=1 -DHAVE___ARGZ_COUNT=1 -DHAVE___ARGZ_STRINGIFY=1 -DHAVE___ARGZ_NEXT=1 -DHAVE___FSETLOCKING=1 -DHAVE_DECL__SNPRINTF=0 -DHAVE_DECL__SNWPRINTF=0 -DHAVE_DECL_FEOF_UNLOCKED=1 -DHAVE_DECL_FGETS_UNLOCKED=0 -DHAVE_DECL_GETC_UNLOCKED=1 -DHAVE_ICONV=1 -DICONV_CONST= -DHAVE_LANGINFO_CODESET=1 -DHAVE_LC_MESSAGES=1 -DENABLE_NLS=1 -DHAVE_GETTEXT=1 -DHAVE_DCGETTEXT=1 -DHAVE_DIRENT_H=1 -DHAVE_ERRNO_H=1 -DHAVE_GETOPT_H=1 -DHAVE_MALLOC_H=1 -DHAVE_MNTENT_H=1 -DHAVE_PATHS_H=1 -DHAVE_SETJMP_H=1 -DHAVE_SIGNAL_H=1 -DHAVE_STDARG_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_TERMIOS_H=1 -DHAVE_UNISTD_H=1 -DHAVE_UTIME_H=1 -DHAVE_LINUX_FD_H=1 -DHAVE_LINUX_MAJOR_H=1 -DHAVE_NETINET_IN_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_MMAN_H=1 -DHAVE_SYS_PRCTL_H=1 -DHAVE_SYS_QUEUE_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SELECT_H=1 -DHAVE_SYS_SOCKET_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_SYSCALL_H=1 -DHAVE_SYS_SYSMACROS_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UN_H=1 -DHAVE_SYS_WAIT_H=1 -DHAVE_SYS_MOUNT_H=1 -DHAVE_NET_IF_H=1 -DHAVE_VPRINTF=1 -DHAVE_RECLEN_DIRENT=1 -DHAVE_TYPE_SSIZE_T=1 -DHAVE_LSEEK64_PROTOTYPE=1 -DSIZEOF_SHORT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG=8 -DSIZEOF_LONG_LONG=8 -DHAVE_INTTYPES_H=1 -DHAVE_INTPTR_T=1 -DHAVE_GETRUSAGE=1 -DHAVE_LLSEEK=1 -DHAVE_LSEEK64=1 -DHAVE_OPEN64=1 -DHAVE_FSTAT64=1 -DHAVE_FTRUNCATE64=1 -DHAVE_STRTOULL=1 -DHAVE_STRCASECMP=1 -DHAVE_SRANDOM=1 -DHAVE_JRAND48=1 -DHAVE_FCHOWN=1 -DHAVE_MALLINFO=1 -DHAVE_FDATASYNC=1 -DHAVE_STRNLEN=1 -DHAVE_STRPTIME=1 -DHAVE_STRDUP=1 -DHAVE_SYSCONF=1 -DHAVE_PATHCONF=1 -DHAVE_POSIX_MEMALIGN=1 -DHAVE_MEMALIGN=1 -DHAVE_VALLOC=1 -DHAVE___SECURE_GETENV=1 -DHAVE_PRCTL=1 -DHAVE_MMAP=1 -DHAVE_UTIME=1 -DHAVE_SETRESUID=1 -DHAVE_SETRESGID=1 -DHAVE_DLOPEN=1 -DHAVE_EXT2_IOCTLS=1 -pipe -fipa-pta -O2 -c tdb.c -o tdb.o tdb.c: In function seen_insert: tdb.c:4143: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. -- Summary: [4.3 Regression] ICE while building e2fsprogs with - fipa-pta -O2 Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vapier at gentoo dot org GCC host triplet: i686-linux-gnu GCC target triplet: i686-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36600
[Bug tree-optimization/36600] [4.3 Regression] ICE while building e2fsprogs with -fipa-pta -O2
--- Comment #1 from vapier at gentoo dot org 2008-06-22 19:48 --- Created an attachment (id=15804) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15804action=view) e2fsprogs-fipa-pta.i reduced test case by Nico R. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36600
[Bug tree-optimization/36600] ICE while building e2fsprogs with -fipa-pta -O2
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-06-22 19:48 --- -fipa-pta was never did anything anyways . -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.3.1 | Known to work|4.2.4 | Summary|[4.3 Regression] ICE while |ICE while building e2fsprogs |building e2fsprogs with - |with -fipa-pta -O2 |fipa-pta -O2| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36600
[Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
--- Comment #10 from danglin at gcc dot gnu dot org 2008-06-22 20:02 --- The same change gcc.c-torture/execute/20040709-2.c on all hppa targets (both 32 and 64 bit). On hppa64-hp-hpux11.11, testK is the first test to fail. In this case, it appears retmeK is miscompiled. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
[Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
--- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca 2008-06-22 20:04 --- Subject: Re: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above to fail. In this case, it appears retmeK is miscompiled. Simplified test attached. Dave --- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca 2008-06-22 20:04 --- Created an attachment (id=15805) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15805action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
[Bug c++/36601] New: Can't be friended by template class argument
This:
templatetypename F class Foo { friend class F; };
gets you this:
~/ootbc/asm$ g++ foo.cc
foo.cc:2: error: using template type parameter F after class
foo.cc:2: error: friend declaration does not name a class or function
--
Summary: Can't be friended by template class argument
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36601
[Bug c++/24629] Can't use template argument as friend
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-06-22 20:13 --- *** Bug 36601 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||igodard at pacbell dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24629
[Bug c++/36601] Can't be friended by template class argument
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-22 20:13 --- Because the C++ standard says you cannot. See PR 24629. *** This bug has been marked as a duplicate of 24629 *** -- 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=36601
[Bug other/36595] Multiple warnings about C++ for C codes
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-22 20:27 --- Not really a regression as the warning was just enabled in the first place recently. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|bootstrap |other Summary|[4.4 Regression] Multiple |Multiple warnings about C++ |warnings about C++ for C|for C codes |codes | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36595
[Bug fortran/36599] major execution regression for induct.f90 polyhedron benchmark in 4.3.1 on Intel
--- Comment #5 from dominiq at lps dot ens dot fr 2008-06-22 20:43 --- I think the problem is that the vector cost model is not tune for the Intel Core family. My understanding of the problem is that without the relevant suboption of -ffast-math the inner implicit loops in induct are not vectorized, while they are wrongly vectorized (they are of length 3) with -ffast-math. This can be prevented by using '--param min-vect-loop-bound=2': [ibook-dhum] lin/test% gfortran -O3 induct.f90 76.901u 0.099s 1:17.11 99.8%0+0k 0+1io 34pf+0w [ibook-dhum] lin/test% gfortran -ffast-math -O3 induct.f90 96.605u 0.133s 1:36.82 99.9%0+0k 0+0io 0pf+0w [ibook-dhum] lin/test% gfortran -ffast-math -O3 --param min-vect-loop-bound=2 induct.f90 73.239u 0.093s 1:13.39 99.9%0+0k 0+0io 0pf+0w [ibook-dhum] lin/test% gfortran -m64 -O3 induct.f90 65.322u 0.075s 1:05.44 99.9%0+0k 0+0io 0pf+0w [ibook-dhum] lin/test% gfortran -m64 -ffast-math -O3 induct.f90 90.604u 0.097s 1:30.77 99.9%0+0k 0+0io 0pf+0w [ibook-dhum] lin/test% gfortran -m64 -ffast-math -O3 --param min-vect-loop-bound=2 induct.f90 61.007u 0.049s 1:01.13 99.8%0+0k 0+0io 41pf+0w In trunk these inner loops are unrolled before vectorization and the run time is now ~36s. So I am not sure that the observed behavior is really a regression, but rather a lack of suitable cost model. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36599
[Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
--- Comment #13 from danglin at gcc dot gnu dot org 2008-06-22 20:44
---
retmeK (struct K x)
{
unnamed-unsigned:10 SR.14;
unnamed-unsigned:15 SR.13;
unnamed-unsigned:7 SR.12;
unnamed-unsigned:10 SR.11;
unnamed-unsigned:15 SR.10;
unnamed-unsigned:15 x$i;
unnamed-unsigned:10 x$j;
unnamed-unsigned:7 x$B0F7;
struct K D.1258;
bb 2:
x$B0F7_1 = 0;
x$j_2 = 0;
x$i_3 = 0;
SR.13_4 = x.i;
x$i_5 = SR.13_4;
SR.14_6 = x.j;
x$j_7 = SR.14_6;
x$B0F7_8 = BIT_FIELD_REF x, 7, 0;
D.1258.i ={v} x$i_5;
D.1258.j ={v} x$j_7;
SR.12_9 = x$B0F7_8 1;
BIT_FIELD_REF D.1258, 7, 0 ={v} SR.12_9;
return D.1258;
}
Don't understand...
At -O0, we just have
retmeK (struct K x)
{
struct K D.1260;
bb 2:
D.1260 = x;
return D.1260;
}
and it works.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
[Bug tree-optimization/36602] New: memset should be optimized into an empty CONSTRUCTOR
I noticed this while looking into tree-ssa-sccvn.c sources (though I doubt it
helps in general really). But anyways we should optimize the following code
into just a return 0;:
struct f
{
int t, k;
int g[1024];
};
int g(void)
{
struct f a;
__builtin_memset(a, 0, sizeof(a));
return a.t;
}
-- CUT ---
You can see that with the above code we get a zeroing for the struct still.
--
Summary: memset should be optimized into an empty CONSTRUCTOR
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: missed-optimization, TREE
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36602
[Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
--- Comment #14 from rguenther at suse dot de 2008-06-22 21:13 ---
Subject: Re: [4.4 Regression] FAIL:
gcc.c-torture/execute/20040709-1.c execution at -O2 and above
On Sun, 22 Jun 2008, danglin at gcc dot gnu dot org wrote:
--- Comment #13 from danglin at gcc dot gnu dot org 2008-06-22 20:44
---
retmeK (struct K x)
{
unnamed-unsigned:10 SR.14;
unnamed-unsigned:15 SR.13;
unnamed-unsigned:7 SR.12;
unnamed-unsigned:10 SR.11;
unnamed-unsigned:15 SR.10;
unnamed-unsigned:15 x$i;
unnamed-unsigned:10 x$j;
unnamed-unsigned:7 x$B0F7;
struct K D.1258;
bb 2:
x$B0F7_1 = 0;
x$j_2 = 0;
x$i_3 = 0;
SR.13_4 = x.i;
x$i_5 = SR.13_4;
SR.14_6 = x.j;
x$j_7 = SR.14_6;
x$B0F7_8 = BIT_FIELD_REF x, 7, 0;
D.1258.i ={v} x$i_5;
D.1258.j ={v} x$j_7;
SR.12_9 = x$B0F7_8 1;
BIT_FIELD_REF D.1258, 7, 0 ={v} SR.12_9;
return D.1258;
}
Don't understand...
At -O0, we just have
retmeK (struct K x)
{
struct K D.1260;
bb 2:
D.1260 = x;
return D.1260;
}
and it works.
Well, SRA is broken (cost-wise at least) since lxos changes.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Comment #116 from vincent at vinc17 dot org 2008-06-22 21:14 --- (In reply to comment #114) Yes, but this requires quite a complicated workaround (solution (4) in my comment #109). The problem is on the compiler side, which could store every result of a cast or an assignment to memory (this is inefficient, but that's what you get with the x87, and the ISO C language could be blamed too for *requiring* something like that instead of being more flexible). So you could say that the IEEE754 double precision type is available even on a processor without any FPU because this can be emulated using integers. Yes, but a conforming implementation would be the processor + a library, not just the processor with its instruction set. Moreover, if we assess things pedantically, the workaround (4) still doesn't fully obey the IEEE single/double precision type(s), because there remains the problem of double rounding of denormals. As I said, in this particular case (underflow/overflow), double rounding is allowed by the IEEE standard. It may not be allowed by some languages (e.g. XPath, and Java in some mode) for good or bad reasons, but this is another problem. I quote, too: Applies To Microsoft#174; Visual C++#174; Now I assume that it follows the MS-Windows API (though nothing is certain with Microsoft). And the other compilers under MS-Windows could (or should) do the same thing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug tree-optimization/36602] memset should be optimized into an empty CONSTRUCTOR
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-06-22 21:26 --- Confirmed. -- rguenth 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-06-22 21:26:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36602
[Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
--- Comment #15 from dave at hiauly1 dot hia dot nrc dot ca 2008-06-22
21:34 ---
Subject: Re: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c
execution at -O2 and above
x$B0F7_8 = BIT_FIELD_REF x, 7, 0;
D.1258.i ={v} x$i_5;
D.1258.j ={v} x$j_7;
SR.12_9 = x$B0F7_8 1;
BIT_FIELD_REF D.1258, 7, 0 ={v} SR.12_9;
return D.1258;
Well, SRA is broken (cost-wise at least) since lxos changes.
Why the shift? It seems incorrect.
SRA also seems to be manipulating the k and l fields together for
some reason. Why not all the fields since K is packed and the total
bit length is less than a word?
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
[Bug target/36603] New: Use \r\n for generated *.s files on Windows
To quote James van Buskirk on comp.lang.fortran: Is there any possibility for gfortran's output text files to receive line termination appropriate to the host OS? (he can't display *.s files properly on Windows without converting them first) -- Summary: Use \r\n for generated *.s files on Windows Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target 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=36603
[Bug target/36603] Use \r\n for generated *.s files on Windows
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-22 21:48 --- (he can't display *.s files properly on Windows without converting them first) What text editor is he using? I know NotePad does not support UNIX style line endings but WordPad supports it which is what I use on Windows to read *.s files. I don't think we should support this really. If we do then can we output UTF-8 line endings instead :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36603
[Bug tree-optimization/16427] dead 0 memset not optimized away
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-06-22 21:54 --- Related to bug 36602. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16427
[Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
--- Comment #16 from rguenther at suse dot de 2008-06-22 22:23 ---
Subject: Re: [4.4 Regression] FAIL:
gcc.c-torture/execute/20040709-1.c execution at -O2 and above
On Sun, 22 Jun 2008, dave at hiauly1 dot hia dot nrc dot ca wrote:
--- Comment #15 from dave at hiauly1 dot hia dot nrc dot ca 2008-06-22
21:34 ---
Subject: Re: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c
execution at -O2 and above
x$B0F7_8 = BIT_FIELD_REF x, 7, 0;
D.1258.i ={v} x$i_5;
D.1258.j ={v} x$j_7;
SR.12_9 = x$B0F7_8 1;
BIT_FIELD_REF D.1258, 7, 0 ={v} SR.12_9;
return D.1258;
Well, SRA is broken (cost-wise at least) since lxos changes.
Why the shift? It seems incorrect.
It looks like it is only assigning the 6-bit part of the k, l
combination. Is the above after the SRA pass in question or after
some more optimizations?
Eventually this is a bit-field-ref vs. BITS_BIG_ENDIAN/BYTES_BIG_ENDIAN
issue -- it was never clear to me how the bit-field position in
a bit-field-ref relates to those.
SRA also seems to be manipulating the k and l fields together for
some reason. Why not all the fields since K is packed and the total
bit length is less than a word?
The cost metric is of course simply broken.
I'll try to investigate at some point with a cross.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
[Bug fortran/36599] major execution regression for induct.f90 polyhedron benchmark in 4.3.1 on Intel
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2008-06-22 22:30 --- IMHO when a new optimization technique is enabled by default in -O3 and degrades common benchmark performance, it qualifies as a performance regression for that release. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36599
[Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
--- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca 2008-06-22
22:43 ---
Subject: Re: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c
execution at -O2 and above
--- Comment #15 from dave at hiauly1 dot hia dot nrc dot ca 2008-06-22
21:34 ---
Subject: Re: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c
execution at -O2 and above
x$B0F7_8 = BIT_FIELD_REF x, 7, 0;
D.1258.i ={v} x$i_5;
D.1258.j ={v} x$j_7;
SR.12_9 = x$B0F7_8 1;
BIT_FIELD_REF D.1258, 7, 0 ={v} SR.12_9;
return D.1258;
Well, SRA is broken (cost-wise at least) since lxos changes.
Why the shift? It seems incorrect.
It looks like it is only assigning the 6-bit part of the k, l
combination. Is the above after the SRA pass in question or after
some more optimizations?
It appears first in the esra pass dump:
;; Function retmeK (retmeK)
Initial instantiation for x
Using element-copy for x
x$B0F7 - x$B0F7
x.j - x$j
x.i - x$i
Initial instantiation for D.1258
Using block-copy for D.1258
Symbols to be put in SSA form
{ x x$B0F7 x$j x$i SR.10 SR.11 SR.12 SR.13 SR.14 }
Incremental SSA update started at block: 0
Number of blocks in CFG: 3
Number of blocks to update: 2 ( 67%)
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
[Bug middle-end/36594] [4.4 Regression] multiple regressions on powerpc at rev.136976
--- Comment #3 from dje at gcc dot gnu dot org 2008-06-22 23:42 --- Yes, similarly multiple regressions on AIX. Reverting Honza's patch fixes it. The failure on AIX is: gcc/testsuite/gcc.c-torture/compile/20050122-2.c:11: internal compiler error: in copy_rtx, at rtl.c:314 rs6000.md restore_stack_nonlocal now receives a REG as operand[1] due to the copy_to_reg change. The pattern calls adjust_address_nv on the operand, adjust_address_1 blindly dereferences the operand it thinks is a memref to extract the address and applies copy_rtx() to the address. copy_rtx receives RTL with code UNKNOWN. Fun and hilarity ensues. -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P2 Last reconfirmed|-00-00 00:00:00 |2008-06-22 23:42:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36594
[Bug fortran/36599] major execution regression for induct.f90 polyhedron benchmark in 4.3.1 on Intel
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2008-06-23 00:07 --- Looking at the polyhedron benchmark data from http://physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/, there appears to be a big jump in performance in the induct runtime with -ffast-math and -O3 between 2008-04-24 and 2008-05-01. Unfortunately, there is a gap in the data between those dates with the later showing the increase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36599
[Bug fortran/36599] major execution regression for induct.f90 polyhedron benchmark in 4.3.1 on Intel
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2008-06-23 00:46 --- Looking at the SuSe polyhedron benchmark servers, the induct regression in trunk was eliminated between 2008-04-27 and 2008-04-28. My guess is this was fixed with... r134730 | rguenth | 2008-04-27 12:27:08 -0400 (Sun, 27 Apr 2008) | 42 lines 2008-04-27 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/18754 PR tree-optimization/34223 * tree-pass.h (pass_complete_unrolli): Declare. * tree-ssa-loop-ivcanon.c (try_unroll_loop_completely): Print loop size before and after unconditionally of UL_NO_GROWTH in effect. Rewrite loop into loop closed SSA form if it is not already. (tree_unroll_loops_completely): Re-structure to iterate over innermost loops with intermediate CFG cleanups. Unroll outermost loops only if requested or the code does not grow doing so. * tree-ssa-loop.c (gate_tree_vectorize): Don't shortcut if no loops are available. (tree_vectorize): Instead do so here. (tree_complete_unroll): Also unroll outermost loops. (tree_complete_unroll_inner): New function. (gate_tree_complete_unroll_inner): Likewise. (pass_complete_unrolli): New pass. * tree-ssa-loop-manip.c (find_uses_to_rename_use): Only record uses outside of the loop. (tree_duplicate_loop_to_header_edge): Only verify loop-closed SSA form if it is available. * tree-flow.h (tree_unroll_loops_completely): Add extra parameter. * passes.c (init_optimization_passes): Schedule complete inner loop unrolling pass before the first CCP pass after final inlining. * gcc.dg/tree-ssa/loop-36.c: New testcase. * gcc.dg/tree-ssa/loop-37.c: Likewise. * gcc.dg/vect/vect-118.c: Likewise. * gcc.dg/Wunreachable-8.c: XFAIL bogus warning. * gcc.dg/vect/vect-66.c: Increase loop trip count. * gcc.dg/vect/no-section-anchors-vect-66.c: Likewise. * gcc.dg/vect/no-section-anchors-vect-69.c: Likewise. * gcc.dg/vect/vect-76.c: Likewise. * gcc.dg/vect/vect-outer-6.c: Likewise. * gcc.dg/vect/vect-outer-1.c: Likewise. * gcc.dg/vect/vect-outer-1a.c: Likewise. * gcc.dg/vect/vect-11a.c: Likewise. * gcc.dg/vect/vect-shift-1.c: Likewise. * gcc.target/i386/vectorize1.c: Likewise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36599
[Bug target/36603] Use \r\n for generated *.s files on Windows
--- Comment #2 from dannysmith at users dot sourceforge dot net 2008-06-23 02:54 --- Using \r\n will cause problems with pch files. This is why I made this change 2004-06-05 Danny Smith [EMAIL PROTECTED] * toplev.c (init_asm_output): Add explicit 'b' to mode when opening asm_out_file. This is the first complaint I've heard since that patch. Don't use Notepad for anything. Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dannysmith at users dot |dot org |sourceforge dot net Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-23 02:54:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36603
[Bug target/27880] [4.2/4.3/4.4 regression] undefined reference to `_Unwind_GetIPInfo'
--- Comment #26 from russiane39 at gmail dot com 2008-06-23 04:34 --- This bug also affects OpenSolaris. # gcc -v Using built-in specs. Target: i386-pc-solaris2.11 Configured with: ../gcc-4.2.4/configure --prefix=/usr/gnu --libdir=/usr/gnu/lib --libexecdir=/usr/gnu/lib --mandir=/usr/gnu/share/man --infodir=/usr/share/info --with-as=/usr/gnu/bin/as --with-gnu-as --with-ld=/usr/gnu/bin/ld --with-gnu-ld --enable-languages=c,c++,fortran,objc --enable-shared --disable-static --enable-decimal-float -disable-nls Thread model: posix gcc version 4.2.4 - g++ -I/usr/include -I/usr/local/include -Wall -D_REENTRANT -pthreads -I/usr/local/include/openssl -DHAVE_SSL -I/opt/mysql/mysql/include -m64 -mtune=k8 -DMY_ATOMIC_MODE_RWLOCKS -m64 -O2 -mtune=k8 -static-libgcc -o ascent-logonserver AccountCache.o AuthSocket.o LogonCommServer.o LogonConsole.o LogonOpcodes.o LogonStdAfx.o AutoPatcher.o Main.o -L/export/home/burlex/summit/src/ascent-shared -L/export/home/burlex/summit/dep/src/zlib -L/usr/lib/amd64 -L/usr/local/lib/amd64 -L/usr/gnu/lib/amd64 -L/usr/sfw/lib/amd64 -L/usr/gnu/lib -L/opt/mysql/mysql/lib -lmysqlclient -lposix4 -lresolv -lgen -lsocket -lnsl -lm -lshared -lzlib -lz -lssl -lcrypto /usr/gnu/lib/amd64/libstdc++.so: undefined reference to [EMAIL PROTECTED]' collect2: ld returned 1 exit status -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27880
