[Bug fortran/37319] [4.4 regression] gfortran.dg/function_kinds_5.f90 fails
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2008-11-25 08:41 --- Subject: Bug 37319 Author: ebotcazou Date: Tue Nov 25 08:39:39 2008 New Revision: 142188 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142188 Log: PR fortran/37319 * parse.c (match_deferred_characteristics): Make sure 'name' is initialized before reading it. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/parse.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37319
[Bug fortran/37319] [4.4 regression] gfortran.dg/function_kinds_5.f90 fails
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2008-11-25 08:44 --- Patch installed. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37319
[Bug target/36793] x86-64 does not get __sync_synchronize right
--- Comment #11 from ubizjak at gmail dot com 2008-11-25 09:15 --- Should we fix __sync_synchronize in 4.3 too? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36793
[Bug target/38227] gcc fails to correctly pass arguments with ms_abi function pointers
--- Comment #5 from ktietz at gcc dot gnu dot org 2008-11-25 10:22 --- Created an attachment (id=16766) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16766action=view) improved patch file this fixes the callabi issues from sysv_abi-ms_abi. As Lankhorst told me, that there seems to be still problems in sysv_abi environment to call sysv_abi out of a ms_abi. Most of those problems are related to the problem, that get_callee_fn (in tree.c) isn't able to detect calls via pointer variables (VAR_DECL). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38227
[Bug middle-end/38151] structures with _Complex arguments are not passed correctly
--- Comment #28 from rguenth at gcc dot gnu dot org 2008-11-25 10:34 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38151
[Bug c++/38175] Explicit instantiation of a template hides symbols with the default visibility attribute
--- Comment #3 from j dot s dot wijnhout at lumc dot nl 2008-11-25 11:00 --- The problem is of course during linking, which fails. But why should I expect the following?: * Using TemplatedClass works just fine stand-alone. * Adding DependentTemplatedClass to the equation hides TemplatedClass effectively, causing a linker error. Why is this expected behavior? It sounds unreasonable to me or am I missing something? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38175
[Bug middle-end/37951] -ftree-parallelize-loops=2 fails for MA57
--- Comment #5 from dennis dot wassel at googlemail dot com 2008-11-25 11:26 --- gfortran also produces ICEs in this context: gfortran -O1 -fdump-tree-vect-details -ftree-vectorize -ftree-parallelize-loops=2 -c ma57.f ma57.f: In function 'ma57id': ma57.f:131: internal compiler error: Segmentation fault gfortran -O3 -fdump-tree-vect-details -ftree-vectorize -ftree-parallelize-loops=2 -c ma57.f ma57.f: In function 'ma57sd': ma57.f:1538: internal compiler error: Segmentation fault Throwing this into the debugger gives Starting program: /localdata/libexec/gcc/i686-pc-linux-gnu/4.3.2/f951 ma57.f -ffixed-form -quiet -dumpbase ma57.f -march=athlon64 -auxbase ma57 -O1 -fdump-tree-vect-details -ftree-vectorize -ftree-parallelize-loops=2 -fintrinsic-modules-path /localdata/bin/../lib/gcc/i686-pc-linux-gnu/4.3.2/finclude -o /tmp/ccWSWloU.s Failed to read a valid object file image from memory. Program received signal SIGSEGV, Segmentation fault. 0xb7ce06f9 in free () from /lib/tls/i686/cmov/libc.so.6 (gdb) bt #0 0xb7ce06f9 in free () from /lib/tls/i686/cmov/libc.so.6 #1 0xb7cdcf43 in _IO_free_backup_area () from /lib/tls/i686/cmov/libc.so.6 #2 0xb7cdafb2 in _IO_file_overflow () from /lib/tls/i686/cmov/libc.so.6 #3 0xb7cda51b in _IO_file_xsputn () from /lib/tls/i686/cmov/libc.so.6 #4 0xb7cb675f in vfprintf () from /lib/tls/i686/cmov/libc.so.6 #5 0xb7cbf2e2 in fprintf () from /lib/tls/i686/cmov/libc.so.6 #6 0x083a634e in vect_print_dump_info (vl=REPORT_DETAILS) at /localdata/install/gcc/gcc-4.3.2/gcc/tree-vectorizer.c:1503 #7 0x0839549a in vect_analyze_loop_form (loop=0xb796c370) at /localdata/install/gcc/gcc-4.3.2/gcc/tree-vect-analyze.c:4028 #8 0x0830475d in parallelize_loops () at /localdata/install/gcc/gcc-4.3.2/gcc/tree-parloops.c:280 #9 0x08355be5 in tree_parallelize_loops () at /localdata/install/gcc/gcc-4.3.2/gcc/tree-ssa-loop.c:486 #10 0x082466ea in execute_one_pass (pass=0x875c440) at /localdata/install/gcc/gcc-4.3.2/gcc/passes.c:1122 #11 0x082469ef in execute_pass_list (pass=0x875c440) at /localdata/install/gcc/gcc-4.3.2/gcc/passes.c:1175 #12 0x08246a10 in execute_pass_list (pass=0x875c100) at /localdata/install/gcc/gcc-4.3.2/gcc/passes.c:1176 #13 0x08246a10 in execute_pass_list (pass=0x875b900) at /localdata/install/gcc/gcc-4.3.2/gcc/passes.c:1176 #14 0x082fe85a in tree_rest_of_compilation (fndecl=0xb7bda380) at /localdata/install/gcc/gcc-4.3.2/gcc/tree-optimize.c:404 #15 0x084081fd in cgraph_expand_function (node=0xb7b87300) at /localdata/install/gcc/gcc-4.3.2/gcc/cgraphunit.c:1157 #16 0x08408cc5 in cgraph_optimize () at /localdata/install/gcc/gcc-4.3.2/gcc/cgraphunit.c:1220 #17 0x080e7c95 in gfc_be_parse_file (set_yydebug=0) at /localdata/install/gcc/gcc-4.3.2/gcc/fortran/f95-lang.c:264 #18 0x082ca6f8 in toplev_main (argc=17, argv=0xbfe09354) at /localdata/install/gcc/gcc-4.3.2/gcc/toplev.c:1042 #19 0x08127aff in main (argc=Cannot access memory at address 0xb72d8ff8 ) at /localdata/install/gcc/gcc-4.3.2/gcc/main.c:35 If I remove -march=athlon64 flag, f951 just hangs/waits without causing any CPU load. Trying to backtrace what it is doing does not give anything meaningful (at least to me): Starting program: /localdata/libexec/gcc/i686-pc-linux-gnu/4.3.2/f951 ma57.f -ffixed-form -quiet -dumpbase ma57.f -auxbase ma57 -O1 -fdump-tree-vect-details -ftree-vectorize -ftree-parallelize-loops=2 -fintrinsic-modules-path /localdata/bin/../lib/gcc/i686-pc-linux-gnu/4.3.2/finclude -o /tmp/ccWSWloU.s Failed to read a valid object file image from memory. Program received signal SIGINT, Interrupt. 0xb7f34410 in ?? () (gdb) bt #0 0xb7f34410 in ?? () #1 0xbfd446e8 in ?? () #2 0x0002 in ?? () #3 0x in ?? () Hope this helps! -- dennis dot wassel at googlemail dot com changed: What|Removed |Added Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37951
[Bug middle-end/38151] structures with _Complex arguments are not passed correctly
--- Comment #29 from rguenth at gcc dot gnu dot org 2008-11-25 10:35 --- Subject: Bug 38151 Author: rguenth Date: Tue Nov 25 10:34:11 2008 New Revision: 142189 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142189 Log: 2008-11-25 Richard Guenther [EMAIL PROTECTED] PR middle-end/38151 PR middle-end/38236 * tree-ssa-alias.c (struct alias_info): Remove written_vars. Remove dereferenced_ptrs_store and dereferenced_ptrs_load in favor of dereferenced_ptrs. (init_alias_info): Adjust. (delete_alias_info): Likewise. (compute_flow_insensitive_aliasing): Properly include all aliased variables. (update_alias_info_1): Use dereferenced_ptrs. (setup_pointers_and_addressables): Likewise. (get_smt_for): Honor ref-all pointers and pointers with known alias set properly. * config/i386/i386.c (ix86_gimplify_va_arg): Use ref-all pointers. * gcc.c-torture/execute/pr38151.c: New testcase. * gcc.c-torture/execute/pr38236.c: Likewise. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr38151.c trunk/gcc/testsuite/gcc.c-torture/execute/pr38236.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-alias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38151
[Bug middle-end/38236] [4.4 Regression] SMT aliases incomplete
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-11-25 10:35 --- Subject: Bug 38236 Author: rguenth Date: Tue Nov 25 10:34:11 2008 New Revision: 142189 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142189 Log: 2008-11-25 Richard Guenther [EMAIL PROTECTED] PR middle-end/38151 PR middle-end/38236 * tree-ssa-alias.c (struct alias_info): Remove written_vars. Remove dereferenced_ptrs_store and dereferenced_ptrs_load in favor of dereferenced_ptrs. (init_alias_info): Adjust. (delete_alias_info): Likewise. (compute_flow_insensitive_aliasing): Properly include all aliased variables. (update_alias_info_1): Use dereferenced_ptrs. (setup_pointers_and_addressables): Likewise. (get_smt_for): Honor ref-all pointers and pointers with known alias set properly. * config/i386/i386.c (ix86_gimplify_va_arg): Use ref-all pointers. * gcc.c-torture/execute/pr38151.c: New testcase. * gcc.c-torture/execute/pr38236.c: Likewise. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr38151.c trunk/gcc/testsuite/gcc.c-torture/execute/pr38236.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-alias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38236
[Bug tree-optimization/37869] PTA results wrong for non-pointer variables
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-11-25 11:58 ---
Simpler testcase at -O
void
foo (unsigned long *start, unsigned long *end)
{
unsigned long *temp = end - 1;
while (end start)
*end-- = *temp--;
}
blocks alias-improvements branch (causes the store and load to be deleted).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37869
[Bug middle-end/38236] [4.4 Regression] SMT aliases incomplete
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-11-25 10:34 --- 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=38236
[Bug tree-optimization/37869] PTA results wrong for non-pointer variables
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-11-25 12:22 ---
On the branch I am installing the following as a stop-gap measure:
Index: tree-ssa-structalias.c
===
--- tree-ssa-structalias.c (revision 142149)
+++ tree-ssa-structalias.c (working copy)
@@ -230,6 +230,9 @@ struct variable_info
variable. This is used for C++ placement new. */
unsigned int no_tbaa_pruning : 1;
+ /* If found to be a non-pointer variable. */
+ unsigned int is_nonpointer_var : 1;
+
/* Variable id this was collapsed to due to type unsafety. Zero if
this variable was not collapsed. This should be unused completely
after build_succ_graph, or something is broken. */
@@ -377,6 +380,7 @@ new_var_info (tree t, unsigned int id, c
ret-is_special_var = false;
ret-is_unknown_size_var = false;
ret-is_full_var = false;
+ ret-is_nonpointer_var = false;
var = t;
if (TREE_CODE (var) == SSA_NAME)
var = SSA_NAME_VAR (var);
@@ -2175,6 +2179,7 @@ perform_var_substitution (constraint_gra
%s is a non-pointer variable, eliminating edges.\n,
get_varinfo (node)-name);
stats.nonpointer_vars++;
+ get_varinfo (i)-is_nonpointer_var = true;
clear_edges_for_node (graph, node);
}
}
@@ -4752,6 +4755,11 @@ find_what_p_points_to (tree p)
if (vi-is_artificial_var)
return false;
+ /* ??? Some real variables get eliminated as non-pointers.
+Workaround this. See PR37869. */
+ if (vi-is_nonpointer_var)
+ return false;
+
/* See if this is a field or a structure. */
if (vi-size != vi-fullsize)
{
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37869
[Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf
--- Comment #11 from tehila at il dot ibm dot com 2008-11-25 12:17 --- (In reply to comment #10) If you only get slow compilation at -O2 and above then your problem is probably due to PR 37790. The original problem affected -O1 compiles as well as -O2. PR 37790 doesn't solve the problem I see. On SPU, with -O1 and -O2 -fno-schedule-insns the compilation time is long (timed out == more than 5 minutes), but it's not as long as with -O2: -O1 - 9.5 minutes. -O2 -fno-schedule-insns - 10.5 minutes -O2 - 1000m I don't know what can be done in order to improve compilation time on SPU, but for sure - there is a problem in the insns shceduler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31850
[Bug fortran/38248] Ignored temporary module files manipulation errors
--- Comment #4 from burnus at gcc dot gnu dot org 2008-11-25 12:53 --- Subject: Bug 38248 Author: burnus Date: Tue Nov 25 12:51:44 2008 New Revision: 142190 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142190 Log: 2008-11-25 Jan Kratochvil [EMAIL PROTECTED] PR fortran/38248 * module.c (gfc_dump_module): Check rename/unlink syscalls errors. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38248
[Bug fortran/38259] New: Add version number to .mod file
Currently, there are only strange parenthesis-related error messages given if an old, incompatible .mod file is used with a newer compiler, e.g. Fatal Error: Reading module mmm at line 16 column 65: Expected left parenthesis (cf. also PR 38248). The solution is to add a version number which is always bumped if a .mod related change happened, which presumably was the case for all new GCC/gfortran releases. -- Summary: Add version number to .mod file 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=38259
[Bug fortran/36463] [4.4 regression] gfc_get_default_type(): Bad symbol
--- Comment #18 from mikael at gcc dot gnu dot org 2008-11-25 13:28 --- Subject: Bug 36463 Author: mikael Date: Tue Nov 25 13:27:26 2008 New Revision: 142191 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142191 Log: 2008-11-25 Mikael Morin [EMAIL PROTECTED] PR fortran/36463 * expr.c (replace_symbol): Don't replace the symtree if the expresion is an intrinsic function. Don't create non-existent symtrees. Use symbol's name instead of symtree's, different in case of module procedure dummy arguments. 2008-11-25 Mikael Morin [EMAIL PROTECTED] PR fortran/36463 * gfortran.dg/proc_decl_20.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/proc_decl_20.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36463
[Bug target/31850] gcc.c-torture/compile/limits-fnargs.c is slow at compiling for spu-elf
--- Comment #12 from abel at gcc dot gnu dot org 2008-11-25 14:28 --- I have somewhat cut the testcase, having the call with two ARG3's instead of ten coming from ARG4. With this smaller testcase, I see that the most time is taken by register renaming (cross to spu-elf, compiled with -O2): scheduling: 0.66 ( 2%) usr 0.03 (30%) sys 0.69 ( 2%) wall 19208 kB (32%) ggc integrated RA : 4.55 (11%) usr 0.00 ( 0%) sys 4.53 (11%) wall 829 kB ( 1%) ggc reload: 2.57 ( 6%) usr 0.01 (10%) sys 2.58 ( 6%) wall 11996 kB (20%) ggc reload CSE regs : 0.23 ( 1%) usr 0.00 ( 0%) sys 0.22 ( 1%) wall 2940 kB ( 5%) ggc peephole 2: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc rename registers : 32.21 (76%) usr 0.01 (10%) sys 32.22 (75%) wall 993 kB ( 2%) ggc scheduling 2 : 0.58 ( 1%) usr 0.03 (30%) sys 0.61 ( 1%) wall 5375 kB ( 9%) ggc machine dep reorg : 0.59 ( 1%) usr 0.01 (10%) sys 0.60 ( 1%) wall 5569 kB ( 9%) ggc final : 0.04 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall 0 kB ( 0%) ggc TOTAL : 42.59 0.1042.71 59919 kB With -O2 -fno-rename-registers, I get scheduling: 0.66 ( 6%) usr 0.04 (36%) sys 0.70 ( 7%) wall 19208 kB (33%) ggc integrated RA : 4.56 (45%) usr 0.00 ( 0%) sys 4.57 (44%) wall 829 kB ( 1%) ggc reload: 2.58 (25%) usr 0.00 ( 0%) sys 2.59 (25%) wall 11996 kB (21%) ggc reload CSE regs : 0.23 ( 2%) usr 0.00 ( 0%) sys 0.24 ( 2%) wall 2940 kB ( 5%) ggc thread pro- epilogue: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 22 kB ( 0%) ggc peephole 2: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 0 kB ( 0%) ggc rename registers : 0.04 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 0 kB ( 0%) ggc scheduling 2 : 0.49 ( 5%) usr 0.04 (36%) sys 0.52 ( 5%) wall 4949 kB ( 9%) ggc machine dep reorg : 0.50 ( 5%) usr 0.02 (18%) sys 0.51 ( 5%) wall 5055 kB ( 9%) ggc reorder blocks: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 0 kB ( 0%) ggc final : 0.05 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall 0 kB ( 0%) ggc TOTAL : 10.21 0.1110.35 57732 kB -frename-registers is enabled by default on spu, so no wonder this is not seen on other targets. oprofile shows me this: Samples %linenr info image name app name symbol name --- 362678 29.6888 rtlanal.c:1412 cc1 cc1 note_stores 362678 100.000 rtlanal.c:1412 cc1 cc1 note_stores [self] --- 304520 24.9280 regrename.c:1941cc1 cc1 rest_of_handle_regrename 304520 99.8727 regrename.c:1941cc1 cc1 rest_of_handle_regrename [self] 201 0.0659 bitmap.c:630cc1 cc1 bitmap_set_bit 990.0325 df-scan.c:1217 cc1 cc1 df_insn_rescan 390.0128 df-problems.c:107 cc1 cc1 df_grow_bb_info 240.0079 (no location information) cc1 cc1 bitmap_clear_bit 170.0056 df-scan.c:573 cc1 cc1 df_grow_reg_info 8 0.0026 emit-rtl.c:1131 cc1 cc1 max_reg_num --- 164550 13.4701 regrename.c:120 cc1 cc1 clear_dead_regs 164550 100.000 regrename.c:120 cc1 cc1 clear_dead_regs [self] --- 6441 100.000 ira-color.c:1044cc1 cc1 allocno_spill_priority_compare 59894 4.9029 ira-color.c:1044cc1 cc1 allocno_spill_priority_compare 5989486.6547 ira-color.c:1044cc1 cc1 allocno_spill_priority_compare [self] 6441 9.3188 ira-color.c:1044cc1 cc1 allocno_spill_priority_compare 1148 1.6609 splay-tree.c:348cc1
[Bug c++/36410] [4.2/4.3 Regression] ICE with transparent union
--- Comment #6 from zhiyin at maths dot tcd dot ie 2008-11-25 14:51 --- Fix in 4.3 much appreciated. Thank you. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36410
[Bug c++/38260] New: vector_size attribute vs specialization
Take:
#define vf4 __attribute__((vector_size(16) )) float
template class T inline T Abs( const T A )
{
return (A=(T)0) ? A : -A;
}
template inline vf4 Abs( const vf4 A) { }
-- CUT ---
If we change vf4 to be a typedef it works.
--
Summary: vector_size attribute vs specialization
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38260
[Bug middle-end/37843] [4.4 Regression] unaligned stack in main due to tail call optimization
--- Comment #8 from hjl at gcc dot gnu dot org 2008-11-25 15:34 --- Subject: Bug 37843 Author: hjl Date: Tue Nov 25 15:33:27 2008 New Revision: 142193 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142193 Log: gcc/ 2008-11-25 H.J. Lu [EMAIL PROTECTED] Joey Ye [EMAIL PROTECTED] PR middle-end/37843 * config/i386/i386.c (ix86_function_ok_for_sibcall): Return false if we need to align the outgoing stack. (ix86_update_stack_boundary): Check parm_stack_boundary. gcc/testsuite/ 2008-11-25 H.J. Lu [EMAIL PROTECTED] PR middle-end/37843 * gcc.target/i386/align-main-3.c: New. * gcc.target/i386/pr37843-1.c: Likewise. * gcc.target/i386/pr37843-2.c: Likewise. * gcc.target/i386/pr37843-3.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/i386/align-main-3.c trunk/gcc/testsuite/gcc.target/i386/pr37843-1.c trunk/gcc/testsuite/gcc.target/i386/pr37843-2.c trunk/gcc/testsuite/gcc.target/i386/pr37843-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37843
[Bug tree-optimization/38261] New: [4.4 regression] gcc.dg/torture/ipa-pta-1.c gcc.dg/tree-ssa/alias-2.c fail with -fpic/-fPIC
The testcases gcc.dg/torture/ipa-pta-1.c and gcc.dg/tree-ssa/alias-2.c used to work with -fpic/-fPIC on the trunk, but now fail. The alias-2.c testcase worked in 4.2, 4.3 with -fpic/-fPIC also, and the testcase doesn't appear to have changed. I think ipa-pta-1.c was added only on the trunk a few months ago so there's no comparison with previous releases, however it did work on the trunk up until very recently. They both passed here: http://gcc.gnu.org/ml/gcc-testresults/2008-11/msg01383.html And they both started failing here: http://gcc.gnu.org/ml/gcc-testresults/2008-11/msg01516.html Based on the timing, I suspect that the cause is related. -- Summary: [4.4 regression] gcc.dg/torture/ipa-pta-1.c gcc.dg/tree-ssa/alias-2.c fail with -fpic/-fPIC Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org GCC target triplet: x86_64-*-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38261
[Bug bootstrap/38262] New: [4.4 regression] GCC components unnecessarily link with shared gmp/mpfr
As noted here: http://gcc.gnu.org/ml/gcc/2008-11/msg00234.html various components of GCC (xgcc, gcov, etc) are linking unnecessarily with gmp/mpfr. I believe we only need to do that for executables linked against libbackend.a (like cc1). The result is exposed when gmp/mpfr are shared libraries and appear in the ldd output. This bug was previously fixed in PR35107 but regressed during the graphite merge. http://gcc.gnu.org/viewcvs/trunk/gcc/Makefile.in?r1=139854r2=139893 -- Summary: [4.4 regression] GCC components unnecessarily link with shared gmp/mpfr Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org BugsThisDependsOn: 35107 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38262
[Bug bootstrap/38262] [4.4 regression] GCC components unnecessarily link with shared gmp/mpfr
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38262
[Bug testsuite/38263] New: gcc.dg/ipa/ipacost-2.c fails with -fpic/-fPIC
The testcase gcc.dg/ipa/ipacost-2.c fails with -fpic/-fPIC, and has been doing so since it was added to the testsuite back in August. August results: http://gcc.gnu.org/ml/gcc-testresults/2008-08/msg02784.html Current results: http://gcc.gnu.org/ml/gcc-testresults/2008-11/msg02234.html Is this test something that should work with -fpic/-fPIC? Could it pass if some function were made static and/or it was compiled with -fpie? Or does it indicate a bug in the compiler? -- Summary: gcc.dg/ipa/ipacost-2.c fails with -fpic/-fPIC Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38263
[Bug c++/36410] [4.2/4.3 Regression] ICE with transparent union
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-11-25 16:31 --- IMHO a backport is not needed for error-recovery bugs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36410
[Bug tree-optimization/38261] [4.4 Regression] gcc.dg/torture/ipa-pta-1.c gcc.dg/tree-ssa/alias-2.c fail with -fpic/-fPIC
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.4 regression]|[4.4 Regression] |gcc.dg/torture/ipa-pta-1.c |gcc.dg/torture/ipa-pta-1.c |gcc.dg/tree-ssa/alias-2.c |gcc.dg/tree-ssa/alias-2.c |fail with -fpic/-fPIC |fail with -fpic/-fPIC Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38261
[Bug libgcj/38251] [4.4 Regression] tools.zip doesn't build on systems with short command lines
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38251
[Bug middle-end/38074] [4.4 Regression] missed inlining since IRA merge on Core2 Duo
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||missed-optimization Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38074
[Bug testsuite/38036] [4.4 Regression][AVR] FAIL: gcc.c-torture/execute/pr37573.c execution
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38036
[Bug ada/37681] [4.4 Regression] Building 64-bit libada fails on Solaris/x86: alignment error
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-11-25 16:34 --- So, this is fixed now? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|enhancement |normal Summary|[4.4 regression] Building |[4.4 Regression] Building |64-bit libada fails on |64-bit libada fails on |Solaris/x86: alignment error|Solaris/x86: alignment error Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37681
[Bug tree-optimization/38261] [4.4 Regression] gcc.dg/torture/ipa-pta-1.c gcc.dg/tree-ssa/alias-2.c fail with -fpic/-fPIC
--- Comment #1 from hjl dot tools at gmail dot com 2008-11-25 16:37 --- Can you use ./contrib/gcc_update to update your gcc source tree so that we can tell which revisions you are using? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38261
[Bug ada/37681] [4.4 Regression] Building 64-bit libada fails on Solaris/x86: alignment error
-- ro at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ro at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-09-30 15:01:45 |2008-11-25 17:07:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37681
[Bug ada/37681] [4.4 Regression] Building 64-bit libada fails on Solaris/x86: alignment error
--- Comment #12 from ro at gcc dot gnu dot org 2008-11-25 17:08 --- Fixed for 4.4.0. (Sorry for not updating the PR.) -- ro at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37681
[Bug c++/36410] [4.2/4.3 Regression] ICE with transparent union
--- Comment #8 from jason at redhat dot com 2008-11-25 17:35 ---
Subject: Re: [4.2/4.3 Regression] ICE with transparent union
rguenth at gcc dot gnu dot org wrote:
IMHO a backport is not needed for error-recovery bugs.
This is not an error-recovery bug, the patch makes us accept it.
That said, it's probably simpler to fix your code: changing
typedef union
{
int i;
} B __attribute__((transparent_union));
typedef union
{
int i;
} __attribute__((transparent_union)) B;
will work with 4.3.2. So yeah, no backport seems needed.
Jason
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36410
[Bug middle-end/38264] New: tree_forwarder_block_p says no to first basic block
tree_forwarder_block_p has if (find_edge (ENTRY_BLOCK_PTR, bb)) return false; without explanation. This test was added by you, Jeff - do you remember why? Removing this check triggers some ICEs in the testsuite because remove_bb (called from remove_forwarder_block) unconditionally moves labels from the removed block to prev_bb (yuck!) - which is of course invalid if that happens to be the entry bb. Luckily remove_forwarder_block already contains code to do the label-move job itself - it is just conditional on seen abnormal incoming edges. Enabling this code to run by default causes a bootstrap comparison failure though. -- Summary: tree_forwarder_block_p says no to first basic block Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38264
[Bug middle-end/38264] tree_forwarder_block_p says no to first basic block
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-11-25 19:11 --- Created an attachment (id=16767) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16767action=view) patch Patch that miscompares. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38264
[Bug c++/38265] New: STL treats explicit constructors as converting constructors
When some STL containers are created, explicit constructors for contained
objects are treated as converting constructors. The keyword explicit is
ignored, and no error message is issued; see the code.
#include vector
#include deque
class X {
public:
explicit X(int) {}
};
int main() {
int a[1] = {};
std::vectorX v(a, a + 1);
std::dequeX d(a, a + 1);
}
--
Summary: STL treats explicit constructors as converting
constructors
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: konto dot dydaktyczne at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38265
[Bug c++/38266] New: improper fix to curses.h on irix
When I try to compile code that include curses.h on IRIX, g++ chokes on the fixed curses.h, producing errors like: /appl/local_sde_dev/IRIX64-6.5/gcc-4.3.2/bin/../lib/gcc/mips-sgi-irix6.5/4.3.2/include-fixed/curses.h:1294: error: declaration of C function 'int mvwprintw(WINDOW*, int, int, ...)' conflicts with /appl/local_sde_dev/IRIX64-6.5/gcc-4.3.2/bin/../lib/gcc/mips-sgi-irix6.5/4.3.2/include-fixed/curses.h:300: error: previous declaration 'int mvwprintw(WINDOW*, int, int, char*, ...)' here -- Summary: improper fix to curses.h on irix Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Jay dot St dot Pierre at Colorado dot EDU GCC build triplet: mips-sgi-irix6.5 GCC host triplet: mips-sgi-irix6.5 GCC target triplet: mips-sgi-irix6.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38266
[Bug c++/38266] improper fix to curses.h on irix
--- Comment #1 from Jay dot St dot Pierre at Colorado dot EDU 2008-11-25 19:31 --- Created an attachment (id=16768) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16768action=view) Test file that includes curses.h I compile this with g++ z.c -o z -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38266
[Bug middle-end/38267] New: rtl epilogues worse than non-rtl epilogues for dbr scheduling
The rtl epilogues are inserted after the USE which indicates where the return value is. As a result, an instruction that calculates the return value cannot be placed in the delay slot of the return instruction. That is something that we did get right when we had non-rtl epilogues - the epilogue_delay could well contain an insn to calculate the function result. -- Summary: rtl epilogues worse than non-rtl epilogues for dbr scheduling Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38267
[Bug c++/38266] improper fix to curses.h on irix
--- Comment #2 from Jay dot St dot Pierre at Colorado dot EDU 2008-11-25 19:34 --- Created an attachment (id=16769) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16769action=view) The fixed curses.h produced by the build of gcc-4.3.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38266
[Bug c++/38265] STL treats explicit constructors as converting constructors
--- Comment #1 from cfairles at gcc dot gnu dot org 2008-11-25 19:34 --- GCC 4.4.0 also accepts this code as does Comeau 4.3.10.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38265
[Bug libstdc++/38265] STL treats explicit constructors as converting constructors
--- Comment #2 from paolo dot carlini at oracle dot com 2008-11-25 19:48 --- Unless I'm badly mistaken, this behaviour, dating back to the original HP/SGI STL and as such very difficult to change now, is a small extension due to the use in the containers of _Construct instead of calling allocator::construct directly. All in all, at the moment I don't think we have good reasons to change it. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Component|c++ |libstdc++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38265
[Bug middle-end/38264] tree_forwarder_block_p says no to first basic block
--- Comment #2 from law at redhat dot com 2008-11-25 20:04 --- Subject: Re: New: tree_forwarder_block_p says no to first basic block rguenth at gcc dot gnu dot org wrote: tree_forwarder_block_p has if (find_edge (ENTRY_BLOCK_PTR, bb)) return false; without explanation. This test was added by you, Jeff - do you remember why? Removing this check triggers some ICEs in the testsuite because remove_bb (called from remove_forwarder_block) unconditionally moves labels from the removed block to prev_bb (yuck!) - which is of course invalid if that happens to be the entry bb. Luckily remove_forwarder_block already contains code to do the label-move job itself - it is just conditional on seen abnormal incoming edges. Enabling this code to run by default causes a bootstrap comparison failure though. I'm not sure -- that code was introduced in 2003 and looks like it was a mix of some of Zdenek's work as well as mine. It could well have been the label issue, or some horrid problem dealing with our control structures (which were still in the IL at that time), or simply my mis-translation of some of Zdenek's code. Clearly remove_bb has to do something with the labels. I think it was decided that the labels could go anywhere and the previous block reasonably convenient -- the theory was the block was unreachable, so the location of a named label in the block was unimportant. In the case of a forwarder block the label was reachable and needs to be moved into a sane location -- removal of forwarder blocks probably wasn't something we considered when discussing the named label issues. Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38264
[Bug tree-optimization/26850] unused function not eliminated with -fwhole-program --combine
--- Comment #3 from alexandre dot nunes at gmail dot com 2008-11-25 20:01 --- Still fails as of gcc 4.3.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26850
Re: [Bug bootstrap/38262] New: [4.4 regression] GCC components unnecessarily link with shared gmp/mpfr
Here is a patch from Dwarak for fixing this. He will send this to review on gcc-patches@ list. Sebastian Pop -- AMD - GNU Tools --- Makefile.in 2008-10-23 10:33:51.274495000 -0500 +++ Makefile.in.fix 2008-11-19 16:11:55.80298 -0600 @@ -903,8 +903,9 @@ BUILD_LIBDEPS=3D $(BUILD_LIBIBERTY) # How to link with both our special library facilities # and the system's installed libraries. -LIBS =3D @LIBS@ $(CPPLIB) $(LIBINTL) $(LIBICONV) $(LIBIBERTY) $(LIBDECNUMBER) \ - $(GMPLIBS) $(CLOOGLIBS) $(PPLLIBS) +LIBS =3D @LIBS@ $(CPPLIB) $(LIBINTL) $(LIBICONV) $(LIBIBERTY) $(LIBDECNUMBER)=20 + +BACKENDLIBS =3D $(GMPLIBS) $(CLOOGLIBS) $(PPLLIBS) # Any system libraries needed just for GNAT. SYSLIBS =3D @GNAT_LIBEXC@ @@ -1613,7 +1614,7 @@ libbackend.a: $([EMAIL PROTECTED]@) xgcc$(exeext): $(GCC_OBJS) gccspec.o version.o intl.o prefix.o \ version.o $(LIBDEPS) $(EXTRA_GCC_OBJS) $(CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ $(GCC_OBJS) gccspec.o \ - intl.o prefix.o version.o $(EXTRA_GCC_OBJS) $(LIBS) + intl.o prefix.o version.o $(EXTRA_GCC_OBJS) $(LIBS) $(BACKENDLIBS) # cpp is to cpp0 as gcc is to cc1. # The only difference from xgcc is that it's linked with cppspec.o @@ -1621,7 +1622,7 @@ xgcc$(exeext): $(GCC_OBJS) gccspec.o ver cpp$(exeext): $(GCC_OBJS) cppspec.o version.o intl.o prefix.o \ version.o $(LIBDEPS) $(EXTRA_GCC_OBJS) $(CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ $(GCC_OBJS) cppspec.o \ - intl.o prefix.o version.o $(EXTRA_GCC_OBJS) $(LIBS) + intl.o prefix.o version.o $(EXTRA_GCC_OBJS) $(LIBS) $(BACKENDLIBS) # Dump a specs file to make -B./ read these specs over installed ones. $(SPECS): xgcc$(exeext) @@ -1638,7 +1639,7 @@ dummy-checksum.o : dummy-checksum.c cc1-dummy$(exeext): $(C_OBJS) dummy-checksum.o $(BACKEND) $(LIBDEPS) $(CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ $(C_OBJS) dummy-checksum.o \ - $(BACKEND) $(LIBS) $(GMPLIBS) + $(BACKEND) $(LIBS) $(BACKENDLIBS) cc1-checksum.c : cc1-dummy$(exeext) build/genchecksum$(build_exeext) build/genchecksum$(build_exeext) cc1-dummy$(exeext) $@ @@ -1647,7 +1648,7 @@ cc1-checksum.o : cc1-checksum.c cc1$(exeext): $(C_OBJS) cc1-checksum.o $(BACKEND) $(LIBDEPS) $(CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ $(C_OBJS) cc1-checksum.o \ - $(BACKEND) $(LIBS) $(GMPLIBS) + $(BACKEND) $(LIBS) $(BACKENDLIBS) # # Build libgcc.a.
[Bug bootstrap/38262] [4.4 regression] GCC components unnecessarily link with shared gmp/mpfr
--- Comment #1 from sebpop at gmail dot com 2008-11-25 20:25 --- Subject: Re: New: [4.4 regression] GCC components unnecessarily link with shared gmp/mpfr Here is a patch from Dwarak for fixing this. He will send this to review on gcc-patches@ list. Sebastian Pop -- AMD - GNU Tools --- Makefile.in 2008-10-23 10:33:51.274495000 -0500 +++ Makefile.in.fix 2008-11-19 16:11:55.80298 -0600 @@ -903,8 +903,9 @@ BUILD_LIBDEPS=3D $(BUILD_LIBIBERTY) # How to link with both our special library facilities # and the system's installed libraries. -LIBS =3D @LIBS@ $(CPPLIB) $(LIBINTL) $(LIBICONV) $(LIBIBERTY) $(LIBDECNUMBER) \ - $(GMPLIBS) $(CLOOGLIBS) $(PPLLIBS) +LIBS =3D @LIBS@ $(CPPLIB) $(LIBINTL) $(LIBICONV) $(LIBIBERTY) $(LIBDECNUMBER)=20 + +BACKENDLIBS =3D $(GMPLIBS) $(CLOOGLIBS) $(PPLLIBS) # Any system libraries needed just for GNAT. SYSLIBS =3D @GNAT_LIBEXC@ @@ -1613,7 +1614,7 @@ libbackend.a: $([EMAIL PROTECTED]@) xgcc$(exeext): $(GCC_OBJS) gccspec.o version.o intl.o prefix.o \ version.o $(LIBDEPS) $(EXTRA_GCC_OBJS) $(CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ $(GCC_OBJS) gccspec.o \ - intl.o prefix.o version.o $(EXTRA_GCC_OBJS) $(LIBS) + intl.o prefix.o version.o $(EXTRA_GCC_OBJS) $(LIBS) $(BACKENDLIBS) # cpp is to cpp0 as gcc is to cc1. # The only difference from xgcc is that it's linked with cppspec.o @@ -1621,7 +1622,7 @@ xgcc$(exeext): $(GCC_OBJS) gccspec.o ver cpp$(exeext): $(GCC_OBJS) cppspec.o version.o intl.o prefix.o \ version.o $(LIBDEPS) $(EXTRA_GCC_OBJS) $(CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ $(GCC_OBJS) cppspec.o \ - intl.o prefix.o version.o $(EXTRA_GCC_OBJS) $(LIBS) + intl.o prefix.o version.o $(EXTRA_GCC_OBJS) $(LIBS) $(BACKENDLIBS) # Dump a specs file to make -B./ read these specs over installed ones. $(SPECS): xgcc$(exeext) @@ -1638,7 +1639,7 @@ dummy-checksum.o : dummy-checksum.c cc1-dummy$(exeext): $(C_OBJS) dummy-checksum.o $(BACKEND) $(LIBDEPS) $(CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ $(C_OBJS) dummy-checksum.o \ - $(BACKEND) $(LIBS) $(GMPLIBS) + $(BACKEND) $(LIBS) $(BACKENDLIBS) cc1-checksum.c : cc1-dummy$(exeext) build/genchecksum$(build_exeext) build/genchecksum$(build_exeext) cc1-dummy$(exeext) $@ @@ -1647,7 +1648,7 @@ cc1-checksum.o : cc1-checksum.c cc1$(exeext): $(C_OBJS) cc1-checksum.o $(BACKEND) $(LIBDEPS) $(CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ $(C_OBJS) cc1-checksum.o \ - $(BACKEND) $(LIBS) $(GMPLIBS) + $(BACKEND) $(LIBS) $(BACKENDLIBS) # # Build libgcc.a. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38262
[Bug tree-optimization/37869] PTA results wrong for non-pointer variables
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-11-25 20:29 --- Subject: Bug 37869 Author: rguenth Date: Tue Nov 25 20:27:44 2008 New Revision: 142202 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142202 Log: 2008-11-25 Richard Guenther [EMAIL PROTECTED] * tree-data-ref.c (dr_may_alias_p): Use the alias-oracle. * tree-tailcall.c (tree_optimize_tail_calls_1): Also split the edge from the entry block if we have degenerate PHI nodes in the first basic block. * gimple.c (gimple_set_bb): Fix off-by-one error. * tree-cfg.c (move_block_to_fn): Likewise. PR tree-optimization/37869 * tree-ssa-structalias.c (struct variable_info): Add is_nonpointer_var flag. (new_var_info): Clear it. (perform_var_substitution): Set it. (find_what_p_points_to): Use it. Modified: branches/alias-improvements/gcc/ChangeLog.alias branches/alias-improvements/gcc/gimple.c branches/alias-improvements/gcc/tree-cfg.c branches/alias-improvements/gcc/tree-data-ref.c branches/alias-improvements/gcc/tree-ssa-structalias.c branches/alias-improvements/gcc/tree-tailcall.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37869
[Bug tree-optimization/37869] PTA results wrong for non-pointer variables
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-11-25 21:23 ---
Testcase from comment #1 has wrong points-to sets on the trunk as well (-O).
end = NONLOCAL
temp_4 = end
end_7 = end_1
temp_8 = temp_2
end_1 = end
end_1 = end_7
temp_2 = temp_4
temp_2 = temp_8
...
end_7 is a non-pointer variable, eliminating edges.
end_7 is a non-pointer variable, eliminating edges.
end_7 is a non-pointer variable,ignoring constraint:end_7 = end_1
end_1 is a non-pointer variable,ignoring constraint:end_1 = end
end_1 is a non-pointer variable,ignoring constraint:end_1 = end_7
...
end_7 = { }
end_1 = { }
...
bb 2:
temp_4 = end_3(D) + -4;
goto bb 4;
bb 3:
D.1238_6 = *temp_2;
*end_1 = D.1238_6;
end_7 = end_1 + -4;
temp_8 = temp_2 + -4;
bb 4:
# end_1 = PHI end_3(D)(2), end_7(3)
# temp_2 = PHI temp_4(2), temp_8(3)
if (end_1 start_5(D))
goto bb 3;
else
goto bb 5;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37869
[Bug tree-optimization/37869] PTA results wrong for non-pointer variables
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-11-25 21:45 ---
Simpler testcase:
void
foo (unsigned long *end)
{
unsigned long *temp = end - 1;
while (1)
*end-- = *temp;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37869
[Bug fortran/38268] New: gfortran doesn't link any 64 bits binaries on Solaris
tchaikovski:[/usr/shared-apps/lib/gcc] gcc -v Using built-in specs. Target: sparc-sun-solaris2.10 Configured with: ../configure --prefix=/usr/shared-apps --enable-languages=c,c++,fortran --enable-shared --enable-threads=solaris --enable-nls --enable-checking=release --with-mpfr=/usr/shared-apps/ --with-gmp=/usr/shared-apps/ --enable-multilib --without-gnu-ld --with-ld=/usr/ccs/bin/ld Thread model: solaris gcc version 4.3.2 (GCC) Test program : tchaikovski:[~/rpl/programmes] cat test.f90 program TEST write(*,*) 'Hello, world' end Tests : tchaikovski:[~/rpl/programmes] gfortran -m64 test.f90 tchaikovski:[~/rpl/programmes] ./a.out ld.so.1: a.out: fatal : /usr/shared-apps/lib/libgfortran.so.3 : classe ELF erronée : ELFCLASS32 Tué tchaikovski:[~/rpl/programmes] gfortran test.f90 tchaikovski:[~/rpl/programmes] ./a.out Hello, world gcc works fine and I can build a 64bits test program : tchaikovski:[~/rpl/programmes] gcc -m64 test.c tchaikovski:[~/rpl/programmes] ./a.out Hello, World There is no error on link stage, but gfortran tries to link program with 32 bits libraries, not with 64 bits one even I force -m64. On linux sparc64, gfortran works fine. All gfortran 64 bits related libraries are available in sparcv9 subdirectory. Regards, JKB -- Summary: gfortran doesn't link any 64 bits binaries on Solaris Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mt1 at systella dot fr GCC build triplet: sparc-sun-solaris2.10 GCC host triplet: sparc-sun-solaris2.10 GCC target triplet: sparc-sun-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38268
[Bug c/38269] New: Segmentation fault in main_block_label when using -fno-unit-at-a-time and precompiled headers containing inline functions
Save the attachments (pin.c and ntoskrnl.h) to the same directory. Then run the following commands: gcc -o ntoskrnl.h.gch -I. -fno-unit-at-a-time -Os ntoskrnl.h gcc -v -o pin.o -I. -fno-unit-at-a-time -Os -c pin.c The latter will print the following: Using built-in specs. Target: mingw32 Configured with: ../gcc-4.1.3/configure --prefix=/gcc-4.1.3 --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --build=mingw32 --enable-languages=c,c++ --enable-checking=release --enable-threads=win32 --disable-win32-registry --disable-nls --disable-shared Thread model: win32 gcc version 4.1.3 20071015 (prerelease) c:/users/hyperion/rosbe/4.1.3/bin/../libexec/gcc/mingw32/4.1.3/cc1.exe -quiet -v -I. -iprefix c:\users\hyperion\rosbe\4.1.3\bin\../lib/gcc/mingw32/4.1.3/ pin.c -quiet -dumpbase pin.c -auxbase-strip pin.o -Os -version -fno-unit-at-a-time -o C:\Users\Hyperion\AppData\Local\Temp/ccphrNAF.s ignoring nonexistent directory C:/MSYS/gcc-4.1.3/include ignoring nonexistent directory /gcc-4.1.3/include ignoring nonexistent directory C:/MSYS/gcc-4.1.3/lib/gcc/mingw32/4.1.3/include ignoring nonexistent directory C:/MSYS/gcc-4.1.3/mingw32/include ignoring nonexistent directory /mingw/include #include ... search starts here: #include ... search starts here: . C:/Users/Hyperion/RosBE/4.1.3/include C:/Users/Hyperion/RosBE/4.1.3/lib/gcc/mingw32/4.1.3/include c:/users/hyperion/rosbe/4.1.3/bin/../lib/gcc/mingw32/4.1.3/include End of search list. GNU C version 4.1.3 20071015 (prerelease) (mingw32) compiled by GNU C version 4.1.3 20071015 (prerelease). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 3f527ff7c87fdc28aecf612037bc62b2 Very often (but not always), when executing the second command line, cc1.exe will ICE with the following message: ntoskrnl.h: In function 'ExAllocateFromNPagedLookasideList': ntoskrnl.h:56: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. I attached a debugger to cc1.exe, and resolved the symbols by hand to the following call stack: 143e04 _main_block_label 143fa1 _cleanup_dead_labels 124461 _execute_cleanup_cfg_post_optimizing 11ed04 _execute_one_pass 11ee3b _execute_pass_list 11ee4f _execute_pass_list 1245fe _tree_rest_of_compilation 09194 _c_expand_body 4eecb _cgraph_expand_function 4efa9 _cgraph_assemble_pending_functions 50125 _cgraph_finalize_function 09573 _finish_function 3fd4e _c_parser_declaration_or_fndef 4132e _c_parser_external_declaration 41f1d _c_gimplify_expr 305c4 _c_common_post_options f84bc _toplev_main 461f7 _main 0124b ___mingw_CRTStartup 01298 _mainCRTStartup Note that I'm forced to use -fno-unit-at-a-time because of an issue related to PR 17982 and PR 38054 -- Summary: Segmentation fault in main_block_label when using -fno- unit-at-a-time and precompiled headers containing inline functions Product: gcc Version: 4.1.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hackbunny at reactos dot com GCC build triplet: mingw32 GCC host triplet: mingw32 GCC target triplet: mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38269
[Bug c/38269] Segmentation fault in main_block_label when using -fno-unit-at-a-time and precompiled headers containing inline functions
--- Comment #1 from hackbunny at reactos dot com 2008-11-25 21:56 --- Created an attachment (id=16770) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16770action=view) test case (1 of 2) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38269
[Bug c/38269] Segmentation fault in main_block_label when using -fno-unit-at-a-time and precompiled headers containing inline functions
--- Comment #2 from hackbunny at reactos dot com 2008-11-25 21:56 --- Created an attachment (id=16771) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16771action=view) test case (2 of 2) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38269
[Bug target/38269] Segmentation fault in main_block_label when using -fno-unit-at-a-time and precompiled headers containing inline functions
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-11-25 22:04 --- 4.1.3 is old and no longer being maintained. So can you try 4.2.3 or better yet 4.3.2? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38269
[Bug target/38269] Segmentation fault in main_block_label when using -fno-unit-at-a-time and precompiled headers containing inline functions
--- Comment #4 from hackbunny at reactos dot com 2008-11-25 22:12 --- Yes and no, we are resisting upgrading due to PR 31707 (which we are attempting to workaround, and the workaround led to this bug...). I will try ASAP anyway -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38269
[Bug target/38269] Segmentation fault in main_block_label when using -fno-unit-at-a-time and precompiled headers containing inline functions
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-11-25 22:38 --- Then do not use PCH. Seriously, this is not going to be fixed unless you provide a patch ;) Rather I hope we will end up removing the current PCH implementation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38269
[Bug c++/11006] [CNI] ICE with use of __java_boolean
--- Comment #7 from olsner at gmail dot com 2008-11-25 23:02 --- Original test case and test case from comment #1 both give this result (i.e. no ICE) for me: (Comment #1) stdin: In function void foo(): stdin:4: error: can't find class$ in __java_boolean (Original test case) stdin: In function void foo(): stdin:28: error: can't find class$ in jboolean (c++ --version gives c++ (Ubuntu 4.3.2-1ubuntu11) 4.3.2) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11006
[Bug bootstrap/38262] [4.4 regression] GCC components unnecessarily link with shared gmp/mpfr
--- Comment #2 from ghazi at gcc dot gnu dot org 2008-11-25 23:08 --- (In reply to comment #1) Subject: Re: New: [4.4 regression] GCC components unnecessarily link with shared gmp/mpfr Here is a patch from Dwarak for fixing this. He will send this to review on gcc-patches@ list. Sebastian Pop -- AMD - GNU Tools Thanks, however I don't understand why in this patch xgcc and cpp are being linked with BACKENDLIBS. They don't linked with libbackend.a. Also, there are many more places where you do need to add BACKENDLIBS like cc1plus, cc1obj, f951, jc1, etc. See here for all the places you'll need to catch: http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00187.html -- ghazi 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-25 23:08:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38262
[Bug other/346] gcc install clobbers files that it shouldn't touch
--- Comment #8 from olsner at gmail dot com 2008-11-25 23:24 --- So, all issues mentioned in this bug are fixed, and related issues all have their own bugs? I think we should just close this one and ping/reconfirm/close bug 18244... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=346
[Bug c++/11006] [CNI] ICE with use of __java_boolean
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-11-25 23:40 --- This only ICEs now with checking turned on: t.cc: In function 'void foo()': t.cc:28: internal compiler error: tree check: expected record_type or union_type or qual_union_type, have integer_type in build_java_class_ref, at cp/init.c:2426 Without checking turned on I get the following ICE: t.cc: In function 'void foo()': t.cc:28: error: can't find 'class$' in 'jboolean' t.cc: At global scope: t.cc:29: error: expected `}' at end of input -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-checking http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11006
[Bug libgomp/38270] New: libgomp test failures due to missing memory barrier
Libgomp test libgomp.c/atomic-3.c started failing with wrong answers on power5 and power6 systems for -m32, and tests nqueens-1.c and sort-1.c started hanging intermittently for both -m32 and -m64 on those systems, with the addition of r139969, which removes the memory barrier from rs6000_split_lock_test_and_set. Adding back the memory barrier allows those tests to pass again. David Edelsohn told me that sync_lock_test_and_set does not require the stricter semantics of a memory barrier and if libgomp needs the memory barrier then it must emit one itself. The patch submission for r139969, http://gcc.gnu.org/ml/gcc/2008-09/msg00038.html, has followups from David and from Richard Henderson briefly discussing the semantics of sync_lock_test_and_set. -- Summary: libgomp test failures due to missing memory barrier Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janis at gcc dot gnu dot org GCC target triplet: powerpc64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38270
[Bug target/38269] Segmentation fault in main_block_label when using -fno-unit-at-a-time and precompiled headers containing inline functions
--- Comment #6 from d dot g dot gorbachev at gmail dot com 2008-11-26 00:00 --- GCC 4.3.2 failed to compile the testcase with internal compiler error: in copy_phis_for_bb, at tree-inline.c:1227 or internal compiler error: in gimplify_expr, at gimplify.c:6146 message. GCC 4.4.0 works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38269
[Bug rtl-optimization/37514] [4.4 Regression] Wrong code generated for 20021120-1.c with -O3 -fomit-frame-pointer on sh4
--- Comment #8 from kkojima at gcc dot gnu dot org 2008-11-26 00:03 --- Vlad, thanks for taking the time to look into this! Your comments in #7 and http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01323.html give a very clear picture of the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37514
[Bug target/38054] Assertion failed in change_decl_assembler_name()
--- Comment #9 from d dot g dot gorbachev at gmail dot com 2008-11-26 00:14 --- GCC 4.3.2 and 4.4.0 compile the above testcase without warnings. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38054
[Bug middle-end/38271] New: Spurious / missing ... used uninitialized in this function warning
gcc -S -O1 -Wuninitialized uninitialized.c GCC 4.4.0 20081121: warning: 's' is used uninitialized in this function GCC 4.3.2: warning: âiâ may be used uninitialized in this function -- Summary: Spurious / missing ... used uninitialized in this function warning Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: d dot g dot gorbachev at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38271
[Bug middle-end/38271] Spurious / missing ... used uninitialized in this function warning
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2008-11-26 02:48 --- Created an attachment (id=16772) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16772action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38271
[Bug middle-end/38271] [4.4 Regression] Spurious / missing ... used uninitialized in this function warning
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-11-26 02:54 ---
What the *#$^*(#^$*(:
SR.3_5 = p_1(D)-c;
SR.4_6 = VIEW_CONVERT_EXPRlong long unsigned int(*p_1(D));
SR.4_7 = SR.4_6 4294967295;
SR.5_8 = (unsigned int) SR.4_7;
s.0.c ={v} SR.3_5;
SR.6_10 = VIEW_CONVERT_EXPRlong long unsigned int(s.0);
SR.7_11 = SR.6_10 0x0;
SR.8_12 = (long long unsigned int) SR.5_8;
SR.9_13 = SR.7_11 | SR.8_12;
s.0 ={v} VIEW_CONVERT_EXPRstruct xxx(SR.9_13);
This is so wrong.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||aoliva at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||diagnostic
Last reconfirmed|-00-00 00:00:00 |2008-11-26 02:54:24
date||
Summary|Spurious / missing ... used|[4.4 Regression] Spurious /
|uninitialized in this |missing ... used
|function warning |uninitialized in this
||function warning
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38271
[Bug c++/28743] [4.2/4.3/4.4 regression] ICE with invalid specialization
--- Comment #17 from jason at gcc dot gnu dot org 2008-11-26 03:53 --- Subject: Bug 28743 Author: jason Date: Wed Nov 26 03:51:40 2008 New Revision: 142212 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142212 Log: PR c++/28743 * decl2.c (check_classfn): Error rather than abort on parameter list mismatch. Added: trunk/gcc/testsuite/g++.dg/template/nontype18.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28743
[Bug fortran/38268] gfortran doesn't link any 64 bits binaries on Solaris
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-11-26 03:53 --- I have been given access to a mchine with this architecture and have not, after several evenings at it, been able to complete a single build of gfortran. I notice some instructions on the gcc web page about some recommended linker to use. I suspect there are some configuration issues going on here that we need to nail down. Do we have a solaris gcc maintainer around? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38268
[Bug rtl-optimization/38272] New: [4.4 Regression] Revision 142207 caused libgomp.fortran/threadprivate2.f90
On Linux/ia32, revision 142207 caused FAIL: libgomp.fortran/threadprivate2.f90 -O1 execution test -- Summary: [4.4 Regression] Revision 142207 caused libgomp.fortran/threadprivate2.f90 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization 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=38272
[Bug libfortran/37754] [4.4 Regression] READ I/O Performance regression from 4.3 to 4.4
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2008-11-26 03:59 --- Un assigning myself since I think Janne is working on this and I would hate to duplicate effort. If I need to pick back up on this, let me know. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|jvdelisle at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37754
[Bug fortran/30388] gfortran42 is slower than g77 3.4 about 10%
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2008-11-26 04:05 --- Not a gfortran frontend issue, so closing. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30388
[Bug middle-end/37843] [4.4 Regression] unaligned stack in main due to tail call optimization
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2008-11-26 04:25 --- On i686-apple-darwin9, we are failing... FAIL: gcc.target/i386/pr37843-1.c scan-assembler call[\\t ]*foo FAIL: gcc.target/i386/pr37843-2.c scan-assembler jmp[\\t ]*foo at revision 142207. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37843
[Bug middle-end/37843] [4.4 Regression] unaligned stack in main due to tail call optimization
--- Comment #10 from howarth at nitro dot med dot uc dot edu 2008-11-26 04:26 --- Created an attachment (id=16773) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16773action=view) assembly file for gcc.target/i386/pr37843-1.c on i686-apple-darwin9 Created with... /sw/src/fink.build/gcc44-4.3.999-20081125/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc44-4.3.999-20081125/darwin_objdir/gcc/ /sw/src/fink.build/gcc44-4.3.999-20081125/gcc-4.4-20081125/gcc/testsuite/gcc.target/i386/pr37843-1.c -O2 -mpreferred-stack-boundary=6 -mincoming-stack-boundary=5 -S -m32 -o pr37843-1.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37843
[Bug middle-end/37843] [4.4 Regression] unaligned stack in main due to tail call optimization
--- Comment #11 from howarth at nitro dot med dot uc dot edu 2008-11-26 04:28 --- Created an attachment (id=16774) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16774action=view) assembly file for gcc.target/i386/pr37843-2.c on i686-apple-darwin9 Created with... /sw/src/fink.build/gcc44-4.3.999-20081125/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc44-4.3.999-20081125/darwin_objdir/gcc/ /sw/src/fink.build/gcc44-4.3.999-20081125/gcc-4.4-20081125/gcc/testsuite/gcc.target/i386/pr37843-2.c -O2 -mpreferred-stack-boundary=6 -mincoming-stack-boundary=6 -S -m32 -o pr37843-2.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37843
[Bug middle-end/37843] [4.4 Regression] unaligned stack in main due to tail call optimization
--- Comment #12 from hjl dot tools at gmail dot com 2008-11-26 05:38 --- I don't think sibcall work on Darwin. Can you skip them on Darwin? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37843
[Bug fortran/38268] gfortran doesn't link any 64 bits binaries on Solaris
--- Comment #2 from mt1 at systella dot fr 2008-11-26 07:17 --- (In reply to comment #1) I have been given access to a mchine with this architecture and have not, after several evenings at it, been able to complete a single build of gfortran. I notice some instructions on the gcc web page about some recommended linker to use. I suspect there are some configuration issues going on here that we need to nail down. Do we have a solaris gcc maintainer around? I have built GNU binutils on Solaris. If I use GNU-ld, gcc runs fine in 32 bits mode, but is unable to link any 64 bits applications (GNU ld takes 64 bits gcc libraries but tries to link a 32 bits program !). Thus it is not possible to build a 64 bits gcc on solaris with GNU-ld and I have built my gcc with Solaris ld. If i use only gfortran to compile (gfortran -c) a test program, I haven't find any option to link and run this object. I suspect a path mistake when gfortran calls ld wrapper. Regards, JKB -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38268
[Bug fortran/38268] gfortran doesn't link any 64 bits binaries on Solaris
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2008-11-26 07:48 --- I have been given access to a mchine with this architecture and have not, after several evenings at it, been able to complete a single build of gfortran. Weird, folks generally can build it flawlessly, see the various build pages: http://gcc.gnu.org/gcc-4.1/buildstat.html http://gcc.gnu.org/gcc-4.2/buildstat.html http://gcc.gnu.org/gcc-4.3/buildstat.html You indeed need to follow the build instructions. What happens exactly? I suspect there are some configuration issues going on here that we need to nail down. Do we have a solaris gcc maintainer around? I'm the SPARC/Solaris maintainer. The Fortran compiler has been working fine on this platform since 4.0.0, like on every other primary platforms. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38268
