[Bug target/38130] [4.4 regression]__builtin_alloca (vs IRA?) testsuite failures on mingw32
--- Comment #1 from ktietz at gcc dot gnu dot org 2008-11-16 09:03 --- This problem exists also for x86_64 based mingw. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added CC||ktietz at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38130
[Bug fortran/38135] RESHAPE gives wrong result
--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-11-16 09:04 --- Simplified test case (without the second reshape): The problem appears to be the empty SOURCE with the presence of PAD. $ cat bar.f90 program main integer, parameter :: N = 3 integer :: A(N,N) integer :: b(n+1) b = (/ 1, 2, 2, 2 /) A(1:N,1:N)=reshape(A(1:0,1),(/N,N/),b) write(*,'(3i5)') A end program main $ gfortran bar.f90 $ ./a.out 1*1 *1* 1*1 -- tkoenig 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-16 09:04:10 date|| Summary|FORALL gives wrong result |RESHAPE gives wrong result http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38135
[Bug fortran/38152] New: ICE for procedure pointer assignment
The following (possibly invalid) program ICEs: MODULE m IMPLICIT NONE PROCEDURE(test), POINTER :: procptr CONTAINS SUBROUTINE test () IMPLICIT NONE CALL bar (test) procptr => test END SUBROUTINE test END MODULE m The ICE is however not related to the missing RECURSIVE and can be reproduced with valid code, see below. -- Summary: ICE for procedure pointer assignment Product: gcc Version: unknown Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: domob at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38152
[Bug fortran/38152] ICE for procedure pointer assignment
--- Comment #1 from domob at gcc dot gnu dot org 2008-11-16 09:27 --- Daniel Kraft wrote: > > I'm working out a test-case for PR 37779 and came across the following > > program, which ICEs for today's trunk gfortran: > > > > SUBROUTINE test () > > IMPLICIT NONE > > procptr => test If one moves the procedure-pointer declaration in the subroutine, it works. The difference of the -fdump-tree-original/gimple is: + void (*) (void) procptr; The failing assert in make_decl_rtl is: /* A weak alias has TREE_PUBLIC set but not the other bits. */ gcc_assert (TREE_CODE (decl) != VAR_DECL || TREE_STATIC (decl) || TREE_PUBLIC (decl) || DECL_EXTERNAL (decl) || DECL_REGISTER (decl)); > > Is this already a known bug? Sorry that I don't have an overview... > > If not, I'll file a report. Please do so, I think it is not known. By the way, the following also fails: module m procedure(), pointer :: procptr end module m use m external foo procptr => foo end with Error: 'procptr' in the pointer assignment at (1) cannot be an l-value since it is a procedure I think the "proc_ptr" attribute is not properly saved in the .mod file. Tobias -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38152
[Bug ada/38127] [4.4 Regression] ACATS cd1c04e fails on sparc, hppa
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2008-11-16 10:06 --- Subject: Bug 38127 Author: ebotcazou Date: Sun Nov 16 10:05:22 2008 New Revision: 141913 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141913 Log: PR ada/38127 * gcc-interface/decl.c (make_type_from_size): Do not special-case boolean types. * gcc-interface/targtyps.c: Tweak comment. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/decl.c trunk/gcc/ada/gcc-interface/targtyps.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38127
[Bug ada/38127] [4.4 Regression] ACATS cd1c04e fails on sparc, hppa
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2008-11-16 10:07 --- This should work now. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||11/msg00731.html Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38127
[Bug tree-optimization/38154] New: comp-goto-1.c failing when compiled with -ftree-parallelize-loops=4
/Develop/mainline_parallel/gcc/gcc/testsuite/gcc.c-torture/execute/comp-goto-1.c -w -O1 -lm -ftree-parallelize-loops=4 is failing at verify_flow_info In function 'simulator_kernel': /Develop/mainline_parallel/gcc/gcc/testsuite/gcc.c-torture/execute/comp-goto-1.c:57: error: label sim_base_addr has incorrect context in bb 8 /Develop/mainline_parallel/gcc/gcc/testsuite/gcc.c-torture/execute/comp-goto-1.c:57: confused by earlier errors, bailing out The context for label sim_base_addr is the outlined function simulator_kernel._loopfn.0 and not simulator_kernel as expected -- Summary: comp-goto-1.c failing when compiled with -ftree- parallelize-loops=4 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: razya at il dot ibm dot com GCC build triplet: powerpc64-suse-linux GCC host triplet: powerpc64-suse-linux GCC target triplet: powerpc64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38154
[Bug tree-optimization/38153] New: failure in testcase when compiled with -ftree-paralleilze-loops
when compiling : /Develop/mainline_parallel/gcc/gcc/testsuite/gcc.c-torture/execute/comp-goto-1.c -w -O1 -ftree-parallelize-loops=4 We get compiler error during verify_flow_info comp-goto-1.c:57: error: label sim_base_addr has incorrect context in bb 8 The context for sim_base_addr is the new outlined function, simulator_kernel._loopfn.0 and not simulator_kernel as expected. while -- Summary: failure in testcase when compiled with -ftree- paralleilze-loops Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: razya at il dot ibm dot com GCC build triplet: powerpc64-suse-linux GCC host triplet: powerpc64-suse-linux GCC target triplet: powerpc64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38153
[Bug fortran/38135] RESHAPE gives wrong result
--- Comment #4 from mikael at gcc dot gnu dot org 2008-11-16 11:38 --- (In reply to comment #3) > The problem appears to be the empty SOURCE with the presence of PAD. I agree. There are two bugs actually: (1) the front-end doesn't expand the reshape. (at least in this case: reshape([integer::],[N,N],[1,2,2,2]) ) (2) reshape gives wrong results. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38135
[Bug target/38155] [4.4 regression] gcc build failure on powerpc biarch
--- Comment #1 from debian-gcc at lists dot debian dot org 2008-11-16 11:49 --- not ada specific -- debian-gcc at lists dot debian dot org changed: What|Removed |Added Summary|[4.4 regression] gnat build |[4.4 regression] gcc build |failure on powerpc biarch |failure on powerpc biarch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38155
[Bug middle-end/38133] xgcc: Internal error: Killed (program cc1) by compiling gcc 4.3.2
--- Comment #2 from jan at jans-seite dot de 2008-11-16 10:17 --- /proc/swaps: FilenameTypeSizeUsed Priority /dev/sda1 partition 1052216 x -1 /usr/local/swap.filefile1048568 0 -2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38133
[Bug target/38155] New: [4.4 regression] gnat build failure on powerpc biarch
last known sucessful bootstrap was on 2008. configured with: --enable-languages=c,c++,java,fortran,objc,obj-c++,ada --prefix=/usr/lib/gcc-snapshot --enable-shared --enable-mpfr --disable-softfloat --enable-secureplt --enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32 --with-long-double-128 --disable-werror --build=powerpc-linux-gnu --host=powerpc-linux-gnu --target=powerpc-linux-gnu gnatgcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-de finition -Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -o cc1-dummy c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o c-ppoutput.o c-cppbuiltin.o c-objc-common.o c-dump.o c-pch.o c-parser.o rs6000-c.o c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o dummy-checksum.o \ main.o tree-browser.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -lmpfr -lgmp -lcloog -lmpfr -lgmp /usr/lib/gcc/powerpc-linux-gnu/4.3.2/../../../../lib/crt1.o: In function `_start': (.text+0x20): relocation truncated to fit: R_PPC_REL24 against symbol `__libc_start_main@@GLIBC_2.0' defined in .glink section in /usr/lib/gcc/powerpc-linux-gnu/4.3.2/../../../../lib/crt1.o /usr/lib/gcc/powerpc-linux-gnu/4.3.2/crtbegin.o:(.fini+0x0): relocation truncated to fit: R_PPC_REL24 against `.text' /usr/lib/gcc/powerpc-linux-gnu/4.3.2/crtend.o:(.init+0x0): relocation truncated to fit: R_PPC_REL24 against `.text' c-lang.o: In function `VEC_tree_base_quick_insert': /home/doko/gcc/snap/gcc-snapshot-20081116/build/gcc/../../src/gcc/tree.h:190: relocation truncated to fit: R_PPC_REL24 against symbol `memmove@@GLIBC_2.0' defined in .glink section in /usr/lib/gcc/powerpc-linux-gnu/4.3.2/../../../../lib/crt1.o c-lang.o: In function `VEC_tree_base_ordered_remove': /home/doko/gcc/snap/gcc-snapshot-20081116/build/gcc/../../src/gcc/tree.h:190: relocation truncated to fit: R_PPC_REL24 against symbol `memmove@@GLIBC_2.0' defined in .glink section in /usr/lib/gcc/powerpc-linux-gnu/4.3.2/../../../../lib/crt1.o c-lang.o: In function `VEC_tree_base_block_remove': /home/doko/gcc/snap/gcc-snapshot-20081116/build/gcc/../../src/gcc/tree.h:190: relocation truncated to fit: R_PPC_REL24 against symbol `memmove@@GLIBC_2.0' defined in .glink section in /usr/lib/gcc/powerpc-linux-gnu/4.3.2/../../../../lib/crt1.o c-lang.o: In function `VEC_tree_gc_copy': /home/doko/gcc/snap/gcc-snapshot-20081116/build/gcc/../../src/gcc/tree.h:191: relocation truncated to fit: R_PPC_REL24 against symbol `memcpy@@GLIBC_2.0' defined in .glink section in /usr/lib/gcc/powerpc-linux-gnu/4.3.2/../../../../lib/crt1.o c-lang.o: In function `VEC_tree_gc_safe_grow_cleared': /home/doko/gcc/snap/gcc-snapshot-20081116/build/gcc/../../src/gcc/tree.h:191: relocation truncated to fit: R_PPC_REL24 against symbol `memset@@GLIBC_2.0' defined in .glink section in /usr/lib/gcc/powerpc-linux-gnu/4.3.2/../../../../lib/crt1.o c-lang.o: In function `VEC_tree_heap_free': /home/doko/gcc/snap/gcc-snapshot-20081116/build/gcc/../../src/gcc/tree.h:192: relocation truncated to fit: R_PPC_REL24 against symbol `free@@GLIBC_2.0' defined in .glink section in /usr/lib/gcc/powerpc-linux-gnu/4.3.2/../../../../lib/crt1.o c-lang.o: In function `VEC_tree_heap_copy': /home/doko/gcc/snap/gcc-snapshot-20081116/build/gcc/../../src/gcc/tree.h:192: relocation truncated to fit: R_PPC_REL24 against symbol `memcpy@@GLIBC_2.0' defined in .glink section in /usr/lib/gcc/powerpc-linux-gnu/4.3.2/../../../../lib/crt1.o c-lang.o: In function `VEC_tree_heap_safe_grow_cleared': /home/doko/gcc/snap/gcc-snapshot-20081116/build/gcc/../../src/gcc/tree.h:192: additional relocation overflows omitted from the output collect2: ld returned 1 exit status make[5]: *** [cc1-dummy] Error 1 make[5]: Leaving directory `/home/doko/gcc/snap/gcc-snapshot-20081116/build/gcc' make[4]: *** [all-stage1-gcc] Error 2 -- Summary: [4.4 regression] gnat build failure on powerpc biarch Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org GCC target triplet: powerpc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38155
[Bug fortran/37926] Program gives wrong output (connected to char len)
--- Comment #7 from pault at gcc dot gnu dot org 2008-11-16 12:02 --- Subject: Bug 37926 Author: pault Date: Sun Nov 16 12:00:44 2008 New Revision: 141914 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141914 Log: 2008-11-16 Paul Thomas <[EMAIL PROTECTED]> PR fortran/37926 * trans-expr.c (gfc_free_interface_mapping): Null sym->formal (gfc_add_interface_mapping): Copy the pointer to the formal arglist, rather than using copy_formal_args. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37926
[Bug tree-optimization/38156] New: gcc.dg/tree-ssa/update-unswitch-1.c fails when compiled with -ftree-parallelize-loops=4
testsuite/gcc.dg/tree-ssa/update-unswitch-1.c is failing when compiled with -ftree-parallelize-loops=4 In function âblaâ: /Develop/mainline_parallel/gcc/gcc/testsuite/gcc.dg/tree-ssa/update-unswitch-1.c:4: internal compiler error: Segmentation fault There are reduction patterns in this tescase, for which the field are not recorded properly. -- Summary: gcc.dg/tree-ssa/update-unswitch-1.c fails when compiled with -ftree-parallelize-loops=4 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: razya at il dot ibm dot com GCC build triplet: powerpc64-suse-linux GCC host triplet: powerpc64-suse-linux GCC target triplet: powerpc64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38156
[Bug fortran/38119] [4.4 Regression] character ICE in gfc_trans_create_temp_array
--- Comment #3 from pault at gcc dot gnu dot org 2008-11-16 12:13 --- Subject: Bug 38119 Author: pault Date: Sun Nov 16 12:11:53 2008 New Revision: 141915 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141915 Log: 2008-11-16 Paul Thomas <[EMAIL PROTECTED]> PR fortran/38119 * trans-array.c (gfc_trans_create_temp_array): Set the loop->from to zero and the renormalisation of loop->to for all dimensions. 2008-11-16 Paul Thomas <[EMAIL PROTECTED]> PR fortran/38119 * gfortran.dg/array_temporaries_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/array_temporaries_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38119
[Bug fortran/38119] [4.4 Regression] character ICE in gfc_trans_create_temp_array
--- Comment #4 from pault at gcc dot gnu dot org 2008-11-16 12:16 --- Fixed on trunk. Thanks for the report. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38119
[Bug fortran/38095] character ICE
--- Comment #15 from pault at gcc dot gnu dot org 2008-11-16 12:22 --- (In reply to comment #14) > (In reply to comment #13) > > > I filled PR38119 for that PR. > > This is probably stupid but what is the difference between the two PRs? 'twas stupid - I missed the difference between the testcases:-( Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38095
[Bug fortran/38138] [4.4 Regression] Revision 141890 caused gfortran.dg/proc_decl_18.f90
--- Comment #2 from pault at gcc dot gnu dot org 2008-11-16 12:16 --- HJ - I just fixed this on trunk, I believe. Note that I used the old PR in the ChangeLog, for which apologies. Thanks for the quick report. I would appreciate confirmation that this really did the job. Best regards Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38138
[Bug tree-optimization/38156] gcc.dg/tree-ssa/update-unswitch-1.c fails when compiled with -ftree-parallelize-loops=4
--- Comment #1 from razya at il dot ibm dot com 2008-11-16 12:12 --- (In reply to comment #0) > testsuite/gcc.dg/tree-ssa/update-unswitch-1.c is failing when compiled with > -ftree-parallelize-loops=4 > In function âblaâ: > /Develop/mainline_parallel/gcc/gcc/testsuite/gcc.dg/tree-ssa/update-unswitch-1.c:4: > internal compiler error: Segmentation fault > There are reduction patterns in this tescase, for which the field are > not recorded properly. Would like to be assigned for this bug. Razya -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38156
[Bug rtl-optimization/36365] [4.3/4.4 Regression] Hang in df_analyze
--- Comment #9 from steven at gcc dot gnu dot org 2008-11-16 12:17 --- Advice to folks caring about compiler stability instead of supposedly faster: Always use double-queue instead of overeager. The overeager solver is just not reliable enough, and I have never found any proof for the speed benefit that Seongbae claimed it has. The theoretical worst-case time for the overeager algorithm is exponential in the number of basic blocks, for densely connected CFGs. I have argued before that such an algorithm should *never* have been selected as the default for GCC, even if it is, say, 0.5% faster for a GCC bootstrap (but I did the comparison last year and I have never actually measured any benefits of overeager over double queue). For the double queue, and also for the hybrid search, the number of passes has a reasonable proven upper bound for any CFG, so these algorithms are much more reliable. See also the discussion in PR34400, esp. comments 25-28: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34400#c25 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34400#c28 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36365
[Bug middle-end/38140] [4.4 Regression] ice for C code with -O2
--- Comment #3 from jakub at gcc dot gnu dot org 2008-11-16 12:33 ---
Shorter testcase:
int foo (void *x)
{
int (*fn) (int);
*(void **)&fn = x;
return fn (6);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38140
[Bug bootstrap/37739] [4.4 Regression] bootstrap broken with core gcc > gcc-4.2.x
--- Comment #5 from jakub at gcc dot gnu dot org 2008-11-16 13:02 --- *** Bug 38155 has been marked as a duplicate of this bug. *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||debian-gcc at lists dot ||debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37739
[Bug target/38155] [4.4 regression] gcc build failure on powerpc biarch
--- Comment #2 from jakub at gcc dot gnu dot org 2008-11-16 13:02 --- *** This bug has been marked as a duplicate of 37739 *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38155
[Bug fortran/38135] RESHAPE gives wrong result
--- Comment #5 from mikael at gcc dot gnu dot org 2008-11-16 13:45 --- Index: simplify.c === --- simplify.c (révision 141833) +++ simplify.c (copie de travail) @@ -3410,9 +3410,6 @@ is_constant_array_expr (gfc_expr *e) if (e->expr_type != EXPR_ARRAY || !gfc_is_constant_expr (e)) return false; - if (e->value.constructor == NULL) -return false; - for (c = e->value.constructor; c; c = c->next) if (c->expr->expr_type != EXPR_CONSTANT) return false; This solves (1) (the original testcase), but not (2). I will regtest it. for (2), I'm puzzled. :( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38135
[Bug c/38136] vim crashes on startup when compiled with -O3 but works with -O2
--- Comment #7 from dominique dot pelle at gmail dot com 2008-11-16 13:48 --- reading through the man page of gcc, I stumbled upon this in the section about -O2: == NOTE: In Ubuntu 8.10 and later versions, -D_FORTIFY_SOURCE=2 is set by default, and is activated when -O is set to 2 or higher. This enables additional compile-time and run-time checks for several libc functions. To disable, specify either -U_FORTIFY_SOURCE or -D_FORTIFY_SOURCE=0. == So I tried adding compiling with -O3 -D_FORTIFY_SOURCE=0 and it makes it work! So far I don't observe anything wrong with -O3 -D_FORTIFY_SOURCE=0. 'make test' succeeds in every tests. I'm not 100% sure whether adding -D_FORTIFY_SOURCE=0 silents a real bug in vim, or whether it was reporting a spurious error (hence bug in gcc). But even if it silents a spurious bug in this case, adding -D_FORTIFY_SOURCE=0 may also silent other real bugs, which is a shame. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38136
[Bug fortran/38135] RESHAPE gives wrong result
--- Comment #6 from tkoenig at gcc dot gnu dot org 2008-11-16 13:58 --- (In reply to comment #5) > > for (2), I'm puzzled. :( I'm onto it; the problems are in reshape.m4 / reshape_generic.c . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38135
[Bug c/38136] vim crashes on startup when compiled with -O3 but works with -O2
--- Comment #8 from dominique dot pelle at gmail dot com 2008-11-16 14:06
---
I should add that building with -O3 -D_FORTIFY_SOURCE=1 also
works which is better.
Reading about _FORTIFY_SOURCE in the following link, everything
makes sense now.
Snippet from http://mail-index.netbsd.org/tech-userlevel/2007/05/23/0001.html
===
The difference between -D_FORTIFY_SOURCE=1 and -D_FORTIFY_SOURCE=2
is e.g. for
struct S { struct T { char buf[5]; int x; } t; char buf[20]; } var;
With -D_FORTIFY_SOURCE=1,
strcpy (&var.t.buf[1], "abcdefg");
is not considered an overflow (object is whole VAR), while
with -D_FORTIFY_SOURCE=2
strcpy (&var.t.buf[1], "abcdefg");
will be considered a buffer overflow.
===
This example is very close to what vim does. So it makes sense
that -D_FORTIFY_SOURCE=2 detects an overflow, while
-D_FORTIFY_SOURCE=1 does not.
It thus OK to keep the bug as RESOLVED INVALID.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38136
[Bug target/38120] missing space in x86 assembly code for some mov instructions
--- Comment #1 from ubizjak at gmail dot com 2008-11-16 14:16 --- Can you send us a patch? -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|translation |target Ever Confirmed|0 |1 GCC host triplet|x86_64-unknown-linux-gnu| GCC target triplet|x86_64-unknown-linux-gnu|x86-unknown-linux-gnu Last reconfirmed|-00-00 00:00:00 |2008-11-16 14:16:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38120
[Bug c/38157] New: -fconserve-stack enabled by default
At both O0 and O3 conserve-stack is enabled. "The compiler will attempt to use less stack space, even if that makes the program slower." Doesn't that contradict with -O2 and -O3? gcc_inst/bin/gcc -O0 -Q foo.c --help=optimizers |grep conserve-stack -fconserve-stack [enabled] gcc_inst/bin/gcc -O3 -Q foo.c --help=optimizers |grep conserve-stack -fconserve-stack [enabled] gcc_inst/bin/gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../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 Thread model: posix gcc version 4.4.0 20081116 (experimental) [trunk revision 141912] (GCC) -- Summary: -fconserve-stack enabled by default Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c 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=38157
[Bug fortran/38095] character ICE
--- Comment #16 from burnus at gcc dot gnu dot org 2008-11-16 14:21 --- Subject: Bug 38095 Author: burnus Date: Sun Nov 16 14:19:38 2008 New Revision: 141917 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141917 Log: 2008-11-16 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/38095 * trans-expr.c (gfc_map_intrinsic_function): Fix pointer access. 2008-11-16 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/38095 * gfortran.dg/char_length_13.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/char_length_13.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38095
[Bug fortran/38095] character ICE
--- Comment #17 from burnus at gcc dot gnu dot org 2008-11-16 14:21 --- FIXED on the trunk (4.4.0). Thanks for the report! -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38095
[Bug middle-end/38158] New: FAIL: gcc.c-torture/execute/pr38051.c execution
At all optimization levels, this new test fails: Executing on host: /home/dave/gcc-4.4/objdir/gcc/xgcc -B/home/dave/gcc-4.4/objdi r/gcc/ /home/dave/gcc-4.4/gcc/gcc/testsuite/gcc.c-torture/execute/pr38051.c -w -O0 -lm -o /home/dave/gcc-4.4/objdir/gcc/testsuite/gcc/pr38051.x0 (timeo ut = 300) PASS: gcc.c-torture/execute/pr38051.c compilation, -O0 Setting LD_LIBRARY_PATH to :/home/dave/gcc-4.4/objdir/gcc::/home/dave/gcc-4.4/ob jdir/gcc:/home/dave/gcc-4.4/objdir/hppa-linux/libstdc++-v3/.libs:/home/dave/gcc- 4.4/objdir/hppa-linux/libmudflap/.libs:/home/dave/gcc-4.4/objdir/hppa-linux/libs sp/.libs:/home/dave/gcc-4.4/objdir/hppa-linux/libgomp/.libs:/home/dave/gcc-4.4/o bjdir/./gcc:/home/dave/gcc-4.4/objdir/./prev-gcc FAIL: gcc.c-torture/execute/pr38051.c execution, -O0 -- Summary: FAIL: gcc.c-torture/execute/pr38051.c execution Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa-unknown-linux-gnu GCC host triplet: hppa-unknown-linux-gnu GCC target triplet: hppa-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38158
[Bug middle-end/38158] FAIL: gcc.c-torture/execute/pr38051.c execution
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-11-16 15:09 --- Only at -O0? If not probably because the testcase assumes sizeof (long) == sizeof (void *). -- 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=38158
[Bug middle-end/38158] FAIL: gcc.c-torture/execute/pr38051.c execution
--- Comment #2 from danglin at gcc dot gnu dot org 2008-11-16 15:10 --- Starting program: /home/dave/gcc-4.4/objdir/gcc/testsuite/gcc/pr38051.x0g Breakpoint 1, main () at /home/dave/gcc-4.4/gcc/gcc/testsuite/gcc.c-torture/execute/pr38051.c:202 202 __builtin_abort (); (gdb) p buf $3 = "\000\000\000\000\000\000\000\000\000\0017\202?UI\235??D?U\027\216?", '\0' (gdb) p buf2 $4 = '\0' , "\0017\202?UI??*m#qIj", '\0' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38158
[Bug middle-end/38158] FAIL: gcc.c-torture/execute/pr38051.c execution
--- Comment #3 from danglin at gcc dot gnu dot org 2008-11-16 15:12 --- No. It fails at all optimizations. sizeof (long) is the same as sizeof (void *) on the PA. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38158
[Bug fortran/38135] RESHAPE gives wrong result
--- Comment #7 from mikael at gcc dot gnu dot org 2008-11-16 15:22 --- (In reply to comment #6) > I'm onto it; the problems are in reshape.m4 / reshape_generic.c . > Ok, leaving it to you. According to my tests, sstride0 has suspicious values. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38135
[Bug testsuite/38151] tmpdir-gcc.dg-struct-layout-1/t028 failure at -m64 on i686-apple-darwin9
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2008-11-16 15:55 --- This failing testcase produces the following in gdb... gdb ./tmpdir-gcc-dg-struct-layout-1-t028-01.exe GNU gdb 6.3.50-20050815 (Apple version gdb-962) (Sat Jul 26 08:14:40 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 "i386-apple-darwin"...Reading symbols for shared libraries ... done (gdb) r Starting program: /sw/src/fink.build/gcc44-4.3.999-20081115/darwin_objdir/gcc/testsuite/gcc/tmpdir-gcc-dg-struct-layout-1-t028-01.exe warning: posix_spawn failed, trying execvp, error: 86 Reading symbols for shared libraries ++. done Program received signal SIGABRT, Aborted. 0x7fff83829ee6 in __kill () (gdb) bt #0 0x7fff83829ee6 in __kill () #1 0x7fff8389af4d in abort () #2 0x00010f6f in main () (gdb) Is there anything else I can provide to debug this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38151
[Bug fortran/38135] RESHAPE gives wrong result
--- Comment #8 from tkoenig at gcc dot gnu dot org 2008-11-16 16:03 --- Created an attachment (id=16700) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16700&action=view) Patch for the library part Well, here's a patch for the library part. Apparently, nobody ever paid much attention to the "pad" argument before (a few things were just plain wrong there). Mikael, you were right about sstride0, but that wasn't the only problem :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38135
[Bug libfortran/38097] I/O with blanks in exponent fails; blank="NULL", BN edit descriptor
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-11-16 16:13 --- Subject: Bug 38097 Author: jvdelisle Date: Sun Nov 16 16:12:16 2008 New Revision: 141919 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141919 Log: 2008-11-16 Jerry DeLisle <[EMAIL PROTECTED]> PR libfortran/38097 * io/read.c (read_f): Initialize exponent. Fix comment. Set loop conditions for BZ/BN. * io/unit.c (get_internal_unit): Initialize flags.blank. * io/transfer.c (data_transfer_init): Fix whitespace. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/read.c trunk/libgfortran/io/transfer.c trunk/libgfortran/io/unit.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38097
[Bug middle-end/37790] limits-fnargs.c takes very long time to compile at -O2
--- Comment #2 from vmakarov at redhat dot com 2008-11-16 16:14 --- I waited more than hour to compile it on 1.2Ghz itanium and canceled the compilation. The problem is in coalescing stack slots. The code was already rewritten for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37448 But it is not enough for limit-fnargs.c which has more 100K allocnos and practically the same number of final stack slots. So I rewrote it one more time. The compilation time was decreased to decent 120 sec and PR37448 has still practically the same compilation time as the current version of the code. I'll sent the patch today for approval. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37790
[Bug libfortran/38097] I/O with blanks in exponent fails; blank="NULL", BN edit descriptor
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-11-16 16:20 --- Subject: Bug 38097 Author: jvdelisle Date: Sun Nov 16 16:18:36 2008 New Revision: 141920 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141920 Log: 2008-11-16 Jerry DeLisle <[EMAIL PROTECTED]> PR libfortran/38097 * gfortran.dg/fmt_bz_bn.f: New test. Added: trunk/gcc/testsuite/gfortran.dg/fmt_bz_bn.f Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38097
[Bug libfortran/38097] I/O with blanks in exponent fails; blank="NULL", BN edit descriptor
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-11-16 16:22 --- Fixed on trunk -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38097
[Bug target/38159] New: [avr] ICE: gcc.c-torture/execute/pr38051.c compilation, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions
ICE on AVR target: gcc.c-torture/execute/pr38051.c compilation, -O3
-fomit-frame-pointer -funroll-all-loops -finline-functions
Executing on host: /usr/local/avrdev/gcc/build/gcc/xgcc
-B/usr/local/avrdev/gcc/build/gcc/
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/pr38051.c -w
-O3 -fomit-frame-pointer -funroll-all-loops -finline-functions
-DSTACK_SIZE=2048 -DNO_TRAMPOLINES -DSIGNAL_SUPPRESS -mmcu=atmega128
/root/dejagnuboards/exit.c -Wl,-u,vfprintf -lprintf_flt
-Wl,-Tbss=0x802000,--defsym=__heap_end=0x80 -lm -o
/usr/local/avrdev/gcc/build/gcc/testsuite/gcc/pr38051.x5(timeout = 300)
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/pr38051.c: In
function 'mymemcmp':
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/pr38051.c:189:
error: unable to find a register to spill in class 'POINTER_REGS'
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/pr38051.c:189:
error: this is the insn:
(insn 371 370 372 10
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/pr38051.c:63 (set
(reg/v:SI 397 [ a0 ])
(mem:SI (subreg:HI (reg/v:SI 413 [ srcp1 ]) 0) [2 S4 A8])) 12 {*movsi}
(nil))
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/pr38051.c:189:
internal compiler error: in spill_failure, at reload1.c:2093
Note that test is successful with:
PASS: gcc.c-torture/execute/pr38051.c execution, -O3 -fomit-frame-pointer
-funroll-loops
The only difference is the flag -finline-functions, which seems to trigger the
bug.
--
Summary: [avr] ICE: gcc.c-torture/execute/pr38051.c compilation,
-O3 -fomit-frame-pointer -funroll-all-loops -finline-
functions
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eric dot weddington at atmel dot com
GCC target triplet: avr-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38159
[Bug fortran/38160] New: C Binding: Kind parameter checking too strict and too late
Found in the README to http://www.lrz-muenchen.de/services/software/mathematik/gsl/fortran/ gfortran is quite picky with regards to the C binding type, i.e. it does not like use iso_c_binding complex(c_double),target :: z ! correct would be: c_double_complex however it is not failing right a way, but it is only failing when using C_LOC: type(c_ptr) :: ptr ptr = c_loc(z) Error: C kind parameter is for type REAL but symbol 'z' at (1) is of type COMPLEX ISSUES: a) The error should already printed for the declaration and not for C_LOC() (The same checking is also done for the dummy arguments of BIND(C) procedures.) b) The question is whether one needs an error or whether a warning is enough (For completeness, the author did not reply to my request to change the code of FGLS.) -- Summary: C Binding: Kind parameter checking too strict and too late Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran 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=38160
[Bug fortran/38135] RESHAPE gives wrong result
--- Comment #9 from mikael at gcc dot gnu dot org 2008-11-16 18:46 ---
(In reply to comment #8)
Are you sure this is needed ?
if (sempty)
{
- /* Switch immediately to the pad array. */
+ /* Pretend we are using the pad array the first time around, too. */
src = pptr;
- sptr = NULL;
+ sptr = pptr;
sdim = pdim;
for (dim = 0; dim < pdim; dim++)
sptr is only used later to switch from source to pad, which is not needed here
as we start with pad directly. No?
> Mikael, you were right about sstride0, but that wasn't the only problem :-)
While we are at it, we could calculate sstride0 outside the loop, that would be
5ns faster ;-).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38135
[Bug fortran/38152] ICE for procedure pointer assignment
--- Comment #2 from janus at gcc dot gnu dot org 2008-11-16 18:59 ---
(In reply to comment #1)
> By the way, the following also fails:
>
> module m
> procedure(), pointer :: procptr
> end module m
>
> use m
> external foo
> procptr => foo
> end
>
> with Error: 'procptr' in the pointer assignment at (1) cannot be an
> l-value since it is a procedure
>
> I think the "proc_ptr" attribute is not properly saved in the .mod file.
Actually this is not the problem. All attributes are saved properly.
The error is fixed by the following trivial patch:
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c (revision 141915)
+++ gcc/fortran/expr.c (working copy)
@@ -3034,7 +3034,8 @@ gfc_check_pointer_assign (gfc_expr *lval
}
if (lvalue->symtree->n.sym->attr.flavor == FL_PROCEDURE
- && lvalue->symtree->n.sym->attr.use_assoc)
+ && lvalue->symtree->n.sym->attr.use_assoc
+ && !lvalue->symtree->n.sym->attr.proc_pointer)
{
gfc_error ("'%s' in the pointer assignment at %L cannot be an "
"l-value since it is a procedure",
--
janus 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-16 18:59:41
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38152
[Bug fortran/38160] C Binding: Kind parameter checking too strict and too late
--- Comment #1 from kargl at gcc dot gnu dot org 2008-11-16 19:08 --- Here's the testcase from Tobias on IRC use iso_c_binding complex(c_double), target :: z type(c_ptr) :: ptr ptr = c_loc(z) end Note, the standard says that c_double and c_double_complex are the same value, so the error message might be relaxed to a warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38160
[Bug libstdc++/37144] A bug in include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp
--- Comment #7 from danglin at gcc dot gnu dot org 2008-11-16 19:17 --- I am not convinced that PR 38128 is a duplicate of this bug. The test doesn't fail if I disable the use of CFI directives on hppa-unknown-linux-gnu. In debugging, there also seems to be an exception in the eh code causing a loop. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37144
[Bug libstdc++/37144] A bug in include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp
--- Comment #8 from hjl dot tools at gmail dot com 2008-11-16 19:21 --- (In reply to comment #7) > I am not convinced that PR 38128 is a duplicate of this bug. The test > doesn't fail if I disable the use of CFI directives on hppa-unknown-linux-gnu. > In debugging, there also seems to be an exception in the eh code causing a > loop. > ext/pb_ds/regression/trie_data_map_rand.cc fails on Linux/Intel64 at random. Can you disable the use of CFI directives and add -D_GLIBCXX_DEBUG to run it on hppa-unknown-linux-gnu by hand? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37144
[Bug fortran/38135] RESHAPE gives wrong result
--- Comment #10 from mikael at gcc dot gnu dot org 2008-11-16 19:44 --- (In reply to comment #9) Those are only details, it works nicely :-). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38135
[Bug middle-end/37790] limits-fnargs.c takes very long time to compile at -O2
--- Comment #3 from hjl at gcc dot gnu dot org 2008-11-16 19:49 --- Subject: Bug 37790 Author: hjl Date: Sun Nov 16 19:47:40 2008 New Revision: 141924 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141924 Log: 2008-11-16 Vladimir Makarov <[EMAIL PROTECTED]> PR bootstrap/37790 * ira-int.h (ira_copy_allocno_live_range_list, ira_merge_allocno_live_ranges, ira_allocno_live_ranges_intersect_p, ira_finish_allocno_live_range_list): New prototypes. (ira_allocno_live_ranges_intersect_p, ira_pseudo_live_ranges_intersect_p): Remove. * ira-conflicts.c (ira_allocno_live_ranges_intersect_p, ira_pseudo_live_ranges_intersect_p): Rename to allocnos_have_intersected_live_ranges_p and pseudos_have_intersected_live_ranges_p. Move them from here to ... * ira-color.c: ... here (coalesced_allocno_conflict_p): Use allocnos_have_intersected_live_ranges_p. (coalesced_allocnos_living_at_program_points, coalesced_allocnos_live_at_points_p, set_coalesced_allocnos_live_points): Remove. (slot_coalesced_allocnos_live_ranges, slot_coalesced_allocno_live_ranges_intersect_p, setup_slot_coalesced_allocno_live_ranges): New. (coalesce_spill_slots): Use ranges of coalesced allocnos. (ira_sort_regnos_for_alter_reg): Use allocnos_have_intersected_live_ranges_p. (ira_reuse_stack_slot): Use pseudos_have_intersected_live_ranges_p. * global.c (pseudo_for_reload_consideration_p): Check flag_ira_share_spill_slots too. * ira-build.c (copy_allocno_live_range_list): Rename to ira_copy_allocno_live_range_list. Make it external. (merge_ranges): Rename to ira_merge_allocno_live_ranges. Make it external. (ira_allocno_live_ranges_intersect_p): New. (ira_finish_allocno_live_range_list): New. (finish_allocno): Use it. (remove_unnecessary_allocnos): Use ira_merge_allocno_live_ranges. (copy_info_to_removed_store_destinations): Ditto. Use ira_copy_allocno_live_range_list. (ira_flattening): Use ira_merge_allocno_live_ranges. * ira.c (too_high_register_pressure_p): New function. (ira): Switch off sharing spill slots if the pressure is too high. Modified: branches/ira-merge/gcc/ChangeLog.ira branches/ira-merge/gcc/global.c branches/ira-merge/gcc/ira-build.c branches/ira-merge/gcc/ira-color.c branches/ira-merge/gcc/ira-conflicts.c branches/ira-merge/gcc/ira-int.h branches/ira-merge/gcc/ira.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37790
[Bug target/38052] [4.4 Regression] genautomata segfaults when -O2 is enabled
--- Comment #8 from rsandifo at gcc dot gnu dot org 2008-11-16 20:27 --- Subject: Bug 38052 Author: rsandifo Date: Sun Nov 16 20:25:40 2008 New Revision: 141925 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141925 Log: gcc/ PR target/38052 * config/mips/mips.c (machine_function): Update the comment above global_pointer. (mips_global_pointer): Use INVALID_REGNUM rather than 0 to indicate that a function doesn't need a global pointer. (mips_current_loadgp_style): Update accordingly. (mips_restore_gp): Likewise. (mips_output_cplocal): Likewise. (mips_expand_prologue): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/mips/mips.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38052
[Bug testsuite/38151] tmpdir-gcc.dg-struct-layout-1/t028 failure at -m64 on i686-apple-darwin9
--- Comment #9 from ubizjak at gmail dot com 2008-11-16 20:28 ---
(In reply to comment #8)
> This failing testcase produces the following in gdb...
> #0 0x7fff83829ee6 in __kill ()
> #1 0x7fff8389af4d in abort ()
> #2 0x00010f6f in main ()
> (gdb)
>
> Is there anything else I can provide to debug this?
Yes: compile all three testfiles with -g flag added, put a watchpoint on
"fails" variable (watch fails) and see where it triggers.
It looks to me that something is wrong with s2848 argument that is passed to
check2848 function. At calling site (in test2848 function), we have:
(gdb) print s2848
$10 = {a = 4027477739, b = -936922831153888968, c = 0x601720}
and in check2848 we receive:
(gdb) print arg0
$11 = {a = 4195077, b = 3221252723567493120, c = 0x7fffde0e11a0}
The structure is defined as:
struct S2848
{
unsigned int a;
_Complex int __attribute__ ((aligned (1))) b;
struct
{
} __attribute__ ((packed, aligned)) c[1];
};
Hm, looks like a real bug to me.
This also fails on linux, I'll try to create a testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38151
[Bug target/38052] [4.4 Regression] genautomata segfaults when -O2 is enabled
--- Comment #9 from rsandifo at gcc dot gnu dot org 2008-11-16 20:32 --- Subject: Bug 38052 Author: rsandifo Date: Sun Nov 16 20:31:13 2008 New Revision: 141926 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141926 Log: gcc/ PR target/38052 * config/mips/mips.c (mips_cfun_call_saved_reg_p) (mips_cfun_might_clobber_call_saved_reg_p): New functions, split out from... (mips_save_reg_p): ...here. Always consult TARGET_CALL_SAVED_GP rather than call_really_used_regs when handling $gp. Modified: trunk/gcc/ChangeLog trunk/gcc/config/mips/mips.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38052
[Bug fortran/38135] RESHAPE gives wrong result
--- Comment #11 from tkoenig at gcc dot gnu dot org 2008-11-16 20:38 --- Regression-test and full patch, including test cases, tomorrow. RL keeps interfering :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38135
[Bug fortran/37992] ICE while resolving charlen for rejected statements
--- Comment #10 from mikael at gcc dot gnu dot org 2008-11-16 20:45 --- Subject: Bug 37992 Author: mikael Date: Sun Nov 16 20:44:33 2008 New Revision: 141927 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141927 Log: 2008-11-16 Mikael Morin <[EMAIL PROTECTED]> PR fortran/37992 * gfortran.h (gfc_namespace): Added member old_cl_list, backup of cl_list. (gfc_free_charlen): Added prototype. * symbol.c (gfc_free_charlen): New function. (gfc_free_namespace): Use gfc_free_charlen. * parse.c (next_statement): Backup gfc_current_ns->cl_list. (reject_statement): Restore gfc_current_ns->cl_list. Free cl_list's elements before dropping them. 2008-11-16 Mikael Morin <[EMAIL PROTECTED]> PR fortran/37992 * gfotran.dg/charlen_free_1.f90: New test. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/parse.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37992
[Bug testsuite/38151] structures with _Complex arguments are not passed correctly
--- Comment #10 from ubizjak at gmail dot com 2008-11-16 20:58 ---
Real bug with argument passing. Confirmed on x86_64-linux-gnu with the
testcase:
--cut here--
struct S2848
{
unsigned int a;
_Complex int b;
};
struct S2848 s2848;
void __attribute__((noinline))
check2848 (struct S2848 arg0)
{
if (arg0.b != s2848.b)
abort ();
}
int main()
{
s2848.a = 4027477739U;
s2848.b = (723419448 + -218144346 * __extension__ 1i);
check2848 (s2848);
return 0;
}
--cut here--
> gcc -O2 t.c
> ./a.out
Aborted
--
ubizjak at gmail dot com changed:
What|Removed |Added
CC||hjl at gcc dot gnu dot org,
||hubicka at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC host triplet|i686-apple-darwin9 |
GCC target triplet|i686-apple-darwin9 |x86_64
Keywords||ABI, wrong-code
Known to fail||4.3.0 4.4.0
Last reconfirmed|-00-00 00:00:00 |2008-11-16 20:58:10
date||
Summary|tmpdir-gcc.dg-struct-layout-|structures with _Complex
|1/t028 failure at -m64 on |arguments are not passed
|i686-apple-darwin9 |correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38151
[Bug fortran/37992] ICE while resolving charlen for rejected statements
--- Comment #11 from mikael at gcc dot gnu dot org 2008-11-16 21:05 --- Fixed on trunk, closing (In reply to comment #9) > Note also that there are other similar instances for which gfortran gives an > ICE after error messages and that are not fixed by the patch, see: Those are ice-on-invalid-after-reporting-an-error. They are quite low in the priority list (after wrong-code, ice-on-valid, ice-on-invalid) and not for trunk at this stage unless a trivial/obvious fix is found for them. -- mikael at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37992
[Bug target/38052] [4.4 Regression] genautomata segfaults when -O2 is enabled
--- Comment #10 from rsandifo at gcc dot gnu dot org 2008-11-16 21:08 --- Fixed on mainline. -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38052
[Bug testsuite/38151] structures with _Complex arguments are not passed correctly
--- Comment #11 from ubizjak at gmail dot com 2008-11-16 21:09 ---
Also fails in return from function:
--cut here--
struct S2848
{
unsigned int a;
_Complex int b;
};
struct S2848 s2848;
struct S2848 __attribute__((noinline))
check2848 (struct S2848 arg0)
{
s2848.a = 4027477739U;
s2848.b = (723419448 + -218144346 * __extension__ 1i);
return s2848;
}
int main()
{
struct S2848 ret;
ret = check2848 (s2848);
if (ret.b != s2848.b)
abort ();
return 0;
}
--cut here--
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38151
[Bug preprocessor/38161] New: #elif breaks
#ifndef FOO
#define FOO sizeof(void *)
#elif FOO
#endif
t.c:3:7: error: missing binary operator before token "("
I expect it's caused by the fix to bug #36320.
--
Summary: #elif breaks
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: h dot b dot furuseth at usit dot uio dot no
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=38161
[Bug fortran/38135] RESHAPE gives wrong result
--- Comment #12 from pault at gcc dot gnu dot org 2008-11-16 22:25 --- Thomas, Since you are there, bar the shouting, I thought that I would assign you:-) Cheers and thanks Paul -- pault 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|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38135
[Bug target/38159] [avr] ICE: gcc.c-torture/execute/pr38051.c compilation, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-11-16 22:26 --- What's sizeof (void *) and sizeof (long) for avr? -- 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=38159
[Bug libgcj/38162] New: [4.4 Regression] FAIL: gctest
On Linux/Intel64, revision 141928 gave
make[8]: Entering directory
`/export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/boehm-gc'
Switched to incremental mode
Emulating dirty bits with mprotect/signals
Lost a node at level 7 - collector is broken
Test failed
/bin/sh: line 4: 26509 Aborted LD_LIBRARY_PATH=../../gcc
${dir}$tst
FAIL: gctest
===
1 of 1 tests failed
===
make[8]: *** [check-TESTS] Error 1
Revision 141923 is OK.
--
Summary: [4.4 Regression] FAIL: gctest
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38162
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #19 from mikael at gcc dot gnu dot org 2008-11-16 22:46 --- Subject: Bug 35681 Author: mikael Date: Sun Nov 16 22:45:10 2008 New Revision: 141931 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141931 Log: 2008-11-16 Mikael Morin <[EMAIL PROTECTED]> PR fortran/35681 * dependency.c (gfc_check_argument_var_dependency): Add elemental check flag. Issue a warning if we find a dependency but don't generate a temporary. Add the case of an elemental function call as actual argument to an elemental procedure. Add the case of an operator expression as actual argument to an elemental procedure. (gfc_check_argument_dependency): Add elemental check flag. Update calls to gfc_check_argument_var_dependency. (gfc_check_fncall_dependency): Add elemental check flag. Update call to gfc_check_argument_dependency. * trans-stmt.c (gfc_trans_call): Make call to gfc_conv_elemental_dependency unconditional, but with a flag whether we should check dependencies between variables. (gfc_conv_elemental_dependency): Add elemental check flag. Update call to gfc_check_fncall_dependency. * trans-expr.c (gfc_trans_arrayfunc_assign): Update call to gfc_check_fncall_dependency. * resolve.c (find_noncopying_intrinsics): Update call to gfc_check_fncall_dependency. * dependency.h (enum gfc_dep_check): New enum. (gfc_check_fncall_dependency): Update prototype. 2008-11-16 Mikael Morin <[EMAIL PROTECTED]> PR fortran/35681 * gfortran.dg/elemental_dependency_1.f90: New test. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dependency.c trunk/gcc/fortran/dependency.h trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/38152] ICE for procedure pointer assignment
--- Comment #3 from burnus at gcc dot gnu dot org 2008-11-17 00:01 ---
(In reply to comment #2)
> > By the way, the following also fails:
> The error is fixed by the following trivial patch:
Janus, do you plan to submit it?
* * *
Regarding the ICE, the following patch seems to work; one probably still needs
to take care of mangling of the name etc. Also there needs to be a check for
use-/host- association (cf. a few lines down and in gfc_finish_var_decl),
adding those flags unconditionally is surely wrong.
--- trans-decl.c(revision 141928)
+++ trans-decl.c(working copy)
@@ -1021,2 +1021,7 @@ gfc_get_symbol_decl (gfc_symbol * sym)
decl = gfc_get_extern_function_decl (sym);
+ if (sym->attr.proc_pointer)
+ {
+ TREE_PUBLIC (decl) = 1;
+ TREE_STATIC (decl) = 1;
+}
return decl;
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38152
[Bug target/38159] [avr] ICE: gcc.c-torture/execute/pr38051.c compilation, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions
--- Comment #2 from eric dot weddington at atmel dot com 2008-11-17 00:15 --- (In reply to comment #1) > What's sizeof (void *) and sizeof (long) for avr? > char: 8-bit int/short: 16-bit pointer: 16-bit long: 32-bit long long: 64-bit -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38159
[Bug testsuite/38163] New: gcc.dg/tree-ssa/loop-3.c failure at -m64 on i686-apple-darwin9
The gcc.dg/tree-ssa/loop-3.c test case fails at -m64 on i686-apple-darwin9 with the failure... Executing on host: /sw/src/fink.build/gcc44-4.3.999-20081116/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc44-4.3.999-20081116/darwin_objdir/gcc/ /sw/src/fink.build/gcc44-4.3.999-20081116/gcc-4.4-20081116/gcc/testsuite/gcc.dg/tree-ssa/loop-3.c -O1 -fno-pic -fno-PIC -fdump-tree-optimized -S -m64 -o loop-3.s(timeout = 300) PASS: gcc.dg/tree-ssa/loop-3.c (test for excess errors) PASS: gcc.dg/tree-ssa/loop-3.c scan-tree-dump-times optimized "MEM" 1 FAIL: gcc.dg/tree-ssa/loop-3.c scan-tree-dump-times optimized "step:" 1 PASS: gcc.dg/tree-ssa/loop-3.c scan-tree-dump-times optimized "int iter" 1 -- Summary: gcc.dg/tree-ssa/loop-3.c failure at -m64 on i686-apple- darwin9 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite 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=38163
[Bug testsuite/38163] gcc.dg/tree-ssa/loop-3.c failure at -m64 on i686-apple-darwin9
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2008-11-17 00:25 --- Created an attachment (id=16701) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16701&action=view) assembly file for gcc.dg/tree-ssa/loop-3.c at -m64 on i686-apple-darwin9 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38163
[Bug testsuite/38163] gcc.dg/tree-ssa/loop-3.c failure at -m64 on i686-apple-darwin9
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2008-11-17 00:25 --- Created an attachment (id=16702) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16702&action=view) 123t.optimized file for gcc.dg/tree-ssa/loop-3.c at -m64 on i686-apple-darwin9 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38163
[Bug testsuite/38164] New: gcc.target/i386/amd64-abi-3.c fails at -m64 on i686-apple-darwin9
The gcc.target/i386/amd64-abi-3.c test case fails at -m64 on i686-apple-darwin9 as follows... Executing on host: /sw/src/fink.build/gcc44-4.3.999-20081116/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc44-4.3.999-20081116/darwin_objdir/gcc/ /sw/src/fink.build/gcc44-4.3.999-20081116/gcc-4.4-20081116/gcc/testsuite/gcc.target/i386/amd64-abi-3.c -O2 -mno-sse -S -m64 -o amd64-abi-3.s(timeout = 300) PASS: gcc.target/i386/amd64-abi-3.c (test for excess errors) FAIL: gcc.target/i386/amd64-abi-3.c scan-assembler subq[\\t ]*\\$88,[\\t ]*%rsp PASS: gcc.target/i386/amd64-abi-3.c scan-assembler-not subq[\\t ]*\\$216,[\\t ]*%rsp -- Summary: gcc.target/i386/amd64-abi-3.c fails at -m64 on i686- apple-darwin9 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite 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=38164
[Bug testsuite/38164] gcc.target/i386/amd64-abi-3.c fails at -m64 on i686-apple-darwin9
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2008-11-17 00:30 --- Created an attachment (id=16703) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16703&action=view) assembly file for gcc.target/i386/amd64-abi-3.c at -m64 on i686-apple-darwin9 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38164
[Bug target/34256] mmx and movd/movq on x86_64
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2008-11-17 00:34 --- The gcc.target/i386/pr34256.c test case is still failing as... Executing on host: /sw/src/fink.build/gcc44-4.3.999-20081116/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc44-4.3.999-20081116/darwin_objdir/gcc/ /sw/src/fink.build/gcc44-4.3.999-20081116/gcc-4.4-20081116/gcc/testsuite/gcc.target/i386/pr34256.c -O2 -fomit-frame-pointer -march=core2 -S -m64 -o pr34256.s(timeout = 300) PASS: gcc.target/i386/pr34256.c (test for excess errors) FAIL: gcc.target/i386/pr34256.c scan-assembler-times mov 4 UNSUPPORTED: gcc.target/i386/pr34312.c UNSUPPORTED: gcc.target/i386/pr34522.c UNSUPPORTED: gcc.target/i386/pr35083.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34256
[Bug target/34256] mmx and movd/movq on x86_64
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2008-11-17 00:37 --- Created an attachment (id=16704) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16704&action=view) assembly file for gcc.target/i386/pr34256.c at -m64 on i686-apple-darwin9 with -fomit-frame-pointer -- howarth at nitro dot med dot uc dot edu changed: What|Removed |Added Attachment #16691|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34256
[Bug testsuite/38165] New: g++.dg/pubtypes.C fails at -m32/-m64 on i686-apple-darwin9
The g++.dg/pubtypes.C test case fails at both -m32 and -m64 on i686-apple-darwin9. The appears as... Executing on host: /sw/src/fink.build/gcc44-4.3.999-20081116/darwin_objdir/gcc/testsuite/g++/../../g++ -B/sw/src/fink.build/gcc44-4.3.999-20081116/darwin_objdir/gcc/testsuite/g++/../../ /sw/src/fink.build/gcc44-4.3.999-20081116/gcc-4.4-20081116/gcc/testsuite/g++.dg/pubtypes.C -nostdinc++ -I/sw/src/fink.build/gcc44-4.3.999-20081116/darwin_objdir/i686-apple-darwin10/libstdc++-v3/include/i686-apple-darwin10 -I/sw/src/fink.build/gcc44-4.3.999-20081116/darwin_objdir/i686-apple-darwin10/libstdc++-v3/include -I/sw/src/fink.build/gcc44-4.3.999-20081116/gcc-4.4-20081116/libstdc++-v3/libsupc++ -I/sw/src/fink.build/gcc44-4.3.999-20081116/gcc-4.4-20081116/libstdc++-v3/include/backward -I/sw/src/fink.build/gcc44-4.3.999-20081116/gcc-4.4-20081116/libstdc++-v3/testsuite/util -fmessage-length=0 -O0 -gdwarf-2 -dA -fno-eliminate-unused-debug-types -S -m32 -o pubtypes.s(timeout = 300) PASS: g++.dg/pubtypes.C (test for excess errors) PASS: g++.dg/pubtypes.C scan-assembler __debug_pubtypes FAIL: g++.dg/pubtypes.C scan-assembler long+[ \t]+0x24+[ \t]+[#;]+[ \t]+Length of Public Type Names Info PASS: g++.dg/pubtypes.C scan-assembler "empty0"+[ \t]+[#;]+[ \t]+external name PASS: g++.dg/pubtypes.C scan-assembler "A0"+[ \t]+[#;]+[ \t]+external name PASS: g++.dg/pubtypes.C scan-assembler "B0"+[ \t]+[#;]+[ \t]+external name -- Summary: g++.dg/pubtypes.C fails at -m32/-m64 on i686-apple- darwin9 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite 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=38165
[Bug testsuite/38165] g++.dg/pubtypes.C fails at -m32/-m64 on i686-apple-darwin9
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2008-11-17 00:51 --- Created an attachment (id=16705) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16705&action=view) assembly file for g++.dg/pubtypes.C at -m32 on i686-apple-darwin9 with -fomit-frame-pointer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38165
[Bug testsuite/38165] g++.dg/pubtypes.C fails at -m32/-m64 on i686-apple-darwin9
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2008-11-17 00:53 --- typo in original attachment description. It wasn't generated with -fomit-frame-pointer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38165
[Bug testsuite/38166] New: g++.dg/ext/visibility/class1.C fails at -m64 on i686-apple-darwin9
The g++.dg/ext/visibility/class1.C test case fails at -m64 on i686-apple-darwin9 as follows... Executing on host: /sw/src/fink.build/gcc44-4.3.999-20081116/darwin_objdir/gcc/testsuite/g++/../../g++ -B/sw/src/fink.build/gcc44-4.3.999-20081116/darwin_objdir/gcc/testsuite/g++/../../ /sw/src/fink.build/gcc44-4.3.999-20081116/gcc-4.4-20081116/gcc/testsuite/g++.dg/ext/visibility/class1.C -nostdinc++ -I/sw/src/fink.build/gcc44-4.3.999-20081116/darwin_objdir/i686-apple-darwin10/x86_64/libstdc++-v3/include/i686-apple-darwin10 -I/sw/src/fink.build/gcc44-4.3.999-20081116/darwin_objdir/i686-apple-darwin10/x86_64/libstdc++-v3/include -I/sw/src/fink.build/gcc44-4.3.999-20081116/gcc-4.4-20081116/libstdc++-v3/libsupc++ -I/sw/src/fink.build/gcc44-4.3.999-20081116/gcc-4.4-20081116/libstdc++-v3/include/backward -I/sw/src/fink.build/gcc44-4.3.999-20081116/gcc-4.4-20081116/libstdc++-v3/testsuite/util -fmessage-length=0 -fpic -S -m64 -o class1.s(timeout = 300) PASS: g++.dg/ext/visibility/class1.C (test for excess errors) FAIL: g++.dg/ext/visibility/class1.C scan-assembler [EMAIL PROTECTED]|indirect_symbol.*InitEv -- Summary: g++.dg/ext/visibility/class1.C fails at -m64 on i686- apple-darwin9 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite 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=38166
[Bug testsuite/38166] g++.dg/ext/visibility/class1.C fails at -m64 on i686-apple-darwin9
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2008-11-17 01:02 --- Created an attachment (id=16706) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16706&action=view) assembly file for g++.dg/ext/visibility/class1.C at -m64 on i686-apple-darwin9 with -fomit-frame-pointer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38166
[Bug c/38167] New: Inline accessor to stdin is breaks on -O2 optimization
It appears that the following inline accessor function to stdin doesn't do it's
job if -O2 optimization is turned on, thus letting a null pointer pass and
causing a segfault. This doesn't happen if the function is not declared inline.
Version: gcc (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu3)
Command line: gcc -O2 -o fault fault.c
GNU libc 2.7 is known for its non-constant stdin and is probably required to
actually get a segfault.
Code in readable format:
#include
struct iostream {
FILE *f;
};
static struct iostream our_stdin = { 0 };
inline void access_iostream(struct iostream* ios)
{
if (ios->f == 0)
if (ios == &our_stdin)
ios->f = stdin;
}
void read_char(struct iostream* ios)
{
access_iostream(ios);
fgetc(ios->f);
}
int main()
{
read_char(&our_stdin);
return 0;
}
--
Summary: Inline accessor to stdin is breaks on -O2 optimization
Product: gcc
Version: 4.2.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aleksi dot nurmi at helsinki dot fi
GCC host triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38167
[Bug c/38167] Inline accessor to stdin is breaks on -O2 optimization
--- Comment #1 from aleksi dot nurmi at helsinki dot fi 2008-11-17 02:01 --- Created an attachment (id=16707) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16707&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38167
[Bug rtl-optimization/32283] [4.3/4.4 regression] Missed induction variable optimization
--- Comment #22 from rakdver at gcc dot gnu dot org 2008-11-17 03:44 --- (In reply to comment #20) > To add to comment #18, after r128272 GCC for powerpc-linux no longer generates > bdnz for: > ... A patch for this testcase: http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00792.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32283
[Bug fortran/37472] bad output on default-format write of double in common block with -m64 flag i
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2008-11-17 05:03 --- The shifting of the decimal point between 1000. and 1001. is an artefact of how we compute the format specifiers in the OUTPUT_FLOAT macro in write_float.def. I am working on a solution to that part of this. The issue with the doubles in common I suspect is some sort of alignment issue, but I do not see it here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37472
[Bug rtl-optimization/36365] [4.3/4.4 Regression] Hang in df_analyze
--- Comment #10 from spark at gcc dot gnu dot org 2008-11-17 06:13 --- I agree that the overeager has the worse worst-case bound. I'll happily approve a patch that drops overeager and leave double-queuing only, provided we have empirical data over some known programs to show that it is a compile time neutral change (I bet it will be so, or worst case, only a very slight slowdown). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36365
[Bug c++/36089] [4.2/4.3/4.4 Regression] Funny rejects valid with constant integral expression
--- Comment #6 from jakub at gcc dot gnu dot org 2008-11-17 07:57 --- Subject: Bug 36089 Author: jakub Date: Mon Nov 17 07:55:52 2008 New Revision: 141941 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141941 Log: PR c++/36089 * init.c (constant_value_1): Handle TREE_LIST init. * g++.dg/template/init8.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/init8.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/init.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36089
