[Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
--- Comment #11 from jv244 at cam dot ac dot uk 2009-05-04 07:49 ---
I have a gdb session open, but I'm rather clueless. I have this:
(gdb) print (*x).generic.type
$5 = {common = {base = {code = RECORD_TYPE, side_effects_flag = 0,
constant_flag = 0, addressable_flag = 0, volatile_flag = 0,
readonly_flag = 0, unsigned_flag = 0, asm_written_flag = 0,
nowarning_flag = 0, used_flag = 0, nothrow_flag = 0,
static_flag = 0, public_flag = 0, private_flag = 0, protected_flag = 0,
deprecated_flag = 0, saturating_flag = 0,
default_def_flag = 0, lang_flag_0 = 0, lang_flag_1 = 0, lang_flag_2 = 0,
lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0,
lang_flag_6 = 0, visited = 0, spare = 0, ann = 0x0}, chain = 0x0, type =
0x0}, values = 0x7f94536c6780, size = 0x7f9453fada80,
size_unit = 0x7f9453e43cc0, attributes = 0x0, uid = 769447, precision = 0,
mode = BLKmode, string_flag = 0, no_force_blk_flag = 0,
needs_constructing_flag = 0, transparent_union_flag = 0, packed_flag = 0,
restrict_flag = 0, contains_placeholder_bits = 0,
lang_flag_0 = 0, lang_flag_1 = 1, lang_flag_2 = 0, lang_flag_3 = 0,
lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6 = 0,
user_align = 0, align = 64, alias_set = -1, pointer_to = 0x0, reference_to =
0x0, symtab = {address = 0, pointer = 0x0, die = 0x0},
name = 0x7f9452151150, minval = 0x0, maxval = 0x0, next_variant =
0x7f941d7c60c0, main_variant = 0x7f9453d66e40, binfo = 0x0,
context = 0x0, canonical = 0x7f9453d66e40, lang_specific = 0x7f941d7c7600}
but the following fails:
(gdb) call debug_tree((*x).generic.type.next_variant)
Cannot access memory at address 0x7fff5d302f78
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
[Bug middle-end/37951] -ftree-parallelize-loops=2 fails for MA57
--- Comment #10 from dennis dot wassel at googlemail dot com 2009-05-04 08:50 --- Edited the "Known to fail" instead of "Reported against". -- dennis dot wassel at googlemail dot com changed: What|Removed |Added Known to fail||4.3.2 4.3.3 Version|4.3.3 |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37951
[Bug middle-end/37951] -ftree-parallelize-loops=2 fails for MA57
--- Comment #9 from dennis dot wassel at googlemail dot com 2009-05-04 08:45 --- Also fails with 4.3.3 (precisely the same error message as 4.3.2) gfortran -O2 -ftree-parallelize-loops=2 -c ma57.f -o ma57.o ma57.f: In function 'ma57od': ma57.f:2724: error: edge from 676 to 686 should be marked irreducible ma57.f:2724: error: basic block 686 should be marked irreducible ma57.f:2724: error: edge from 686 to 679 should be marked irreducible ma57.f:2724: error: basic block 679 should be marked irreducible ma57.f:2724: error: edge from 679 to 124 should be marked irreducible ma57.f:2724: confused by earlier errors, bailing out Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.3.3/configure --prefix=/localdata --program-suffix=-4.3.3 --enable-languages=c,c++,fortran --with-gmp=/localdata --with-mpfr=/localdata --enable-version-specific-runtime-libs Thread model: posix gcc version 4.3.3 (GCC) COLLECT_GCC_OPTIONS='-v' '-O2' '-ftree-parallelize-loops=2' '-c' '-o' 'ma57.o' '-mtune=generic' '-pthread' /localdata/libexec/gcc/i686-pc-linux-gnu/4.3.3/f951 ma57.f -ffixed-form -quiet -dumpbase ma57.f -mtune=generic -auxbase-strip ma57.o -O2 -version -ftree-parallelize-loops=2 -fintrinsic-modules-path /localdata/lib/gcc/i686-pc-linux-gnu/4.3.3/finclude -o /tmp/ccHYlhlQ.s GNU F95 (GCC) version 4.3.3 (i686-pc-linux-gnu) compiled by GNU C version 4.3.3, GMP version 4.3, MPFR version 2.4.1-p5. warning: GMP header version 4.3 differs from library version 4.3.0. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Is anyone interested in fixing this? I think it would not infringe the spirit of license agreement, if I provided someone off-list with the source _for debugging purposes only_. -- dennis dot wassel at googlemail dot com changed: What|Removed |Added CC||dennis dot wassel at ||googlemail dot com Version|4.3.2 |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37951
[Bug fortran/37744] ICE-on-invalid with ISO_C_BINDING and TYPEs
--- Comment #3 from dennis dot wassel at googlemail dot com 2009-05-04 08:55 --- Also fails with 4.3.3: gfortran -v pr37744.f90 Driving: gfortran -v pr37744.f90 -lgfortranbegin -lgfortran -lm -shared-libgcc Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.3.3/configure --prefix=/localdata --program-suffix=-4.3.3 --enable-languages=c,c++,fortran --with-gmp=/localdata --with-mpfr=/localdata --enable-version-specific-runtime-libs Thread model: posix gcc version 4.3.3 (GCC) COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' /localdata/libexec/gcc/i686-pc-linux-gnu/4.3.3/f951 pr37744.f90 -quiet -dumpbase pr37744.f90 -mtune=generic -auxbase pr37744 -version -fintrinsic-modules-path /localdata/lib/gcc/i686-pc-linux-gnu/4.3.3/finclude -o /tmp/ccQTr6UN.s GNU F95 (GCC) version 4.3.3 (i686-pc-linux-gnu) compiled by GNU C version 4.3.3, GMP version 4.3, MPFR version 2.4.1-p5. warning: GMP header version 4.3 differs from library version 4.3.0. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 pr37744.f90:22.19: foo%flags(trouble) = .FALSE._C_BOOL 1 Error: Symbol 'trouble' at (1) has no IMPLICIT type f951: internal compiler error: Segmentation fault -- dennis dot wassel at googlemail dot com changed: What|Removed |Added Known to fail|4.3.2 4.4.0 |4.3.2 4.3.3 4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37744
[Bug middle-end/40015] [4.5.0 Regression] Revision 147083 failed gfortran.dg/array_memcpy_4.f90
--- Comment #5 from rguenther at suse dot de 2009-05-04 09:01 ---
Subject: Re: [4.5.0 Regression] Revision 147083 failed
gfortran.dg/array_memcpy_4.f90
On Mon, 4 May 2009, dominiq at lps dot ens dot fr wrote:
> --- Comment #4 from dominiq at lps dot ens dot fr 2009-05-04 08:59
> ---
> This test has been introduced by the patch in
> http://gcc.gnu.org/ml/fortran/2007-01/msg00425.html.
> The tests gfortran.dg/array_memcpy_[1-3].f90 use
>
> ! { dg-final { scan-tree-dump-times "memcpy" * "original" } }
>
> So a simple fix would be to replace
>
> ! { dg-final { scan-tree-dump-times "d = " 1 "original" } }
>
> with
>
> ! { dg-final { scan-tree-dump-times "memcpy" 1 "original" } }
>
> but I don't understand why array_memcpy_4.f90 used to give a different
> construct and this change could mask a more serious problem.
I will investigate - we really should get the memcpy removed.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40015
[Bug fortran/37744] ICE-on-invalid with ISO_C_BINDING and TYPEs
--- Comment #4 from dominiq at lps dot ens dot fr 2009-05-04 09:06 --- Also ICE on trunk r147065 powerpc-apple-darwin9 or r147085 i686-apple-darwin9. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37744
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #1 from pault at gcc dot gnu dot org 2009-05-04 09:10 --- Dominique, Thanks for setting this up. I'll poll everybody involved for contributions and have assigned myself the bug(s). Cheers Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-04 09:10:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #2 from pault at gcc dot gnu dot org 2009-05-04 09:29 --- see PR40006: allow type cheating for procedures with an implicit interface"" -- pault at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||40006 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug target/38570] [arm] -mthumb generates sub-optimal prolog/epilog
--- Comment #7 from rearnsha at gcc dot gnu dot org 2009-05-04 09:41 --- (In reply to comment #6) > We can compute the maximum possible function length first. If the length is > not > large enough far jump is not necessary, and we can do this optimization > safely. > No, it's not that easy, since reload can add instructions. Realistically, there is a finite limit beyond which even reload couldn't generate sufficiently large numbers of instructions to cause failure, but it's hard to *prove* what that lower bound is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38570
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #3 from pault at gcc dot gnu dot org 2009-05-04 09:31 --- ...and PR39896 : "ICE with -fwhole-file" -- pault at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||39896 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug target/38570] [arm] -mthumb generates sub-optimal prolog/epilog
--- Comment #8 from carrot at google dot com 2009-05-04 10:08 --- Sorry for my ignorance to gcc. What types of instructions reload will add? Spilling and loading registers? and more? By reading the the implementation of thumb_far_jump_used_p() I can get the conclusion that if reload thinks there is a far jump, later pass won't change this decision. But if reload thinks there is no far jump, later pass still need to re-check the far jump existence and may change this decision. So if reload occasionally makes a wrong decision later pass should correct it, is it right? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38570
[Bug fortran/39896] ICE with -fwhole-file
--- Comment #5 from pault at gcc dot gnu dot org 2009-05-04 10:19 --- (In reply to comment #2) > It may be worth noting that there are no warnings in the application about > labels not being in the same block as the corresponding GOTO if compiled > without -fwhole-file, but if compiled with -fwhole-file some of these warnings > appear. > > If these warnings are missed without -fwhole-file or spurious with > -fwhole-file, I can not say yet. I'll try to get a testcase ... > For some reason that I do not see right now, cs_base in resolve.c is not being pushed or popped correctly. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39896
[Bug middle-end/40015] [4.5.0 Regression] Revision 147083 failed gfortran.dg/array_memcpy_4.f90
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-05-04 09:25 --- I have a patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-05-04 05:54:58 |2009-05-04 09:25:57 date|| Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40015
[Bug middle-end/40015] [4.5.0 Regression] Revision 147083 failed gfortran.dg/array_memcpy_4.f90
--- Comment #4 from dominiq at lps dot ens dot fr 2009-05-04 08:59 ---
This test has been introduced by the patch in
http://gcc.gnu.org/ml/fortran/2007-01/msg00425.html.
The tests gfortran.dg/array_memcpy_[1-3].f90 use
! { dg-final { scan-tree-dump-times "memcpy" * "original" } }
So a simple fix would be to replace
! { dg-final { scan-tree-dump-times "d = " 1 "original" } }
with
! { dg-final { scan-tree-dump-times "memcpy" 1 "original" } }
but I don't understand why array_memcpy_4.f90 used to give a different
construct and this change could mask a more serious problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40015
[Bug c++/40013] [4.4 Regression] ICE when creating a local array with size from the return value of a member function of an object in a nested class in a template class
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.3.3 Summary|[4.4 regression] ICE when |[4.4 Regression] ICE when |creating a local array with |creating a local array with |size from the return value |size from the return value |of a member function of an |of a member function of an |object in a nested class in |object in a nested class in |a template class|a template class Target Milestone|--- |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40013
[Bug fortran/39896] ICE with -fwhole-file
--- Comment #6 from pault at gcc dot gnu dot org 2009-05-04 10:31 --- > For some reason that I do not see right now, cs_base in resolve.c is not being > pushed or popped correctly. Ah yes! resolve_codes nulls out cs_base. The problem is fixed by storing cs_base before calling gfc_resolve, at line 1674, and then restoring the value afterwards. It might be cleaner to do this in gfc_resolve - I'll check later. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39896
[Bug fortran/39896] ICE with -fwhole-file
--- Comment #7 from pault at gcc dot gnu dot org 2009-05-04 10:32 --- I guess that I should take it :-) Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-04 10:32:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39896
[Bug middle-end/40015] [4.5.0 Regression] Revision 147083 failed gfortran.dg/array_memcpy_4.f90
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-05-04 11:02 --- Subject: Bug 40015 Author: rguenth Date: Mon May 4 11:01:59 2009 New Revision: 147094 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147094 Log: 2009-05-04 Richard Guenther PR middle-end/40015 * builtins.c (fold_builtin_memory_op): Do not decay to element type if the size matches the whole array. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40015
[Bug c++/40013] [4.4 Regression] ICE when creating a local array with size from the return value of a member function of an object in a nested class in a template class
--- Comment #1 from jakub at gcc dot gnu dot org 2009-05-04 11:26 --- http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00116.html -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-04 11:26:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40013
[Bug bootstrap/39968] [4.5 Regression] ./plugin-version.h:11: error: 'gcc_version' defined but not used
--- Comment #6 from dominiq at lps dot ens dot fr 2009-05-04 11:42 --- This pr is fixed as long as *-apple-darwin9 is concerned. Due to comments #3 to #5, I don't close it as fixed. If someone wants to keep this PR open, (s)he should change subject and priority. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39968
[Bug bootstrap/39929] [4.5 Regression] Bootstrapping fails at stage 1 on powerpc-apple-darwin9 and powerpc-ibm-aix
--- Comment #15 from dominiq at lps dot ens dot fr 2009-05-04 11:45 --- This pr is fixed as long as *-apple-darwin9 is concerned. Due to comments #11 to #13, I don't close it as fixed. If someone wants to keep this PR open, (s)he should change subject, platform, and priority. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39929
[Bug middle-end/40015] [4.5.0 Regression] Revision 147083 failed gfortran.dg/array_memcpy_4.f90
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-05-04 12:43 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40015
[Bug c++/28152] Diagnostic about wrong use _Complex prints __complex__
--- Comment #9 from manu at gcc dot gnu dot org 2009-05-04 12:48 --- Subject: Bug 28152 Author: manu Date: Mon May 4 12:47:53 2009 New Revision: 147097 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147097 Log: 2009-05-04 Manuel Lopez-Ibanez PR c++/28152 cp/ * parser.c (cp_lexer_get_preprocessor_token): Do not store the canonical spelling for keywords. (cp_parser_attribute_list): Use the canonical spelling for keywords in attributes. testsuite/ * g++.dg/parse/parser-pr28152.C: New. * g++.dg/parse/parser-pr28152-2.C: New. Added: trunk/gcc/testsuite/g++.dg/parse/parser-pr28152-2.C trunk/gcc/testsuite/g++.dg/parse/parser-pr28152.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28152
[Bug c++/28152] Diagnostic about wrong use _Complex prints __complex__
--- Comment #10 from manu at gcc dot gnu dot org 2009-05-04 12:49 --- FIXED in GCC 4.5 -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28152
[Bug c/40016] New: regex_internal.h:185: error: integer overflow in preprocessor expression
Hi, when i compiling gnu parted 1.8.8 with gcc 4.5.0, got error include regex.i TIA = /bin/sh ../libtool --tag=CC --mode=compile gcc -std=gnu99 -I. -Os -Werror -MT regex.lo -MD -MP -MF .deps/regex.Tpo -c -o regex.lo regex.c gcc -std=gnu99 -I. -Os -Werror -MT regex.lo -MD -MP -MF .deps/regex.Tpo -c regex.c -fPIC -DPIC -o .libs/regex.o cc1: warnings being treated as errors In file included from regex.c:58: regex_internal.h:185: error: integer overflow in preprocessor expression make[2]: *** [regex.lo] Error 1 make[2]: Leaving directory `/home/user/d/parted-1.8.8/lib' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/user/d/parted-1.8.8/lib' make: *** [all-recursive] Error 1 bash-4.0$ cc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr --libexecdir=/usr/lib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++ --disable-bootstrap --disable-multilib Thread model: posix gcc version 4.5.0 20090503 (experimental) (GCC) bash-4.0$ -- Summary: regex_internal.h:185: error: integer overflow in preprocessor expression Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: happyarch at gmail dot com GCC build triplet: x86_64 GCC host triplet: x86_64 GCC target triplet: x86_64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40016
[Bug c/40016] regex_internal.h:185: error: integer overflow in preprocessor expression
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-04 14:23 --- Works for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40016
[Bug target/40017] New: [4.4/4.5 Regression] stdbool.h/altivec.h
#include
#include
vector bool int b;
int
main (void)
{
return 0;
}
used to compile up to 4.3, doesn't any longer. I wonder what can be done here
though, for C++ with the conditional macros bool keywords can coexist well with
the context sensitive keywords, but unfortunately #define bool _Bool
kills the conditional keyword behavior.
--
Summary: [4.4/4.5 Regression] stdbool.h/altivec.h
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40017
[Bug bootstrap/39849] [4.3/4.4 Regression] segfault for '__divtf3' during bootstrap and non-bootstrap install
--- Comment #8 from dennis dot wassel at googlemail dot com 2009-05-04 14:18 --- Marked as 4.3/4.4 regression. What should I try next? Need I provide any additional info? Any help is much appreciated! -- dennis dot wassel at googlemail dot com changed: What|Removed |Added Severity|normal |major Summary|segfault for '__divtf3' |[4.3/4.4 Regression] |during bootstrap and non- |segfault for '__divtf3' |bootstrap install |during bootstrap and non- ||bootstrap install http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39849
[Bug bootstrap/39849] [4.3/4.4 Regression] segfault for '__divtf3' during bootstrap and non-bootstrap install
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-05-04 14:28 --- Do not set CFLAGS in make CFLAGS='-O2' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' profiledbootstrap or specify your host compiler version. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39849
[Bug bootstrap/39849] segfault for '__divtf3' during bootstrap and non-bootstrap install
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-05-04 14:29 --- It obviously works for me, you system seems to be messed up / special. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3/4.4 Regression]|segfault for '__divtf3' |segfault for '__divtf3' |during bootstrap and non- |during bootstrap and non- |bootstrap install |bootstrap install | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39849
[Bug target/40017] [4.4/4.5 Regression] stdbool.h/altivec.h
--- Comment #1 from jakub at gcc dot gnu dot org 2009-05-04 14:30 --- I'd say handling _Bool the same way as bool after vector would be a good idea. It has a disadvantage that in addition to the (I'd say desirable): #include #include ... vector bool int i; also vector _Bool int i; would be accepted, but the advantages IMHO outweight disadvantages. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org, ||bje at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40017
[Bug target/40017] [4.4/4.5 Regression] stdbool.h/altivec.h
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-05-04 14:32 --- Yes that seems like the right idea; the altivec specs was written before C99 was out. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40017
[Bug bootstrap/39849] segfault for '__divtf3' during bootstrap and non-bootstrap install
--- Comment #13 from dennis dot wassel at googlemail dot com 2009-05-04 14:55 --- I just noticed/remembered that [x]gcc only drives the compilers, so I plugged cc1 into gdb and here is the (somewhat messy, slightly edited) result: gdb /localdata/install/gcc/gcc-4.4.0-build/./gcc/cc1 GNU gdb 6.8 This GDB was configured as "i686-pc-linux-gnu"... run -quiet -v -I. -I. -I../.././gcc -I../../../gcc-4.4.0/libgcc -I../../../gcc-4.4.0/libgcc/. -I../../../gcc-4.4.0/libgcc/../gcc -I../../../gcc-4.4.0/libgcc/../include -I../../../gcc-4.4.0/libgcc/config/libbid -iprefix /localdata/install/gcc/gcc-4.4.0-build/gcc/../lib/gcc/i686-pc-linux-gnu/4.4.0/ -isystem /localdata/install/gcc/gcc-4.4.0-build/./gcc/include -isystem /localdata/install/gcc/gcc-4.4.0-build/./gcc/include-fixed -MD divtf3.d -MF divtf3.dep -MP -MT divtf3.o -DIN_GCC -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -DHIDE_EXPORTS -isystem /localdata/i686-pc-linux-gnu/include -isystem /localdata/i686-pc-linux-gnu/sys-include -isystem ./include ../../../gcc-4.4.0/libgcc/../gcc/config/soft-fp/divtf3.c -quiet -dumpbase divtf3.c -mtune=generic -auxbase-strip divtf3.o -g -g -g -O2 -O2 -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wcast-qual -Wold-style-definition -Wno-missing-prototypes -Wno-type-limits -version -fPIC -fexceptions -fvisibility=hidden -o /tmp/ccuJ4Jyu.s Starting program: /localdata/install/gcc/gcc-4.4.0-build/gcc/cc1 -quiet -v -I. -I. -I../.././gcc -I../../../gcc-4.4.0/libgcc -I../../../gcc-4.4.0/libgcc/. -I../../../gcc-4.4.0/libgcc/../gcc -I../../../gcc-4.4.0/libgcc/../include -I../../../gcc-4.4.0/libgcc/config/libbid -iprefix /localdata/install/gcc/gcc-4.4.0-build/gcc/../lib/gcc/i686-pc-linux-gnu/4.4.0/ -isystem /localdata/install/gcc/gcc-4.4.0-build/./gcc/include -isystem /localdata/install/gcc/gcc-4.4.0-build/./gcc/include-fixed -MD divtf3.d -MF divtf3.dep -MP -MT divtf3.o -DIN_GCC -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -DHIDE_EXPORTS -isystem /localdata/i686-pc-linux-gnu/include -isystem /localdata/i686-pc-linux-gnu/sys-include -isystem ./include ../../../gcc-4.4.0/libgcc/../gcc/config/soft-fp/divtf3.c -quiet -dumpbase divtf3.c -mtune=generic -auxbase-strip divtf3.o -g -g -g -O2 -O2 -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wcast-qual -Wold-style-definition -Wno-missing-prototypes -Wno-type-limits -version -fPIC -fexceptions -fvisibility=hidden -o /tmp/ccuJ4Jyu.s Failed to read a valid object file image from memory. ignoring nonexistent directory "/localdata/i686-pc-linux-gnu/include" ignoring nonexistent directory "/localdata/i686-pc-linux-gnu/sys-include" ignoring nonexistent directory "./include" ignoring nonexistent directory "/localdata/install/gcc/gcc-4.4.0-build/gcc/../lib/gcc/i686-pc-linux-gnu/4.4.0/include" ignoring nonexistent directory "/localdata/install/gcc/gcc-4.4.0-build/gcc/../lib/gcc/i686-pc-linux-gnu/4.4.0/include-fixed" ignoring nonexistent directory "/localdata/install/gcc/gcc-4.4.0-build/gcc/../lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../i686-pc-linux-gnu/include" ignoring nonexistent directory "/localdata/lib/gcc/i686-pc-linux-gnu/4.4.0/include" ignoring nonexistent directory "/localdata/lib/gcc/i686-pc-linux-gnu/4.4.0/include-fixed" ignoring nonexistent directory "/localdata/lib/gcc/i686-pc-linux-gnu/../../../i686-pc-linux-gnu/include" ignoring duplicate directory "." ignoring duplicate directory "../../../gcc-4.4.0/libgcc/." #include "..." search starts here: #include <...> search starts here: . ../.././gcc ../../../gcc-4.4.0/libgcc ../../../gcc-4.4.0/libgcc/../gcc ../../../gcc-4.4.0/libgcc/../include ../../../gcc-4.4.0/libgcc/config/libbid /localdata/install/gcc/gcc-4.4.0-build/./gcc/include /localdata/install/gcc/gcc-4.4.0-build/./gcc/include-fixed /usr/local/include /localdata/include /usr/include End of search list. GNU C (GCC) version 4.4.0 (i686-pc-linux-gnu) compiled by GNU C version 4.3.3, GMP version 4.3, MPFR version 2.4.1-p5. warning: GMP header version 4.3 differs from library version 4.3.0. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: ac242e6eff36fdeb132b194aac7540a7 Program received signal SIGSEGV, Segmentation fault. 0x0816a5ba in c_tree_printer (pp=0x9e3d288, text=0xbfd3ca04, spec=0x9e23129 "D", precision=0, wide=0 '\0', set_locus=0 '\0', hash=0 '\0') at ../../gcc-4.4.0/gcc/c-objc-common.c:99 99tree t = va_arg (*text->args_ptr, tree); (gdb) bt #0 0x0816a5ba in c_tree_printer (pp=0x9e3d288, text=0xbfd3ca04, spec=0x9e23129 "D", precision=0, wide=0 '\0', set_locus=0 '\0', hash=0 '\0') at ../../gcc-4.4.0/gcc/c-objc-common.c:99 #1 0x088568b4 in pp_base_format (pp=0x9e3d288, text=0xbfd3ca04) at ../../gcc-4.4.0/gcc/pretty-print.c:557 #2 0x083cc846 in diagnostic_report_diagnostic (context=0x9dc3aa0, diagnostic=0xbfd3ca04) at ../../gcc-4.4.0/gcc/diagnostic
[Bug bootstrap/38523] [4.4/4.5 regression] arm build fails to link cc1-dummy
--- Comment #21 from laurent at guerby dot net 2009-05-04 14:50 --- No objection in one week, so closing as WORKSFORME with binutils from CVS >= 20090423 -- laurent at guerby dot net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38523
[Bug bootstrap/39849] segfault for '__divtf3' during bootstrap and non-bootstrap install
--- Comment #15 from dennis dot wassel at googlemail dot com 2009-05-04 15:09 --- Created an attachment (id=17796) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17796&action=view) Preprocessed source Sure! Attaching preprocessed source of gcc-4.4.0/gcc/config/soft-fp/divtf3.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39849
[Bug c/40016] regex_internal.h:185: error: integer overflow in preprocessor expression
--- Comment #3 from jakub at gcc dot gnu dot org 2009-05-04 14:52 --- Not surprisingly when the error is during preprocessing. regex.h parted ships (why?) is broken by the #elif changes, there is: #if some_condition_that_is_true_on_sane_targets ... #elif BITSET_WORD_MAX == (0x + 2) * 0x /* Work around a bug in 64-bit PGC (before version 6.1-2), where the preprocessor mishandles large unsigned values as if they were signed. */ ... #endif To make GCC happy about this at least the #elif should be changed into #else #if ... #endif. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40016
[Bug bootstrap/39849] segfault for '__divtf3' during bootstrap and non-bootstrap install
--- Comment #14 from pinskia at gcc dot gnu dot org 2009-05-04 15:00 --- Yes slightly, it is trying to warn about something which is unitialized. This works for me on i686-linux-gnu. Can you provide the preprocessed source? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39849
[Bug ada/38874] gnatmake doesn't pass through --param options
--- Comment #3 from guerby at gcc dot gnu dot org 2009-05-04 15:32 --- Subject: Bug 38874 Author: guerby Date: Mon May 4 15:32:00 2009 New Revision: 147102 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147102 Log: 2009-05-04 Laurent GUERBY PR ada/38874 * make.adb (Scan_Make_Arg): Pass --param= to compiler and linker. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/make.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38874
[Bug bootstrap/39977] [4.5 Regression] r146817 broke bootstrap on PA
--- Comment #7 from danglin at gcc dot gnu dot org 2009-05-04 15:35 --- The patch from comment #4 was installed here: http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00018.html >From my perspective, this fixes the 4.5 regression reported here. Possibly the change should be back ported to fix PR 29209. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39977
[Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817
--- Comment #8 from luisgpm at linux dot vnet dot ibm dot com 2009-05-04 15:41 --- Oops... forgot about that bit, sorry. Compile flags: -m32 -O3 -mcpu=power[4|5|6] -ffast-math -ftree-loop-linear -funroll-loops -fpeel-loops This reproduces on both 32-bit and 64-bit. Luis -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
[Bug bootstrap/39849] segfault for '__divtf3' during bootstrap and non-bootstrap install
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39849
[Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817
--- Comment #9 from luisgpm at linux dot vnet dot ibm dot com 2009-05-04 15:50 --- Follows the configure options, although i think you'll be able to reproduce it with the flags i've mentioned. /gcc/HEAD/configure --target=powerpc64-linux --host=powerpc64-linux --build=powerpc64-linux --with-cpu=default32 --enable-threads=posix --enable-shared --enable-__cxa_atexit --with-gmp=/gmp --with-mpfr=mpfr --with-long-double-128 --enable-decimal-float --enable-secure-plt --disable-bootstrap --disable-alsa --prefix=/install/gcc/HEAD build_alias=powerpc64-linux host_alias=powerpc64-linux target_alias=powerpc64-linux --enable-languages=c,c++,fortran --no-create --no-recursion -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
[Bug bootstrap/39849] segfault for '__divtf3' during bootstrap and non-bootstrap install
--- Comment #11 from dennis dot wassel at googlemail dot com 2009-05-04 14:35 --- (In reply to comment #9) > Do not set CFLAGS in > > make CFLAGS='-O2' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 > -fno-implicit-templates' profiledbootstrap This ^ was only in my first iteration, and I've omitted it in the following ones. My last (unsuccessful) attempt was a plain: ../gcc-4.4.0/configure --prefix=/localdata --program-suffix=-4.4.0 --enable-languages=c,c++,fortran --with-gmp=/localdata --with-mpfr=/localdata --with-ppl=/localdata --with-cloog=/localdata --enable-version-specific-runtime-libs make and nothing out of the ordinary. > or specify your host compiler version. My host compiler is gcc 4.3.3 gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.3.3/configure --prefix=/localdata --program-suffix=-4.3.3 --enable-languages=c,c++,fortran --with-gmp=/localdata --with-mpfr=/localdata --enable-version-specific-runtime-libs Thread model: posix gcc version 4.3.3 (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39849
[Bug middle-end/39978] [4.5 Regression] SEGV compiling libiberty/regex.c in stage2
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2009-05-04
13:48 ---
Subject: Re: [4.5 Regression] SEGV compiling libiberty/regex.c in stage2
> Which pass? p *pass in frame 20 should tell you.
(gdb) p *pass
$1 = {type = GIMPLE_PASS, name = 0x27bb734 "forwprop",
gate = 0x152d6d4 ,
execute = 0x152cc8c , sub = 0x0,
next = 0x2a806c8, static_pass_number = 123, tv_id = TV_TREE_FORWPROP,
properties_required = 40, properties_provided = 0, properties_destroyed = 0,
todo_flags_start = 0, todo_flags_finish = 2055}
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39978
[Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817
--- Comment #7 from matz at gcc dot gnu dot org 2009-05-04 14:37 --- Compile options please. I can't reproduce it with a powerpc64 compiler with -O2, neither with -m32 nor -m64, -ffast-math or no -ffast-math. Also 'gcc -v' can't hurt to make sure our compilers are configured the same. Hint: I use this command to quickly skim over the situation with labels and bdnz: % egrep '^.L|bdnz' thin6d.s If the bdnz lines always mention the label from a line above it's a single basic block loop. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
[Bug c/40016] regex_internal.h:185: error: integer overflow in preprocessor expression
--- Comment #1 from happyarch at gmail dot com 2009-05-04 13:59 --- Created an attachment (id=17795) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17795&action=view) .i file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40016
[Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817
--- Comment #10 from matz at gcc dot gnu dot org 2009-05-04 16:10 --- Yes, I can now, thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
[Bug bootstrap/39849] segfault for '__divtf3' during bootstrap and non-bootstrap install
--- Comment #12 from dennis dot wassel at googlemail dot com 2009-05-04 14:43 --- (In reply to comment #10) > It obviously works for me, you system seems to be messed up / special. Seems so, although it is a Debian 4 with an unknown amount of modifications by our admin. One symptom of specialness is the fact that neither the system nor the gcc's headers define SSIZE_MAX, but I have a workaround for that (namely defining it as SHRT_MAX in config/host-linux.c, if it is undefined). Shall I dig around somewhere to find out the exact amount of my system's specialness? Is there a way to build the bootstrap compiler with debugging info, so I can use gdb to figure out where the segfault happens? PS: I think this *is* a regression, because I can build 4.3, but not 4.4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39849
[Bug target/40017] [4.4/4.5 Regression] stdbool.h/altivec.h
--- Comment #3 from jakub at gcc dot gnu dot org 2009-05-04 14:39 --- _Bool would need to be a conditional macro too though, I wonder if some ISO C99 pedantry can't test that _Bool isn't defined or something like that. But then for C++ it is similar with defined(bool) also being true with -maltivec instead of false. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40017
[Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817
--- Comment #6 from luisgpm at linux dot vnet dot ibm dot com 2009-05-04 13:50 --- Just for the sake of information, -fselective-scheduling doesn't help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #4 from dominiq at lps dot ens dot fr 2009-05-04 17:54 --- With thee patch in http://gcc.gnu.org/ml/fortran/2009-05/msg00056.html without type cheating, all the ICEs in my tests are gone. It even fixes pr37744!-(it may give a clue on how to fix it without -fwhole-file). For the test arr_fun.f90, I now get: arr_fun.f90:10.6: res = test(2) 1 Error: The reference to function 'test' at (1) either needs an explicit INTERFACE or the rank is incorrect which seems right (without -fwhole-file I get a "bus error" at run time). Test gcc/testsuite/gfortran.dg/hollerith.f90 and friends won't probably pass regtesting: call test (8h hello) 1 Error: Type mismatch in argument 'h' at (1); passed HOLLERITH to INTEGER(8) I have to run the polyhedron tests and to regtest, so it is all for this time. Thanks for the patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/39896] ICE with -fwhole-file
--- Comment #8 from dfranke at gcc dot gnu dot org 2009-05-04 18:08 --- Paul, your patch fixes all issues I came across when compiling my largish set of fortran sources with -fwhole-file. So, now I "just" need to sort out all the warnings that came up *cough* ;) Many thanks! -- dfranke at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/fortra ||n/2009-05/msg00046.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39896
[Bug fortran/40018] New: ICE in output_constructor
$ cat a.f90 integer(kind=8) :: i write(*,*) [(i, i = 1, 10)] end $ gfortran a.f90 a.f90:2: internal compiler error: in output_constructor, at varasm.c:4712 The GDB backtrace is: #0 fancy_abort (file=0xd7999a "../../trunk/gcc/varasm.c", line=4716, function=0xd792d0 "output_constructor") at ../../trunk/gcc/diagnostic.c:723 #1 0x0094b762 in output_constructor (exp=, size=, align=) at ../../trunk/gcc/varasm.c:4716 #2 0x009bec65 in varpool_assemble_decl (node=0x2ace99df7a40) at ../../trunk/gcc/varpool.c:364 #3 0x0098f991 in cgraph_output_in_order () at ../../trunk/gcc/cgraphunit.c:1202 #4 0x00991622 in cgraph_optimize () at ../../trunk/gcc/cgraphunit.c:1318 #5 0x005125e5 in gfc_be_parse_file (set_yydebug=) at ../../trunk/gcc/fortran/f95-lang.c:237 #6 0x007e0324 in toplev_main (argc=2, argv=0x7fff143ae1b8) at ../../trunk/gcc/toplev.c:977 Happens on x86_64-linux with current trunk (rev. 147105), and i686-apple-darwin9 rev. 144983. -- Summary: ICE in output_constructor Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org OtherBugsDependingO 32834 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40018
[Bug fortran/40018] ICE in output_constructor
--- Comment #1 from dominiq at lps dot ens dot fr 2009-05-04 19:19 --- Confirmed on trunk and 4.4.0. Works with 4.3.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40018
[Bug fortran/40019] New: LEADZ and TRAILZ give wrong results
LEADZ and TRAILZ can give wrong results for kinds other than 4 and 8. For example, the following code: integer(kind=1) :: i1 integer(kind=2) :: i2 integer(kind=4) :: i4 integer(kind=8) :: i8 integer(kind=16) :: i16 i1 = -1 i2 = -1 i4 = -1 i8 = -1 i16 = -1 print *, leadz(i1), leadz(i2), leadz(i4), leadz(i8), leadz(i16) gives "-24 -16 0 0 64" as results, while it should only yield zeros! There are a few reasons: - for kinds 1 and 2, we should not cast directly to (unsigned int), but do a double cast: (unsigned int)(unsigned char) for kind=1, for example; otherwise, negative values are screwed. - trans-intrinsic.c uses a correspondance, kinds == 1, 2 and 4 use BUILT_IN_CLZ, kind 8 uses BUILT_IN_CLZL and kind 16 uses BUILT_IN_CLZLL; in reality, there is no such correspondance, as kind==16 is larger than long long! This, of course, makes it harder, because there is no function ready for use in kind==16. -- Summary: LEADZ and TRAILZ give wrong results Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40019
[Bug fortran/38282] Add the remaining HPF bit intrinsics
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2009-05-04 19:37
---
About POPCNT and POPPAR, beware! Implementations are much harder than simply
using the GCC __builtin_popcount{,l,ll}: see PR40019 for similar issue with
LEADZ and TRAILZ.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38282
[Bug c/33466] mixed-case suffix for decimal float constants
--- Comment #10 from janis at gcc dot gnu dot org 2009-05-04 19:50 --- Fixed for trunk, expected to become GCC 4.5.0. -- janis at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33466
[Bug target/39027] double floating point suffix of 'd' and 'D' not accepted
--- Comment #5 from janis at gcc dot gnu dot org 2009-05-04 19:55 --- This was fixed in trunk, expected to become GCC 4.5.0, on 2009-04-01 as revision 145422. The ChangeLog entries have the correct PR number but the svn log messages use 29027, which is why the checkins were not recorded here. -- janis at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39027
[Bug fortran/39772] add a correctness check for the size intrinsic to -fbounds-check
--- Comment #10 from mikael at gcc dot gnu dot org 2009-05-04 20:24 --- cf PR36462 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39772
[Bug fortran/39971] kinds.h fails at building libgfortran
--- Comment #13 from mikael at gcc dot gnu dot org 2009-05-04 20:27 --- (In reply to comment #12) > don't know how to use it to compile gcc being a normal user (no root > privileges) without scrambling everything else. Any help on this direction? > Thanks > export LD_LIBRARY_PATH=/your/libc/path ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39971
[Bug middle-end/39973] [4.5 Regression] Revision 146817 miscompiled 416.gamess in SPEC CPU 2006
--- Comment #3 from hjl dot tools at gmail dot com 2009-05-04 20:44 --- blas.fppized.f was miscompiled by -m32 -c -O3 -msse2 -mfpmath=sse -ffast-math -fno-inline-functions -funroll-loops -ffixed-form -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39973
[Bug middle-end/39972] [4.5 Regression] Revision 146817 miscompiled 465.tonto in SPEC CPU 2006
--- Comment #4 from hjl dot tools at gmail dot com 2009-05-04 20:52 --- blas.f90 was miscompiled by -m32 -O3 -msse2 -mfpmath=sse -ffast-math -fno-inline-functions -funroll-loops -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39972
[Bug target/39986] decimal float constant is incorrect when cc1 is a 64-bit binary
--- Comment #3 from janis at gcc dot gnu dot org 2009-05-04 21:24 --- On x86_64 with a 64-bit compiler, positive decimal float constants are OK, negative decimal float constants are wrong for both -m64 (the default) and -m32. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39986
[Bug fortran/40020] New: Bad value during floating point read
I tried to migrate well running program from g77 to gfortran. I found a problem with new gfortan: >>Fortran runtime error: Bad value during floating point read<< to read REAL from file. >> read(nin,'(6e11.0)') a and numbers were: >> 7.73118- 3 4.26617+ 0 8.17285- 3 ... It helps to add number '0' to exponent instead of space >> 7.73118-03 4.26617+00 8.17285-03 ... Input decks are very old so I'm not sure if it was some feature off g77. -- Summary: Bad value during floating point read Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ased at cce dot cz GCC build triplet: i486-linux-gnu GCC host triplet: i486-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40020
[Bug middle-end/40021] New: [4.5 Regression] Revision 146817 miscompiled DAXPY in BLAS
On Linux/ia32, revision 146817 miscompiled DAXPY in BLAS with -m32 O3 -msse2 -mfpmath=sse -ffast-math -fno-inline-functions -funroll-loops -ffixed-form -- Summary: [4.5 Regression] Revision 146817 miscompiled DAXPY in BLAS Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end 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=40021
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #5 from dominiq at lps dot ens dot fr 2009-05-04 21:52 --- With the patch in http://gcc.gnu.org/ml/fortran/2009-05/msg00056.html gas_dyn.f90 fails as in commet #0, except for -O1: [ibook-dhum] lin/test% gfc -O1 -fwhole-file gas_dyn.f90 gas_dyn.f90: In function 'chozdt': gas_dyn.f90:216: internal compiler error: Bus error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug middle-end/40021] [4.5 Regression] Revision 146817 miscompiled DAXPY in BLAS
--- Comment #1 from hjl dot tools at gmail dot com 2009-05-04 21:52 --- *** Bug 39972 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40021
[Bug middle-end/39972] [4.5 Regression] Revision 146817 miscompiled 465.tonto in SPEC CPU 2006
--- Comment #5 from hjl dot tools at gmail dot com 2009-05-04 21:52 --- *** This bug has been marked as a duplicate of 40021 *** -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39972
[Bug middle-end/39973] [4.5 Regression] Revision 146817 miscompiled 416.gamess in SPEC CPU 2006
--- Comment #4 from hjl dot tools at gmail dot com 2009-05-04 21:53 --- *** This bug has been marked as a duplicate of 40021 *** -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39973
[Bug middle-end/40021] [4.5 Regression] Revision 146817 miscompiled DAXPY in BLAS
--- Comment #2 from hjl dot tools at gmail dot com 2009-05-04 21:53 --- *** Bug 39973 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40021
[Bug fortran/40020] Bad value during floating point read
--- Comment #1 from kargl at gcc dot gnu dot org 2009-05-04 22:17 --- (In reply to comment #0) > I tried to migrate well running program from g77 to gfortran. > I found a problem with new gfortan: > >>Fortran runtime error: Bad value during floating point read<< > to read REAL from file. > >> read(nin,'(6e11.0)') a > and numbers were: > >> 7.73118- 3 4.26617+ 0 8.17285- 3 ... > It helps to add number '0' to exponent instead of space > >> 7.73118-03 4.26617+00 8.17285-03 ... > Input decks are very old so I'm not sure if it was some feature > off g77. Works fine with 4.5.0 and I suspect 4.4.0. Please try 4.4.0. REMOVE:kargl[30] gfc4x -o z gf.f90 REMOVE:kargl[31] ./z 0.12345e- 3 1.23449994E-04 REMOVE:kargl[32] gfc43 -o z gf.f90 REMOVE:kargl[33] ./z 0.12345e- 3 At line 3 of file gf.f90 (unit = 5, file = 'stdin') Fortran runtime error: Bad value during floating point read REMOVE:kargl[34] cat gf.f90 program gf real x read(*,'(e11.0)') x write(*,*) x end program gf -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40020
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #6 from dominiq at lps dot ens dot fr 2009-05-04 22:20 ---
Regtest gives:
=== gfortran Summary ===
# of expected passes117714
# of unexpected failures576
# of expected failures 78
# of unsupported tests 906
for RUNTESTFLAGS="--target_board=unix'{,-m64,/-fwhole-file,-m64/-fwhole-file}'"
with no "unexpected failures" for {,-m64}. 444 failures come from
cc1: warning: command line option "-fwhole-file" is valid for Fortran but not
for C
I think I know how to filter them.
---> generic_actual_arg.f90 fails with
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/generic_actual_arg.f90:40.64:
CALL F(CALCULATION2) ! OK because there is a same name specific
1
Error: More actual than formal arguments in procedure call at (1)
False positive?
---> global_references_1.f90 fails with
SUBROUTINE j (x)! { dg-error "is already being used as a FUNCTION" }
2
Error: Global name 'j' at (1) is already being used as a SUBROUTINE at (2)
/opt/gcc/gcc-4.5-work/gcc/testsuite/gfortran.dg/global_references_1.f90:39.6:
T = j () ! { dg-error "is already being used as a FUNCTION" }
1
Error: Missing actual argument for argument 'x' at (1)
/opt/gcc/gcc-4.5-work/gcc/testsuite/gfortran.dg/global_references_1.f90:68.64:
---> hollerith.f90 fails with
call test (8h hello)
1
Error: Type mismatch in argument 'h' at (1); passed HOLLERITH to INTEGER(8)
---> hollerith_legacy.f90 same failure
---> import6.f90 fails with
opt/gcc/gcc-4.5-work/gcc/testsuite/gfortran.dg/import6.f90:42.13:
call func1(x)
1
Error: Type mismatch in argument 'param' at (1); passed TYPE(my_type) to
TYPE(my_type)
Obviously some tests will require adjustments to pass with -fwhole-file.
More tomorrow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug libstdc++/39382] FAIL: abi_check on trunk revision 144629
--- Comment #3 from bkoz at gcc dot gnu dot org 2009-05-04 22:33 --- No feedback. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39382
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #7 from dominiq at lps dot ens dot fr 2009-05-04 22:44 --- Also gfortran.dg/contained_3.f90 is miscompiled with -fwhole-file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug middle-end/40021] [4.5 Regression] Revision 146817 miscompiled DAXPY in BLAS
--- Comment #3 from hjl dot tools at gmail dot com 2009-05-04 23:07 --- Created an attachment (id=17797) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17797&action=view) A testcase [...@gnu-33 pr40021]$ make /export/gnu/import/rrs/146817/usr/bin/gfortran -m32 -c -O3 -msse2 -mfpmath=sse -ffast-math -fno-inline-functions -funroll-loops -ffixed-form test.f /export/gnu/import/rrs/146817/usr/bin/gfortran -m32 -c -O3 -msse2 -mfpmath=sse -ffast-math -fno-inline-functions -funroll-loops -ffixed-form daxpy.f /export/gnu/import/rrs/146817/usr/bin/gfortran -m32 -Wl,-rpath,/export/gnu/import/rrs/146817/usr/lib -o daxpy test.o daxpy.o ./daxpy 2 -2.20932289958000183E-002 != -2.22017297318430201E-002 4.88703976462625395E-003 [...@gnu-33 pr40021]$ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40021
[Bug c/40022] New: 4.4 regression breaks "reply to all" in alpine
Hello, I have to admit I'm clueless about how to debug this.
On Fedora 11 preview release with gcc-4.4.0 alpine "reply to all"
does not include the list of cc'd addresses. Linus found that if
you compile the pith/reply.cc without optimizations it works
properly (see Fedora bug report at
http://bugzilla.redhat.com/show_bug.cgi?id=496400 ).
Here is how to reproduce:
mkdir alpinetest
cd alpinetest
svn checkout https://svn.cac.washington.edu/public/alpine/snapshots/
cd snapshots
_sysconfdir=/etc/
touch imap/ip6
./configure \ --enable-debug=no \
--without-tcl \
--with-c-client-target=lfd \
--with-passfile=.alpine.passfile \
--with-spellcheck-prog=aspell \
--with-system-pinerc=%{_sysconfdir}/pine.conf \
--with-system-fixed-pinerc=%{_sysconfdir}/pine.conf.fixed
make
alpine/alpine # try "Reply to all" and see bug
cd pith
make clean && make CFLAGS=-O0
cd ..
make
alpine/alpine # try "Reply to all" and see it working
--
Summary: 4.4 regression breaks "reply to all" in alpine
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joshuadfranklin at yahoo dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40022
[Bug middle-end/40021] [4.5 Regression] Revision 146817 miscompiled DAXPY in BLAS
--- Comment #4 from hjl dot tools at gmail dot com 2009-05-04 23:09 --- The vectorizer seems broken: /export/gnu/import/rrs/146817/usr/bin/gfortran -m32 -c -O2 -ftree-vectorize -msse2 -mfpmath=sse -ffast-math -ffixed-form test.f /export/gnu/import/rrs/146817/usr/bin/gfortran -m32 -c -O2 -ftree-vectorize -msse2 -mfpmath=sse -ffast-math -ffixed-form daxpy.f /export/gnu/import/rrs/146817/usr/bin/gfortran -m32 -Wl,-rpath,/export/gnu/import/rrs/146817/usr/lib -o daxpy test.o daxpy.o ./daxpy 2 -2.20932289958000183E-002 != -2.22017297318430201E-002 4.88703976462625395E-003 [...@gnu-33 pr40021]$ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40021
[Bug middle-end/40022] 4.4 regression breaks "reply to all" in alpine
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-04 23:16 --- Hmm, so -fwrapv and -fno-strict-aliasing fixes the problem which case it might be a bug in the source. Can you provide the preprocessed source of pith/reply.cc? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40022
[Bug middle-end/40022] 4.4 regression breaks "reply to all" in alpine
--- Comment #2 from joshuadfranklin at yahoo dot com 2009-05-04 23:36 --- Created an attachment (id=17798) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17798&action=view) alpine pith/reply.c compiled with O0 and save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40022
[Bug middle-end/40022] 4.4 regression breaks "reply to all" in alpine
-- joshuadfranklin at yahoo dot com changed: What|Removed |Added CC||joshuadfranklin at yahoo dot ||com Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40022
[Bug middle-end/40022] 4.4 regression breaks "reply to all" in alpine
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-05-04 23:55 --- That is the assembler that is produced not the preprocessed source, use -save-temps and attach the .ii file. Thanks, Andrew Pinski -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40022
[Bug middle-end/40022] 4.4 regression breaks "reply to all" in alpine
--- Comment #4 from joshuadfranklin at yahoo dot com 2009-05-05 00:00 --- Created an attachment (id=17799) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17799&action=view) alpine pith/reply.c compiled with save-temps ' My compile line: gcc -c -save-temps -std=gnu99 -DHAVE_CONFIG_H -I../include -I../include -I/etc/pki/tls/include -c -o reply.o reply.c Make output: cc -save-temps -std=gnu99 -DHAVE_CONFIG_H -I../include -I../include -I/etc/pki/tls/include -O0 -MT reply.o -MD -MP -MF .deps/reply.Tpo -c -o reply.o reply.c -- joshuadfranklin at yahoo dot com changed: What|Removed |Added Attachment #17798|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40022
[Bug middle-end/40022] 4.4 regression breaks "reply to all" in alpine
--- Comment #5 from joshuadfranklin at yahoo dot com 2009-05-05 00:01 --- (In reply to comment #3) > That is the assembler that is produced not the preprocessed source, use > -save-temps and attach the .ii file. Sorry. Does this one look right? It's actually .c I typo'd the .cc. -- joshuadfranklin at yahoo dot com changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40022
[Bug middle-end/40021] [4.5 Regression] Revision 146817 miscompiled DAXPY in BLAS
--- Comment #5 from hjl dot tools at gmail dot com 2009-05-05 00:45 --- Created an attachment (id=17800) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17800&action=view) A testcase [...@gnu-33 pr40021]$ make /export/gnu/import/rrs/146817/usr/bin/gfortran -m32 -c -O2 -ftree-vectorize -msse2 -mfpmath=sse -ffast-math -ffixed-form test.f /export/gnu/import/rrs/146817/usr/bin/gfortran -m32 -Wl,-rpath,/export/gnu/import/rrs/146817/usr/lib -o daxpy test.o ./daxpy 2 -1. != -2. [...@gnu-33 pr40021]$ -- hjl dot tools at gmail dot com changed: What|Removed |Added Attachment #17797|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40021
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #8 from jv244 at cam dot ac dot uk 2009-05-05 04:18 --- (In reply to comment #6) > opt/gcc/gcc-4.5-work/gcc/testsuite/gfortran.dg/import6.f90:42.13: > > call func1(x) > 1 > Error: Type mismatch in argument 'param' at (1); passed TYPE(my_type) to > TYPE(my_type) that's a proper error as well, TYPE(my_type) needs to have the SEQUENCE attribute for this to be correct -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug c++/40013] [4.4/4.5 Regression] ICE when creating a local array with size from the return value of a member function of an object in a nested class in a template class
--- Comment #2 from jakub at gcc dot gnu dot org 2009-05-05 06:37 --- Subject: Bug 40013 Author: jakub Date: Tue May 5 06:37:05 2009 New Revision: 147119 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147119 Log: PR c++/40013 * pt.c (tsubst): If magic NOP_EXPR with side-effects has no type, set it from its operand's type after tsubst_expr. * g++.dg/ext/vla7.C: New test. Added: trunk/gcc/testsuite/g++.dg/ext/vla7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40013
[Bug c/40023] New: type mismatch in address expression
Hi, when i compiling Firefox trunk version, got error include .i file. TIA == gcc -o prscanf.o -c -fvisibility=hidden -Wall -pthread -O2 -fPIC -UDEBUG -DMOZILLA_CLIENT=1 -DNDEBUG=1 -DHAVE_VISIBILITY_HIDDEN_ATTRIBUTE=1 -DHAVE_VISIBILITY_PRAGMA=1 -DXP_UNIX=1 -D_GNU_SOURCE=1 -DHAVE_FCNTL_FILE_LOCKING=1 -DLINUX=1 -DHAVE_LCHOWN=1 -DHAVE_STRERROR=1 -D_REENTRANT=1 -DFORCE_PR_LOG -D_PR_PTHREADS -UHAVE_CVAR_BUILT_ON_SEM -D_NSPR_BUILD_ -I/home/use r/d/src/ff-opt/dist/include/nspr -I/home/user/d/src/nsprpub/pr/include -I/home/user/d/src/nsprpub/pr/include/private /home/user/d/src/nsprpub/pr/src/io/prscanf.c /home/user/d/src/nsprpub/pr/src/io/prscanf.c: In function : /home/user/d/src/nsprpub/pr/src/io/prscanf.c:669: error: type mismatch in address expression struct * struct [1] * D.5714 = &state->ap; /home/user/d/src/nsprpub/pr/src/io/prscanf.c:669: error: type mismatch in address expression struct * struct [1] * D.5714 = &state->ap; /home/user/d/src/nsprpub/pr/src/io/prscanf.c:669: error: type mismatch in address expression struct * struct [1] * D.5714 = &state->ap; /home/user/d/src/nsprpub/pr/src/io/prscanf.c:669: error: type mismatch in address expression struct * struct [1] * D.5714 = &state->ap; /home/user/d/src/nsprpub/pr/src/io/prscanf.c:669: error: type mismatch in address expression struct * struct [1] * D.5714 = &state->ap; /home/user/d/src/nsprpub/pr/src/io/prscanf.c:669: error: type mismatch in address expression struct * struct [1] * D.5714 = &state->ap; /home/user/d/src/nsprpub/pr/src/io/prscanf.c:669: error: type mismatch in address expression struct * struct [1] * D.5714 = &state->ap; /home/user/d/src/nsprpub/pr/src/io/prscanf.c:669: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. bash-4.0$ cc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr --libexecdir=/usr/lib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++ --disable-bootstrap --disable-multilib Thread model: posix gcc version 4.5.0 20090504 (experimental) (GCC) -- Summary: type mismatch in address expression Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: happyarch at gmail dot com GCC build triplet: x86_64 GCC host triplet: x86_64 GCC target triplet: x86_64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40023
[Bug c/40023] type mismatch in address expression
--- Comment #1 from happyarch at gmail dot com 2009-05-05 06:40 --- Created an attachment (id=17801) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17801&action=view) .i file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40023
[Bug c++/40013] [4.4/4.5 Regression] ICE when creating a local array with size from the return value of a member function of an object in a nested class in a template class
--- Comment #3 from jakub at gcc dot gnu dot org 2009-05-05 06:41 --- Subject: Bug 40013 Author: jakub Date: Tue May 5 06:41:33 2009 New Revision: 147120 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147120 Log: PR c++/40013 * pt.c (tsubst): If magic NOP_EXPR with side-effects has no type, set it from its operand's type after tsubst_expr. * g++.dg/ext/vla7.C: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/ext/vla7.C - copied unchanged from r147119, trunk/gcc/testsuite/g++.dg/ext/vla7.C Modified: branches/gcc-4_4-branch/gcc/cp/ChangeLog branches/gcc-4_4-branch/gcc/cp/pt.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40013
[Bug c++/40013] [4.4/4.5 Regression] ICE when creating a local array with size from the return value of a member function of an object in a nested class in a template class
--- Comment #4 from jakub at gcc dot gnu dot org 2009-05-05 06:47 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40013
[Bug fortran/39997] Procedure(), pointer & implicit typing: rejects-valid / accepts-invalid?
--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-04 07:11 --- Wrong comp.lang.fortran link; the correct one is: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/b3a7e94ddf6b8ff3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39997
[Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
--- Comment #10 from jv244 at cam dot ac dot uk 2009-05-04 07:12 --- This is the outermost stack trace to the segfault (with default 8M stack), shows the depth of the recursion, and the location: #174699 0x00528487 in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:337 #174700 0x00528487 in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:337 #174701 0x00528487 in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:337 #174702 0x00528487 in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:337 #174703 0x00528487 in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:337 #174704 0x00528487 in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:337 #174705 0x0052884d in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:213 #174706 0x005283e7 in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:315 #174707 0x00528831 in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:211 #174708 0x005283e7 in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:315 #174709 0x005283d9 in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:314 #174710 0x005283d9 in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:314 #174711 0x00528041 in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:457 #174712 0x005283e7 in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:315 #174713 0x00528519 in gt_ggc_mx_lang_tree_node (x_p=) at ./gt-fortran-f95-lang.h:291 #174714 0x006f6955 in gt_ggc_mx_cgraph_node (x_p=) at gtype-desc.c:228 #174715 0x006f6a76 in gt_ggc_m_P11cgraph_node4htab (x_p=) at gtype-desc.c:2142 #174716 0x006c0bce in ggc_mark_roots () at /data03/vondele/gcc_trunk/gcc/gcc/ggc-common.c:107 #174717 0x00572108 in ggc_collect () at /data03/vondele/gcc_trunk/gcc/gcc/ggc-page.c:1941 #174718 0x00543253 in gfc_generate_function_code (ns=0x3603e890) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-decl.c:4140 #174719 0x005298eb in gfc_generate_module_code (ns=) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans.c:1322 #174720 0x004f6404 in gfc_parse_file () at /data03/vondele/gcc_trunk/gcc/gcc/fortran/parse.c:3865 #174721 0x00526bbd in gfc_be_parse_file (set_yydebug=) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/f95-lang.c:236 #174722 0x007f39b4 in toplev_main (argc=13, argv=0x7fff5db02a88) at /data03/vondele/gcc_trunk/gcc/gcc/toplev.c:977 #174723 0x7f9454765436 in __libc_start_main () from /lib64/libc.so.6 #174724 0x00499679 in _start () -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
