[Bug target/4605] [alpha-osf]mips-tfile spaced directory names
--- Comment #16 from markus dot schoepflin at comsoft dot de 2009-01-14 08:11 --- Subject: Re: [alpha-osf]mips-tfile spaced directory names gnu at the-meissners dot org wrote: --- Comment #15 from gnu at the-meissners dot org 2009-01-13 23:13 --- I suspect this needs to be solved in gcc.c with the specs handling, and you probably need something to quote the white space in filename, so that it doesn't break the file into separate arguments. Only some alpha and mips port use ASM_FINAL_SPEC which calls mips-tfile. I don't think this can be solved in gcc at all. AFAICT the quoting is all there as needed, but the system assembler simply can't handle file names with embedded blanks. I must admit that when I wrote mips-tfile as a quick hack in 1990 to get around the problem of having to use the MIPS assembler which provided no debug inteferface until a MIPS port of GAS was done, that the hack would still be in use 18 years later. Nothing is as long-lived as a quick hack, isn't it? Markus -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4605
[Bug fortran/34955] transfer_assumed_size_1.f90: Valgrind error: invalid read of size 3
--- Comment #21 from dominiq at lps dot ens dot fr 2009-01-14 08:15 ---
On i686-apple-darwin9 I cannot test the valgrind part of this pr, however with
the patch in http://gcc.gnu.org/ml/fortran/2009-01/msg00162.html the following
test now succeeds:
character(len=1) :: string = z
character(len=20) :: tmp =
tmp = Upper (abcdefgh)
print *, tmp
contains
Character (len=20) Function Upper (string)
Character(len=*) string
integer :: ij
print *, len(string)
print *, size(transfer(string,xy,len(string)))
i = size(transfer(string,xy,len(string)))
if (i /= len(string)) call abort()
Upper =
Upper(1:2) =
transfer(merge(transfer(string,xy,len(string)),
string(1:2), .true.), xy)
return
end function Upper
end
(coming from pr31608). I saw one regression on char_cast_1.f90 which needs some
adjustment of the test, the following change allows it to pass:
--- ../_gcc_clean/gcc/testsuite/gfortran.dg/char_cast_1.f90 2008-05-19
14:20:35.0 +0200
+++ gcc/testsuite/gfortran.dg/char_cast_1.f90 2009-01-14 07:37:03.0
+0100
@@ -27,5 +27,5 @@
end
! The sign that all is well is that [S.5][1] appears twice.
! Platform dependent variations are [S$5][1], [__S_5][1], [S___5][1]
-! { dg-final { scan-tree-dump-times 5\\\]\\\[1\\\] 2 original } }
+! { dg-final { scan-tree-dump-times 6\\\]\\\[1\\\] 2 original } }
! { dg-final { cleanup-tree-dump original } }
From the comment the test seems fragile and should probably changed to
something more robust.
Thanks for the patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34955
[Bug c++/38828] g++ 4.3.2: -O2 without -fno-inline-small-functions makes some template instantiations disappear
--- Comment #6 from ronan dot lehy at probayes dot com 2009-01-14 09:11 --- Thanks a lot for considering this report! (In reply to comment #5) Also since it is not explicitly instatinated, the template does not need to be in the object file really. I believe this is instantiated with Archive = boost_xml_iarchive by the BOOST_EXPORT macro. (In reply to comment #5) serialize with an empty body is a pure function so it will be can be optimized away without any effects. I don't see the issue here really. But this function (as instantiated with Archive = boost_xml_iarchive by BOOST_EXPORT) can be called from other .o files. Actually, it is, and linking the .o files together into a shared library then fails. Can you give a better example of why do you think this is wrong besides a nm testcase? I could show you how mylib1.o and mylib2.o fail to link into libmylib.so, since serializeboost_xml_iarchive(boost_xml_iarchive, A, unsigned int) is referenced by mylib2.o, and should be defined in mylib1.o, but is not. Do you want that ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38828
[Bug c++/38828] g++ 4.3.2: -O2 without -fno-inline-small-functions makes some template instantiations disappear
--- Comment #7 from ronan dot lehy at probayes dot com 2009-01-14 09:14 --- (In reply to comment #6) I believe this is instantiated with Archive = boost_xml_iarchive by the BOOST_EXPORT macro. I mean BOOST_CLASS_EXPORT(), of course, sorry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38828
[Bug libstdc++/38834] New: FAIL: abi_check on alpha
abi_check is failing on alpha: # of added symbols: 505 # of missing symbols:0 # of incompatible symbols: 22 using: baseline_symbols.txt FAIL: abi_check These failures are all due to incompatible std::numeric_limits object versions, i.e.: _ZNSt14numeric_limitsIgE14max_exponent10E std::numeric_limits__float128::max_exponent10 version status: incompatible GLIBCXX_3.4 type: object type size: 4 status: added According to abi_check, functions with __float128 arguments should be versioned as GLIBCXX_LDBL_3.4. Following patch fixes abi_check failure: --cut here-- Index: gnu.ver === --- gnu.ver (révision 143247) +++ gnu.ver (copie de travail) @@ -403,8 +403,7 @@ _ZNKSt9money_putI[cw]St19ostreambuf_iteratorI[cw]St11char_traitsI[cw]EEE*; # std::numeric_limits -# _ZNSt14numeric_limitsI[^g]*; -_ZNSt14numeric_limitsI[a-z]E*; +_ZNSt14numeric_limitsI[^g]E*; # std::_Rb_tree _ZSt18_Rb_tree_decrementPKSt18_Rb_tree_node_base; --cut here-- libc version: GNU C Library stable release version 2.7, by Roland McGrath et al. Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 4.2.3 (Debian 4.2.3-3). Compiled on a Linux 2.6.18-4-alpha-generic system on 2008-03-28. Available extensions: crypt add-on version 2.1 by Michael Glad and others GNU Libidn by Simon Josefsson Native POSIX Threads Library by Ulrich Drepper et al BIND-8.2.3-T5B software FPU emulation by Richard Henderson, Jakub Jelinek and others For bug reporting instructions, please see: http://www.gnu.org/software/libc/bugs.html. libstdc++ is configured as: $ /home/uros/gcc-svn/trunk/libstdc++-v3/configure --cache-file=./config.cache --enable-multilib --disable-bootstrap --enable-languages=c,c++ --program-transfo rm-name=s,y,y, --with-target-subdir=alphaev56-unknown-linux-gnu --build=alphaev5 6-unknown-linux-gnu --host=alphaev56-unknown-linux-gnu --target=alphaev56-unknow n-linux-gnu --srcdir=../../../gcc-svn/trunk/libstdc++-v3 -mlong-double-128 is implicit. -- Summary: FAIL: abi_check on alpha Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ubizjak at gmail dot com GCC build triplet: alphaev68-unknown-linux-gnu GCC host triplet: alphaev68-unknown-linux-gnu GCC target triplet: alphaev68-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38834
[Bug libstdc++/38834] FAIL: abi_check on alpha
--- Comment #1 from ubizjak at gmail dot com 2009-01-14 09:40 --- Created an attachment (id=17096) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17096action=view) test log file of make check_abi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38834
[Bug libstdc++/38834] FAIL: abi_check on alpha
--- Comment #2 from ubizjak at gmail dot com 2009-01-14 09:42 --- Patch at http://gcc.gnu.org/ml/libstdc++/2009-01/msg00066.html -- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/libstd ||c++/2009-01/msg00066.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38834
Re: [Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
Attached a fix for this PR. I will regstrap and submit for review.
Sebastian
2009-01-14 Sebastian Pop sebastian@amd.com
PR middle-end/38431
* graphite.c (get_vdef_before_scop, scop_adjust_vphi): New.
(scop_adjust_phis_for_liveouts): Call scop_adjust_vphi.
(gloog): Do not call cleanup_tree_cfg.
(graphite_transform_loops): Call cleanup_tree_cfg after all
scops have been code generated.
Index: graphite.c
===
--- graphite.c (revision 143346)
+++ graphite.c (working copy)
@@ -5188,6 +5188,82 @@ scop_insert_phis_for_liveouts (sese regi
update_ssa (TODO_update_ssa);
}
+/* Get the definition of NAME before the SCOP. Keep track of the
+ basic blocks that have been VISITED in a bitmap. */
+
+static tree
+get_vdef_before_scop (scop_p scop, tree name, sbitmap visited)
+{
+ unsigned i;
+ gimple def_stmt = SSA_NAME_DEF_STMT (name);
+ basic_block def_bb = gimple_bb (def_stmt);
+
+ if (!bb_in_scop_p (def_bb, scop))
+return name;
+
+ if (TEST_BIT (visited, def_bb-index))
+return NULL_TREE;
+
+ SET_BIT (visited, def_bb-index);
+
+ switch (gimple_code (def_stmt))
+{
+case GIMPLE_PHI:
+ for (i = 0; i gimple_phi_num_args (def_stmt); i++)
+ {
+ tree arg = gimple_phi_arg_def (def_stmt, i);
+ tree res = get_vdef_before_scop (scop, arg, visited);
+ if (res)
+ return res;
+ }
+ return NULL_TREE;
+
+default:
+ return NULL_TREE;
+}
+}
+
+/* Adjust a virtual phi node PHI that is placed at the end of the
+ generated code for SCOP:
+
+ | if (1)
+ | generated code from REGION;
+ | else
+ | REGION;
+
+ The FALSE_E edge comes from the original code, TRUE_E edge comes
+ from the code generated for the SCOP. */
+
+static void
+scop_adjust_vphi (scop_p scop, gimple phi, edge true_e)
+{
+ unsigned i;
+
+ gcc_assert (gimple_phi_num_args (phi) == 2);
+
+ for (i = 0; i gimple_phi_num_args (phi); i++)
+if (gimple_phi_arg_edge (phi, i) == true_e)
+ {
+ tree true_arg, false_arg, before_scop_arg;
+ sbitmap visited;
+
+ true_arg = gimple_phi_arg_def (phi, i);
+ if (!SSA_NAME_IS_DEFAULT_DEF (true_arg))
+ return;
+
+ false_arg = gimple_phi_arg_def (phi, i == 0 ? 1 : 0);
+ if (SSA_NAME_IS_DEFAULT_DEF (false_arg))
+ return;
+
+ visited = sbitmap_alloc (last_basic_block);
+ sbitmap_zero (visited);
+ before_scop_arg = get_vdef_before_scop (scop, false_arg, visited);
+ gcc_assert (before_scop_arg != NULL_TREE);
+ SET_PHI_ARG_DEF (phi, i, before_scop_arg);
+ sbitmap_free (visited);
+ }
+}
+
/* Adjusts the phi nodes in the block BB for variables defined in
SCOP_REGION and used outside the SCOP_REGION. The code generation
moves SCOP_REGION in the else clause of an if (1) and generates
@@ -5214,7 +5290,10 @@ scop_adjust_phis_for_liveouts (scop_p sc
gimple phi = gsi_stmt (si);
if (!is_gimple_reg (PHI_RESULT (phi)))
- continue;
+ {
+ scop_adjust_vphi (scop, phi, true_e);
+ continue;
+ }
for (i = 0; i gimple_phi_num_args (phi); i++)
if (gimple_phi_arg_edge (phi, i) == false_e)
@@ -5396,9 +5475,6 @@ gloog (scop_p scop, struct clast_stmt *s
recompute_all_dominators ();
graphite_verify ();
- cleanup_tree_cfg ();
- recompute_all_dominators ();
- graphite_verify ();
}
/* Returns the number of data references in SCOP. */
@@ -6095,6 +6171,7 @@ graphite_transform_loops (void)
}
/* Cleanup. */
+ cleanup_tree_cfg ();
free_scops (current_scops);
cloog_finalize ();
free_original_copy_tables ();
[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
--- Comment #33 from sebpop at gmail dot com 2009-01-14 10:20 --- Subject: Re: [graphite] several ICEs with CP2K (summary) Attached a fix for this PR. I will regstrap and submit for review. Sebastian --- Comment #34 from sebpop at gmail dot com 2009-01-14 10:20 --- Created an attachment (id=17097) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17097action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431
[Bug fortran/33430] Improve -finit-*: Initialization of derived types, equivalenced variables, allocated arrays
--- Comment #2 from tkoenig at gcc dot gnu dot org 2009-01-14 10:32 --- It would also make a lot of sense to do this for allocated arrays, as well. (Original request from Clive Page on c.l.f) -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Summary|Improve -finit-*: |Improve -finit-*: |Initialization of derived |Initialization of derived |types, equivalenced |types, equivalenced |variables |variables, allocated arrays http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33430
[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
--- Comment #35 from jv244 at cam dot ac dot uk 2009-01-14 10:51 --- (In reply to comment #33) Attached a fix for this PR. I will regstrap and submit for review. while I'll apply it to current trunk, retest CP2K, and update this PR with the results. Thanks, Joost -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431
[Bug target/20049] __builtin_ia32_loadsss is still documented
--- Comment #3 from aldot at gcc dot gnu dot org 2009-01-14 11:01 ---
Created an attachment (id=17098)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17098action=view)
patch for trunk to remove references to the removed
__builtin_ia32_{pextrw,pinsrw}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20049
[Bug target/37250] GCC documentation lists unavailable ia32 intrinsics
--- Comment #1 from aldot at gcc dot gnu dot org 2009-01-14 11:02 --- *** This bug has been marked as a duplicate of 20049 *** -- aldot at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37250
[Bug target/20049] __builtin_ia32_loadsss is still documented
--- Comment #4 from aldot at gcc dot gnu dot org 2009-01-14 11:02 --- *** Bug 37250 has been marked as a duplicate of this bug. *** -- aldot at gcc dot gnu dot org changed: What|Removed |Added CC||jtoomim at jtoomim dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20049
[Bug tree-optimization/38835] New: field-insensitive PTA causes libstdc++ miscompiles
Running the libstdc++ testsuite with --param=max-fields-for-field-sensitive=0 (which disables field-sensitive PTA) causes FAIL: 23_containers/forward_list/ext_pointer/1.cc execution test FAIL: 23_containers/forward_list/ext_pointer/modifiers/1.cc execution test FAIL: 23_containers/forward_list/ext_pointer/modifiers/2.cc execution test FAIL: 23_containers/forward_list/ext_pointer/modifiers/3.cc execution test FAIL: 23_containers/forward_list/ext_pointer/operations/1.cc execution test FAIL: 23_containers/forward_list/ext_pointer/operations/2.cc execution test FAIL: 23_containers/forward_list/ext_pointer/operations/3.cc execution test FAIL: 23_containers/forward_list/ext_pointer/operations/4.cc execution test FAIL: 23_containers/vector/ext_pointer/modifiers/erase.cc execution test FAIL: 23_containers/vector/ext_pointer/modifiers/insert.cc execution test -- Summary: field-insensitive PTA causes libstdc++ miscompiles Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38835
[Bug c/38836] New: Documentation for x86 builtins is outdated
The documentation for builtin functions need a serious overhaul, trying to use several builtins as documented will result in the linker complaining about missing functions. As reference (I`m not sure how accurate this is) take this post: http://www.mail-archive.com/g...@gcc.gnu.org/msg03309.html Also the correct alternative of using xmmintrin.h is mentioned nowhere in the documentation, neither the correct typedefs (or even which variation should be prefered). eg. defining v8qi as typedef uint_8 v8qi __attribute__ ((vector_size (8))); will result in errors with function requiring a 8*8 vector of integers. Its not obvious that you have to use typedef char v8qi __attribute__ ((vector_size (8))); instead -- Summary: Documentation for x86 builtins is outdated Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: npl at chello dot at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38836
[Bug c/38836] Documentation for x86 builtins is outdated
--- Comment #1 from aldot at gcc dot gnu dot org 2009-01-14 11:13 --- As previously said on irc, this is a duplicate of PR20049. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38836
[Bug tree-optimization/38785] huge performance regression on EEMBC bitmnp01
--- Comment #7 from Joey dot ye at intel dot com 2009-01-14 10:08 --- (In reply to comment #5) Joern, re. comment #4, Richi refers to my patch to enable PRE at -Os, see [1]. An extension to this patch that we tested on x86 machines, is to disable PRE for scalar integer registers, via SMALL_REGISTER_CLASSES. I changed SMALL_REGISTER_CLASSES into a target hook for this purpose, see [2]. You could play with this, see if you can use this to cure your problem... [1] http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00199.html [2] http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00590.html Reproduced on x86. But I fail to build with patch [2] on x86_64, anything wrong? ../../src/gcc/target-def.h:476:1: error: unterminated #ifndef ../../src/gcc/c-common.c:8197: error: 'TARGETCM_INITIALIZER' undeclared here (not in a function) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38785
[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
--- Comment #36 from jv244 at cam dot ac dot uk 2009-01-14 12:08 --- (In reply to comment #35) (In reply to comment #33) Attached a fix for this PR. I will regstrap and submit for review. while I'll apply it to current trunk, retest CP2K, and update this PR with the results. Looks like all CP2K tests pass with this patch installed! Many thanks, Joost -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431
[Bug middle-end/21374] [4.2/4.3/4.4 regression] ICE with nested function
--- Comment #6 from laurent at guerby dot net 2009-01-14 12:38 --- I think return of variable sized objects are handled by the Ada front-end using a secondary stack (and hidden pointers to boundary records) and so the back-end doesn't see anything like the code above. The ACATS testsuite is very likely checking that stuff extensively, so testing a patch disabling that GNU C feature with Ada enabled will be enough to validate it. -- laurent at guerby dot net changed: What|Removed |Added CC||laurent at guerby dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21374
[Bug c/19541] need another option to support what -I- did just besides -iquote
--- Comment #14 from Johannes dot Schwenke at gmx dot de 2009-01-14 12:18 --- Please, could anyone increase priority and serverity of this bug? The current documentation that pretends that -iquote could work as replacement is plain wrong. A proper replacement for -I- is needed. A solution has been proposed long ago. Fixes are around. Of course, like other people (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34855#c5) my favourite solution would be if you could undo the deprecation of -I-, as it is used by other compilers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19541
[Bug tree-optimization/38785] huge performance regression on EEMBC bitmnp01
--- Comment #8 from steven at gcc dot gnu dot org 2009-01-14 10:54 --- Re comment #7 Those patches are just proof-of-concept, and wouldn't actually help without additional changes in tree-ssa-pre.c. If you want, I can make the patches apply and work properly, and send them to you to play with (just send me a mail if you want them). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38785
[Bug c++/37862] Parenthesised indirection alters class member access
--- Comment #6 from nickc at gcc dot gnu dot org 2009-01-14 13:00 --- Subject: Bug 37862 Author: nickc Date: Wed Jan 14 13:00:21 2009 New Revision: 143369 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143369 Log: PR c++/37862 * parser.c: Pass cp_id_kind computed in cp_parser_postfix_dot_deref_expression to cp_parser_primary_expression. * g++.cp/parse/pr37862.C: New test. Added: trunk/gcc/testsuite/g++.dg/parse/pr37862.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37862
[Bug target/20049] __builtin_ia32_loadsss is still documented
--- Comment #5 from aldot at gcc dot gnu dot org 2009-01-14 11:33 --- Also applies to the 4_3-branch. -- aldot at gcc dot gnu dot org changed: What|Removed |Added CC||aldot at gcc dot gnu dot org Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20049
[Bug c++/35109] [4.2/4.3 Regression] ICE in lookup_name_real, at cp/name-lookup.c:4056
--- Comment #7 from dodji at gcc dot gnu dot org 2009-01-14 13:10 --- This is now fixed in trunk (gcc 4.4) so I have adjusted the summary. -- dodji at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.2/4.3/4.4 Regression] ICE|[4.2/4.3 Regression] ICE in |in lookup_name_real, at |lookup_name_real, at |cp/name-lookup.c:4056 |cp/name-lookup.c:4056 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35109
[Bug c++/38837] New: Compatibilty with MPICH2
I upgraded recently to gcc-4.3 and I'm finding trouble to execute my MPI programs. Indeed, when executing an MPI program with mpiexec sometimes it terminates correctly and sometimes it shows different error messages such as: rank 2 in job 1 mahmoud-desktop_33023 caused collective abort of all ranks exit status of rank 2: killed by signal 9 or [cli_1]: aborting job: Fatal error in MPI_Allreduce: Other MPI error, error stack: MPI_Allreduce(696): MPI_Allreduce(sbuf=0x8103344, rbuf=0x8103348, count=1, MPI_UNSIGNED, MPI_SUM, MPI_COMM_WORLD) failed MPIR_Allreduce(285)...: MPIC_Sendrecv(161): MPIC_Wait(321): MPIDI_CH3_Progress_wait(199)..: an error occurred while handling an event returned by MPIDU_Sock_Wait() MPIDI_CH3I_Progress_handle_sock_event(422): MPIDU_Socki_handle_read(649)..: connection failure (set=0,sock=3,errno=104:(strerror() not found)) [cli_1]: aborting job: Fatal error in MPI_Finalize: Other MPI error, error stack: MPI_Finalize(220).: MPI_Finalize failed MPI_Finalize(146).: MPID_Finalize(206): an error occurred while the device was waiting for all open connections to close MPIDI_CH3_Progress_wait(199)..: an error occurred while handling an event returned by MPIDU_Sock_Wait() MPIDI_CH3I_Progress_handle_sock_event(422): MPIDU_Socki_handle_read(649)..: connection failure (set=0,sock=4,errno=104:(strerror() not found)) rank 3 in job 4 mahmoud-desktop_33023 caused collective abort of all ranks exit status of rank 3: killed by signal 9 rank 0 in job 4 mahmoud-desktop_33023 caused collective abort of all ranks exit status of rank 0: killed by signal 11 I'm failing to find a reason as my programs work fine with gcc 4.2. If it is a known bug that has been already fixed please send tell me how to fix it on my own machine. Best regards, Yours faithfully. -- Summary: Compatibilty with MPICH2 Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mahmoud dot fatene at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38837
[Bug c++/38837] Compatibilty with MPICH2
-- mahmoud dot fatene at gmail dot com changed: What|Removed |Added Severity|normal |blocker http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38837
[Bug middle-end/21374] [4.2/4.3/4.4 regression] ICE with nested function
--- Comment #7 from joseph at codesourcery dot com 2009-01-14 13:49 --- Subject: Re: [4.2/4.3/4.4 regression] ICE with nested function If there is language-independent code that's supposed to handle this extension that doesn't handle anything in any other language, I'd be fine with deprecating and then removing the feature (returning variable-size types from nested functions) from GNU C (unless a lot of users show up after deprecation) - provided it at least isn't used in glibc (which does use some nested functions). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21374
[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath
--- Comment #20 from r dot emrich at de dot tecosim dot com 2009-01-14 13:58 --- (In reply to comment #18) Ranier, this should be working now. Can you try to cross-compile as before, but with updated gcc sources? Now it builds, but there are some issues. Will come back to this next week. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38384
[Bug c++/38837] Compatibilty with MPICH2
--- Comment #1 from mahmoud dot fatene at gmail dot com 2009-01-14 14:13 --- Sorry, I forgot to precise that I'm using a linux distribution ubuntu 8.10 on a DELL XPS desktop. The compiler was built with the following options: Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.2-1ubuntu11' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38837
[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
--- Comment #37 from spop at gcc dot gnu dot org 2009-01-14 14:35 --- Subject: Bug 38431 Author: spop Date: Wed Jan 14 14:35:27 2009 New Revision: 143372 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143372 Log: 2009-01-14 Sebastian Pop sebastian@amd.com PR middle-end/38431 * graphite.c (get_vdef_before_scop, scop_adjust_vphi): New. (scop_adjust_phis_for_liveouts): Call scop_adjust_vphi. (gloog): Do not call cleanup_tree_cfg. (graphite_transform_loops): Call cleanup_tree_cfg after all scops have been code generated. Modified: branches/graphite/gcc/ChangeLog.graphite branches/graphite/gcc/graphite.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431
[Bug middle-end/38431] [graphite] several ICEs with CP2K (summary)
--- Comment #38 from spop at gcc dot gnu dot org 2009-01-14 14:36 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38431
Re: [Bug testsuite/38791] FAIL: gcc.dg/graphite/block-3.c (test for excess errors)
Before closing this pr as fixed, I have a question: usually tests having
-fdump-* in dg-options are doing some search of patterns in the dumped file,
e.g. in gcc/testsuite/gcc.dg/pr35729.c
/* { dg-options -Os -fdump-rtl-loop2_invariant } */
...
/* { dg-final { scan-rtl-dump-times Decided to move invariant 0
loop2_invariant } } */
I noticed that gcc/testsuite/gcc.dg/graphite/block-3.c has only the cleaning
dg-final, but no scan-* one(s). I don't see anything in
gcc/testsuite/gcc.dg/graphite/graphite.exp that could supply it either.
Is this the intended behavior or is there something missing in this test (and
possibly other graphite ones)?
The test for loop blocking is missing in block-3.c. We will have to
clean up the graphite testsuite and making the tests more reliable,
but probably this will be done in GCC4.5.
Sebastian
[Bug testsuite/38791] FAIL: gcc.dg/graphite/block-3.c (test for excess errors)
--- Comment #8 from sebpop at gmail dot com 2009-01-14 14:45 ---
Subject: Re: FAIL: gcc.dg/graphite/block-3.c (test for excess errors)
Before closing this pr as fixed, I have a question: usually tests having
-fdump-* in dg-options are doing some search of patterns in the dumped file,
e.g. in gcc/testsuite/gcc.dg/pr35729.c
/* { dg-options -Os -fdump-rtl-loop2_invariant } */
...
/* { dg-final { scan-rtl-dump-times Decided to move invariant 0
loop2_invariant } } */
I noticed that gcc/testsuite/gcc.dg/graphite/block-3.c has only the cleaning
dg-final, but no scan-* one(s). I don't see anything in
gcc/testsuite/gcc.dg/graphite/graphite.exp that could supply it either.
Is this the intended behavior or is there something missing in this test (and
possibly other graphite ones)?
The test for loop blocking is missing in block-3.c. We will have to
clean up the graphite testsuite and making the tests more reliable,
but probably this will be done in GCC4.5.
Sebastian
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38791
[Bug testsuite/38791] FAIL: gcc.dg/graphite/block-3.c (test for excess errors)
--- Comment #9 from spop at gcc dot gnu dot org 2009-01-14 14:46 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38791
[Bug middle-end/21374] [4.2/4.3/4.4 regression] ICE with nested function
--- Comment #8 from jakub at gcc dot gnu dot org 2009-01-14 15:00 --- As any call to a nested function with VL return type ICEs (even if the result isn't used) in 3.4.5 through 4.4.0, I doubt this is used very widely. That said, if we deprecate it now, we'd have to fix it, warning about deprecation and then ICE doesn't make much sense. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21374
[Bug middle-end/21374] [4.2/4.3/4.4 regression] ICE with nested function
--- Comment #9 from joseph at codesourcery dot com 2009-01-14 15:06 --- Subject: Re: [4.2/4.3/4.4 regression] ICE with nested function If all such calls ICE since 3.4.5 then I think we can just remove the feature (giving an error if a nested function is declared to return a variable-length type). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21374
[Bug regression/38838] New: BIND(C): Binding name expressions are wrongly rejected
R509 language-binding-spec is BIND (C [, NAME = scalar-char-initialization-expr ]) -- Summary: BIND(C): Binding name expressions are wrongly rejected Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: regression 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=38838
[Bug regression/38838] BIND(C): Binding name expressions are wrongly rejected
--- Comment #1 from burnus at gcc dot gnu dot org 2009-01-14 15:07 --- Example: subroutine test() bind(c, name=trim(Hello )) end Error: Syntax error in NAME= specifier for binding label at (1) Per the R509 cited above this is valid. It is also accepted by other compilers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38838
[Bug regression/38838] BIND(C): Binding name expressions are wrongly rejected
--- Comment #2 from burnus at gcc dot gnu dot org 2009-01-14 15:13 --- Found at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/d977a668b0316119 by James Van Buskirk -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38838
[Bug target/38781] PR38151: valgrind finds problem
--- Comment #2 from hjl dot tools at gmail dot com 2009-01-14 15:16 --- An updated patch is posted at http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00738.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- |http://gcc.gnu.org/ml/gcc- |patches/2009- |patches/2009- |01/msg00463.html|01/msg00738.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38781
[Bug bootstrap/37660] Error Building libssp, recent update
--- Comment #2 from piotr dot wyderski at gmail dot com 2009-01-14 15:20 --- Still happens on Cygwin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660
[Bug fortran/38822] Compile-time simplification of x**(real) / ICE in in gfc_target_encode_expr
--- Comment #2 from burnus at gcc dot gnu dot org 2009-01-14 15:30 --- Before closing, please also check the two longer cases: http://groups.google.com/group/comp.lang.fortran/msg/97c3ce6e98432ae9 and the older (partially incorrect?) one at http://groups.google.com/group/comp.lang.fortran/msg/c71f697c3e21e3f2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38822
[Bug fortran/38839] New: BIND(C): Allow non-digit/underscore/alphabetic binding names
Motivated by
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/d977a668b0316119
Currently, BIND(C, NAME=binding-name) checks for ISALPHA and _. However, the
C standard allows more (from ISO/IEC 9899:1999(E) = C99, Section 6.4.2
Indentifiers):
identifier:
identifier-nondigit
identifier identifier-nondigit
identifier digit
identifier-nondigit:
nondigit
universal-character-name
other implementation-defined characters
nondigit: One of
_ a b c (...) z A B C (...) Z
digit:
0 1 (...) 9
Note the items marked by . I'm not sure whether the current restriction
makes any problem in practice, but I could imaging that there is a legitimated
use for it, though I could not find a good example.
Currently, it is abused to call STDCALL programs which get a @n appended to
the name where n is related to how much needs to be popped from the stack.
The proper solution is to support STDCALL (PR 34112); thus I don't think this
is a proper use.
Does it make sense to change the error into a warning? Or to allow certain
other characters?
* * *
Seemingly $ is allowed by gcc -c -std=c99 -Wall -pedantic:
void t$FAst(void)
{
}
--
Summary: BIND(C): Allow non-digit/underscore/alphabetic binding
names
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: rejects-valid
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=38839
[Bug java/38840] New: GCJ internal compiler error in handle_constant under very specific combination of conditions
When compiling a class which assigns the value 1 to a variable of type static
final int, and that class has an annotation with a boolean value being set in
it, and annotation retention policy for the annotation is set RUNTIME, an
internal compiler error occurs in handle_constant.
I tried this on three different compilers, including the latest svn trunk. All
yielded the same error under the same conditions.
Tested with:
gcj (GCC) 4.2.1 (Ubuntu 4.2.1-5ubuntu5) (on 64 bit Ubuntu 7.10)
gcj (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu3) (on 32 bit Ubuntu 8.04 LTS)
gcj (GCC) 4.4.0 20090113 (experimental) (on 32 bit Ubuntu 8.04 LTS)
I do not know what options the Ubuntu binaries were built with, but I built
from svn using all defaults:
./contrib/download_ecj
./configure --prefix=$HOME/gcc-trunk/20090113
make
make install
I've constructed two files that together demonstrate the effect.
//-- TestAnnotation.java ---
package nl.vu.ivm.nils.gcj.annotation;
import java.lang.annotation.*;
@Retention(RetentionPolicy.RUNTIME)
public @interface TestAnnotation {
String eggs() default ;
int spam() default 0;
boolean foo() default false;
};
//--
//-- Test.java -
package nl.vu.ivm.nils.gcj.annotation;
import nl.vu.ivm.nils.gcj.annotation.TestAnnotation;
@TestAnnotation(eggs = yolk, spam = 5, foo = true)
public class Test {
static final int bar = 1;
};
//--
Now here goes.. all well until the third step:
$ gcj -C nl/vu/ivm/nils/gcj/annotation/TestAnnotation.java
$ gcj -C nl/vu/ivm/nils/gcj/annotation/Test.java
$ gcj -c nl/vu/ivm/nils/gcj/annotation/Test.class
In file included from built-in:0:
nl/vu/ivm/nils/gcj/annotation/Test.java:0: internal compiler error: in
handle_constant, at java/jcf-parse.c:584
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
Here is again with -v:
$ gcj -v -c nl/vu/ivm/nils/gcj/annotation/Test.class
Using built-in specs.
Reading specs from
/home/nils/gcc-trunk/latest/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../libgcj.spec
rename spec startfile to startfileorig
rename spec lib to liborig
Target: i686-pc-linux-gnu
Configured with: ./configure --prefix=/home/nils/gcc-trunk/latest
Thread model: posix
gcc version 4.4.0 20090113 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-c'
'-fbootclasspath=./:/home/nils/gcc-trunk/latest/share/java/libgcj-4.4.0.jar'
'-g1' '-shared-libgcc' '-mtune=generic'
COLLECT_GCC_OPTIONS='-v' '-c'
'-fbootclasspath=./:/home/nils/gcc-trunk/latest/share/java/libgcj-4.4.0.jar'
'-g1' '-shared-libgcc' '-mtune=generic'
/home/nils/gcc-trunk/latest/libexec/gcc/i686-pc-linux-gnu/4.4.0/jc1
nl/vu/ivm/nils/gcj/annotation/Test.class -fhash-synchronization
-fno-use-divide-subroutine -fuse-boehm-gc -fnon-call-exceptions
-fkeep-inline-functions -quiet -dumpbase Test.class -mtune=generic -auxbase
Test -g1 -version
-fbootclasspath=./:/home/nils/gcc-trunk/latest/share/java/libgcj-4.4.0.jar
-faux-classpath /tmp/cccemUCX.zip -o /tmp/ccOYsl8K.s
GNU Java (GCC) version 4.4.0 20090113 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.4.0 20090113 (experimental), GMP version
4.2.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Class path starts here:
/tmp/cccemUCX.zip/ (zip)
./ (system)
/home/nils/gcc-trunk/latest/share/java/libgcj-4.4.0.jar/ (system) (zip)
In file included from built-in:0:
nl/vu/ivm/nils/gcj/annotation/Test.java:0: internal compiler error: in
handle_constant, at java/jcf-parse.c:584
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
What drives me up the walls is that doing *any* of the following will cause
this code to compile, so it must somehow be the combination of these things
that causes the error:
* If I do not set @Retention(RetentionPolicy.RUNTIME), it compiles.
* If I do not assign anything to the boolean field in the annotation (foo in
the example), it compiles.
* If I do not make bar final, it compiles.
* If I assign 0, 2, or 3 to bar, it compiles - just not if I assign 1.
Is this some kind of corner case?
--
Summary: GCJ internal compiler error in handle_constant under
very specific combination of conditions
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nils dot de dot reus at ivm dot vu dot nl
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=38840
[Bug fortran/38838] BIND(C): Binding name expressions are wrongly rejected
--- Comment #3 from burnus at gcc dot gnu dot org 2009-01-14 16:00 --- The following seems to be rejected as well: subroutine test() bind(c, name=1_name) I don't see why this is rejected. The standard has: C540 (R509) The scalar-char-initialization-expr shall be of default character kind. but this is fulfilled. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38838
[Bug fortran/38839] BIND(C): Allow non-digit/underscore/alphabetic binding names
--- Comment #1 from burnus at gcc dot gnu dot org 2009-01-14 16:00 ---
And for the universal-character-name, the following compiles with Intel's icc
void \u01ac(void) {
}
and should be valid C99. ICC generates the identifier _u01ac. Using gcc
-fextended-identifiers
it shows up in the .o file as (readelf -a):
8: 6 FUNCGLOBAL DEFAULT1 ^^F^354
In the Fortran 2003 standard one finds:
R509 language-binding-spec is BIND (C [, NAME = scalar-char-initialization-expr
])
C540 (R509) The scalar-char-initialization-expr shall be of default character
kind.
That makes it a bit difficult to use UCNs ... From Fortran 2008 (below R508):
NOTE 5.5
The C International Standard provides a facility for creating C identifiers
whose characters are not restricted to the C basic character set. Such a C
identifier is referred to as a universal character name (6.4.3 of the C
International Standard). The name of such a C identifier might include
characters that are not part of the representation method used by the processor
for default character. If so, the C entity cannot be referenced from Fortran.
Thus currently we only need to worry about '$' and maybe some others.
Optionally supporting non-default character strings and thus UCN might be done
later on (cf. also PR 38838 comment 3).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38839
[Bug fortran/38839] BIND(C): Allow non-digit/underscore/alphabetic binding names
--- Comment #2 from burnus at gcc dot gnu dot org 2009-01-14 16:09 --- For UCN see also PR 9449. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38839
[Bug c++/38579] [4.2/4.3/4.4 Regression] Template: Wrong inherited copy-ctor visibility
--- Comment #2 from jason at gcc dot gnu dot org 2009-01-14 16:37 --- 11.2: If a class is declared to be a base class for another class using the protected access specifier, the public and protected members of the base class are accessible as protected members of the derived class. Not a bug. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38579
[Bug c++/38841] New: valgrind finds problem for broken C++ code
In the testsuite for C++ is the file g++.dg/ext/utf16-4.C I just tried to compile this file with the GNU C++ compiler version 4.4 snapshot 20090109 using valgrind. The debug output was g++.dg/ext/utf16-4.C:6:29: error: empty character constant ==9851== Conditional jump or move depends on uninitialised value(s) ==9851==at 0x5807A8: c_lex_with_flags (c-lex.c:992) ==9851==by 0x4B0ADF: cp_lexer_get_preprocessor_token (parser.c:405) ==9851==by 0x4D1C22: c_parse_file (parser.c:304) ==9851==by 0x58840C: c_common_parse_file (c-opts.c:1243) ==9851==by 0x82FA64: toplev_main (toplev.c:970) ==9851==by 0x5CF1585: (below main) (in /lib64/libc-2.9.so) It might be a good idea to process this broken C++ code in a cleaner way. Similar fun games for test case g++.dg/ext/utf32-4.C -- Summary: valgrind finds problem for broken C++ code Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38841
[Bug middle-end/38477] [strict-aliasing] warning message contains compiler-generated symbols
--- Comment #17 from rguenth at gcc dot gnu dot org 2009-01-14 16:45 --- Subject: Bug 38477 Author: rguenth Date: Wed Jan 14 16:45:22 2009 New Revision: 143374 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143374 Log: 2009-01-14 Richard Guenther rguent...@suse.de PR tree-optimization/38826 PR middle-end/38477 * tree-ssa-structalias.c (emit_alias_warning): Emit the pointer initialization notes only if we actually emitted a warning. (intra_create_variable_infos): Add constraints for a result decl that is passed by hidden reference. (build_pred_graph): Mark all related variables non-direct on address-taking. * gcc.dg/Wstrict-aliasing-bogus-pta-1.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/Wstrict-aliasing-bogus-pta-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38477
[Bug tree-optimization/38826] points-to result wrong for reads from call-clobbered vars
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-01-14 16:45 --- Subject: Bug 38826 Author: rguenth Date: Wed Jan 14 16:45:22 2009 New Revision: 143374 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143374 Log: 2009-01-14 Richard Guenther rguent...@suse.de PR tree-optimization/38826 PR middle-end/38477 * tree-ssa-structalias.c (emit_alias_warning): Emit the pointer initialization notes only if we actually emitted a warning. (intra_create_variable_infos): Add constraints for a result decl that is passed by hidden reference. (build_pred_graph): Mark all related variables non-direct on address-taking. * gcc.dg/Wstrict-aliasing-bogus-pta-1.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/Wstrict-aliasing-bogus-pta-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38826
[Bug tree-optimization/38826] points-to result wrong for reads from call-clobbered vars
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-01-14 16:45 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38826
[Bug middle-end/38477] [strict-aliasing] warning message contains compiler-generated symbols
--- Comment #18 from rguenth at gcc dot gnu dot org 2009-01-14 16:47 --- 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=38477
[Bug middle-end/38503] [4.4 regression] warnings from -isystem headers strikes back.
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-01-14 16:48 --- I just installed a fix - can you verify if all the annoying warnigns are gone? Thx! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38503
[Bug c++/36334] [4.2/4.3/4.4 Regression] typedef to function type leads to problems
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-05-26 14:46:26 |2009-01-14 16:49:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36334
[Bug preprocessor/38842] New: Problem with SystemC compilation using GCC 4.3.2
Hi , Dear Stuff, Lastly I wanted to install SystemC on my linux Ubuntu 8.10(Intrepid) with kernel 2.6.27-7, but I got some problems at compilation time with GCC 4.3.2: g++ -I. -I. -I../../../../src/sysc/utils -I../../../../src-Wall -DSC_INCLUDE_FX -O3 -c -o sc_utils_ids.o `test -f '../../../../src/sysc/utils/sc_utils_ids.cpp' || echo '../../../../src/sysc/utils/'`../../../../src/sysc/utils/sc_utils_ids.cpp ../../../../src/sysc/utils/sc_utils_ids.cpp: In function 'int sc_core::initialize()': ../../../../src/sysc/utils/sc_utils_ids.cpp:113: error: 'getenv' is not a member of 'std' ../../../../src/sysc/utils/sc_utils_ids.cpp: At global scope: ../../../../src/sysc/utils/sc_utils_ids.cpp:122: warning: 'sc_core::forty_two' defined but not used make[3]: *** [sc_utils_ids.o] Error 1 make[3]: Leaving directory `/home/khalil/Projects/systemc-2.2.0/objdir/src/sysc/utils' make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory `/home/khalil/Projects/systemc-2.2.0/objdir/src/sysc' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/home/khalil/Projects/systemc-2.2.0/objdir/src' make: *** [install-recursive] Error 1 Please, can you give me any solution to this problem, because I'm really stuck! What do you think of downgrading my GCC 4.3.2 to GCC 3.2.3? Thank you for your time, I look to hear from you sooner. Regards -- Summary: Problem with SystemC compilation using GCC 4.3.2 Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: conanedo08 at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38842
[Bug target/38781] PR38151: valgrind finds problem
--- Comment #3 from hjl dot tools at gmail dot com 2009-01-14 17:07 --- An updated patch is at http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00747.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- |http://gcc.gnu.org/ml/gcc- |patches/2009- |patches/2009- |01/msg00738.html|01/msg00747.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38781
[Bug preprocessor/38843] New: Problem with SystemC compilation using GCC 4.3.2
Hi , Dear Stuff, Lastly I wanted to install SystemC on my linux Ubuntu 8.10(Intrepid) with kernel 2.6.27-7, but I got some problems at compilation time with GCC 4.3.2: g++ -I. -I. -I../../../../src/sysc/utils -I../../../../src-Wall -DSC_INCLUDE_FX -O3 -c -o sc_utils_ids.o `test -f '../../../../src/sysc/utils/sc_utils_ids.cpp' || echo '../../../../src/sysc/utils/'`../../../../src/sysc/utils/sc_utils_ids.cpp ../../../../src/sysc/utils/sc_utils_ids.cpp: In function 'int sc_core::initialize()': ../../../../src/sysc/utils/sc_utils_ids.cpp:113: error: 'getenv' is not a member of 'std' ../../../../src/sysc/utils/sc_utils_ids.cpp: At global scope: ../../../../src/sysc/utils/sc_utils_ids.cpp:122: warning: 'sc_core::forty_two' defined but not used make[3]: *** [sc_utils_ids.o] Error 1 make[3]: Leaving directory `/home/khalil/Projects/systemc-2.2.0/objdir/src/sysc/utils' make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory `/home/khalil/Projects/systemc-2.2.0/objdir/src/sysc' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/home/khalil/Projects/systemc-2.2.0/objdir/src' make: *** [install-recursive] Error 1 Please, can you give me any solution to this problem, because I'm really stuck! What do you think of downgrading my GCC 4.3.2 to GCC 3.2.3? Thank you for your time, I look to hear from you sooner. Regards -- Summary: Problem with SystemC compilation using GCC 4.3.2 Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: conanedo08 at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38843
[Bug java/38717] gcc 4.4.0 20090102 - jc1: out of memory allocating ... (with 1 G of RAM)
--- Comment #5 from rob1weld at aol dot com 2009-01-14 17:24 --- Created an attachment (id=17099) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17099action=view) Memory Usage Report for classpath/tools/.libs/libgcj_tools_la-tools.o (In reply to comment #4) (In reply to comment #3) With 1400M (and 512M swap) it dies here: ... -g -O2 -m64 -MT classpath/tools/libgcj_tools_la-tools.lo -MD -MP -MF classpath/tools/.deps/libgcj_tools_la-tools.Tpo -c classpath/tools/tools.zip -fPIC -o classpath/tools/.libs/libgcj_tools_la-tools.o jc1: out of memory allocating 4072 bytes after a total of 380526592 bytes ... I manually compiled the one file and added these commands: -v -fmem-report -ftime-report -fpre-ipa-mem-report -fpost-ipa-mem-report # cd /usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava # /usr/share/src/gcc_build/gcc/gcj -B/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava/ -B/usr/share/src/gcc_build/gcc/ -ffloat-store -fomit-frame-pointer -Usun -fclasspath= -fbootclasspath=../../../../gcc_trunk/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -findirect-dispatch -fno-indirect-classes -fsource-filename=/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava/classpath/tools/all-classes.lst -g -O2 -v -fmem-report -ftime-report -fpre-ipa-mem-report -fpost-ipa-mem-report -m64 -MT classpath/tools/libgcj_tools_la-tools.lo -MD -MP -MF classpath/tools/.deps/libgcj_tools_la-tools.Tpo -c classpath/tools/tools.zip -fPIC -o classpath/tools/.libs/libgcj_tools_la-tools.o 21 | tee /usr/share/src/gcc_build/test_gcc_memory_for_libgcj_tools_compile.result.txt Notice: 1. The report of the Memory still allocated at the end of the compilation process. 2. The line ??? tree nodes created 3. Notice this section, bad news followed by an empty section: Heap vectors: source locationLeak Peak Times --- gimplify.c:1593 (gimplify_switch_expr)0: 0.0% 40 123: 0.0% gimplify.c:238 (gimple_push_bind_expr)0: 0.0% 40 4250: 1.6% tree-eh.c:637 (record_in_goto_queue_label)0: 0.0% 48 13: 0.0% gimple-low.c:113 (lower_function_body)0: 0.0% 72 4251: 1.6% gimplify.c:1951 (gimplify_compound_lval) 0: 0.0%144 260891:96.5% gimplify.c:239 (gimple_push_bind_expr)0: 0.0%400 139: 0.1% gimplify.c:1670 (gimplify_case_label_expr)0: 0.0% 1984 128: 0.0% function.c:4107 (push_struct_function) 24: 0.2% 24 1: 0.0% java/class.c:1797 (make_class_data) 15068:99.8% 16696 598: 0.2% Total 15092 270394 source locationLeak Peak Times --- --- 4. Lots in the Garbage, Leak and Times piles: source location GarbageFreed Leak OverheadTimes --- ... source location GarbageFreed Leak OverheadTimes --- ... tree-ssa-operands.c:499 (ssa_operand_alloc) 0: 0.0% 85135158:32.8% 0: 0.0%2324278: 7.2% 11654 ... gimplify.c:522 (create_tmp_var_raw)43432400: 6.9% 0: 0.0%1482184: 2.1% 0: 0.0% 510393 tree-ssanames.c:141 (make_ssa_name_fn) 57218392: 9.1% 0: 0.0%1459640: 2.0% 0: 0.0%1047822 Total 631644212259687118 72135253 32455003 24761794 source location GarbageFreed Leak OverheadTimes --- 5. Slow too: Execution times (seconds) ... TOTAL : 581.1856.35 707.22 909163 kB Thanks Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38717
[Bug preprocessor/38843] Problem with SystemC compilation using GCC 4.3.2
--- Comment #1 from paolo dot carlini at oracle dot com 2009-01-14 17:36 --- First, this issue has nothing to do with the preprocessor. Actually, looking at your PR, has nothing to do with GCC. Apparently, the authors of SystemC forgot to include cstdlib in sc_utils_ids.cpp, and that shows up only now because the C++ headers delivered with 4.3.2 have been cleaned-up and less is included as an implementation detail. I would suggest reporting the issue to the SystemC authors; do not downgrade GCC; if you want, in the meanwhile experiment with adding the missing include yourself. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38843
[Bug preprocessor/38843] Problem with SystemC compilation using GCC 4.3.2
--- Comment #2 from schwab at suse dot de 2009-01-14 17:46 --- *** Bug 38842 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38843
[Bug preprocessor/38842] Problem with SystemC compilation using GCC 4.3.2
--- Comment #1 from schwab at suse dot de 2009-01-14 17:46 --- *** This bug has been marked as a duplicate of 38843 *** -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38842
[Bug bootstrap/38728] gcc 4.4.0 20090104 - make install is relinking `libgij.la'
--- Comment #3 from rob1weld at aol dot com 2009-01-14 17:54 --- (In reply to comment #2) Relinking in itself is not a bug. You can avoid it on some systems (but likely not on yours) with --enable-fast-install. On some systems it is simply necessary. If there is a specific problem you have with the relinking process, then please describe that and reopen the bug. Thanks for looking at this. I was only pointing out that _everything_ _else_ worked as-is and only the _one_ _file_ needed to be re-linked during installation. I'll leave this 'oddity' as RESOLVED INVALID. YT, Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38728
[Bug other/38805] sed Unterminated `s' command
--- Comment #7 from rwild at gcc dot gnu dot org 2009-01-14 18:02 --- Please go into the gcc directory in the build tree and confirm that ./config.status reproduces the errors (ignore further errors). If yes, then please show the output of ./config.status -d wc confstat*/* If any of the sed scripts are longer than roughly 6KB, or have line lengths over 4000 bytes, then try /usr/xpg4/bin/sed (put /usr/xpg4/bin early in PATH). Or try GNU sed. Solaris' seds are rather limited, although the configure scripts should usually work around most known issues. The @gcc_config_arguments@ substitution line could be rather long in your case. If all sed programs show the same error, then please post the sed script that causes it (the 'config.status -d' left it behind in that temporary subdir). BTW, your build log shows that you are patching the GCC sources quite a bit: ... [DEBUG]Applying patch '/export/home/thomas/workspace/ct-ng/trunk/patches/gcc/4.3.2/130-cross-compile.patch' [DEBUG]== Executing: 'patch -g0 -F1 -p1 -f' [ALL ]patching file gcc/configure [ALL ]patching file gcc/configure.ac ... [DEBUG]Applying patch '/export/home/thomas/workspace/ct-ng/trunk/patches/gcc/4.3.2/250-sh-pr24836.patch' [DEBUG]== Executing: 'patch -g0 -F1 -p1 -f' [ALL ]patching file gcc/configure [ALL ]patching file gcc/configure.ac ... Please prove that none of the several dozen patches are relevant to this issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38805
[Bug awt/38803] [4.4 regression] Configure with --enable-java-awt=x requires Escher
--- Comment #1 from rob1weld at aol dot com 2009-01-14 18:06 --- Built and tested with my hacks, works. Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38803
[Bug c++/38844] New: [4.3/4.4 Regression] deadlock with __attribute__((always_inline)) at -O1 and above
gcc seems to deadlock with the following code at -O1 and above:
=
struct A {
inline __attribute__((always_inline)) A()
{
A();
A();
}
};
int main()
{
A();
return 0;
}
=
Command line:
g++ deadlock.cpp -o deadlock.o -O1
--
Summary: [4.3/4.4 Regression] deadlock with
__attribute__((always_inline)) at -O1 and above
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
GCC host triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38844
[Bug c++/38844] [4.3/4.4 Regression] deadlock with __attribute__((always_inline)) at -O1 and above
--- Comment #1 from zsojka at seznam dot cz 2009-01-14 18:14 --- Created an attachment (id=17100) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17100action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38844
[Bug c/38845] New: aligned attribute not working on ms-extensions anonymous struct
The alignment of an anonymous structure defined as a member
of another structure (thanks to -fms-extensions) cannot be
forced with __attribute__((aligned)).
This problem occurs on cygwin with default gcc packages:
gcc version 4.3.2 20080827 (alpha-testing) 1 (GCC)
and:
gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
The code below show the exact problem by comparing the sizes and alignments
of a named struct and an anonynous one.
#include stdio.h
struct nested
{
char a;
char b;
};
struct unaligned
{
char misalign;
struct nested __attribute__((aligned(4)));
};
struct aligned
{
char misalign;
struct nested name __attribute__((aligned(4)));
};
int main(int argc, char * argv[])
{
printf(%d %d - %d %d\n,
sizeof(struct unaligned), sizeof(struct aligned),
__alignof__(struct unaligned), __alignof__(struct aligned));
}
options:
gcc-4 -std=c99 -fms-extensions align.c
output:
3 8 - 1 4
--
Summary: aligned attribute not working on ms-extensions anonymous
struct
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: acalando at free dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38845
[Bug middle-end/38846] New: [Graphite] 70% slower using -floop* than without graphite (gas_dyn of Polyhedron)
This is with gfortran 4.4.0 20090114 [trunk revision 143364] and the Polyhedron test suite, http://www.polyhedron.co.uk/MFL6VW74649 on AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ running openSUSE Factory x86-64. First the good news: No ICE and no result-checking failures. The geometric average shows 4% longer runtime for -floop*, which is dominated by the 70% slower gas_dyn. Other programs are faster such as capacita (by 6%) or slower such as test_fpu (by 13%). [I picked the extrema; mostly the changes seem to be only slightly above noise with a slight tendency to better performance.] I was using the following options, which yielded the stated run time for gas_dyn: gfortran -march=opteron -ffast-math -funroll-loops -ftree-vectorize -ftree-loop-linear -msse3 -O3 - Runtime = 11.73 seconds gfortran -march=opteron -floop-interchange -floop-strip-mine -floop-block -ffast-math -funroll-loops -ftree-vectorize -ftree-loop-linear -msse3 -O3 - Runtime = 19.95033 -- Summary: [Graphite] 70% slower using -floop* than without graphite (gas_dyn of Polyhedron) Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38846
[Bug c++/38579] [4.2/4.3/4.4 Regression] Template: Wrong inherited copy-ctor visibility
--- Comment #3 from syntheticpp at gmx dot net 2009-01-14 18:29 ---
11.2 is talking about a different case.
When you instantiate the integer template parameter manually you will see that
it is really a bug:
struct Policy
{
protected:
Policy() {}
Policy(const Policy) {}
};
templateclass P
struct BugGcc0 :
protected P
//public P
{
BugGcc0() {}
};
templateclass P
struct BugGcc1 : public P
{
BugGcc1() {}
templateclass P1
BugGcc1(const BugGcc0P1 t) : P(t) {}
};
void foo()
{
BugGcc0Policy d0;
BugGcc1Policy d1(d0);
}
The Policy ctor is visible within BugGcc1 (because it is inherited protected)
but it is not visible to a different class (again, because it is inherited
protected).
BugGcc0 and BugGcc1 only have the same base class but they are NOT of same type
which 11.2 talks about.
The protected policy ctor is only visible for BugGcc0 but not for BugGcc1.
--
syntheticpp at gmx dot net changed:
What|Removed |Added
CC||syntheticpp at gmx dot net
Status|RESOLVED|REOPENED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38579
[Bug middle-end/38503] [4.4 regression] warnings from -isystem headers strikes back.
--- Comment #10 from pluto at agmk dot net 2009-01-14 18:29 --- (In reply to comment #9) I just installed a fix - can you verify if all the annoying warnigns are gone? Thx! they are still there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38503
[Bug c/38847] New: error: Link tests are not allowed after GCC_NO_EXECUTABLES
I'm trying to build gcc-4.3.2 for powerpc-405-gnu-linux.
I'm using binutils 2.18 built earlier with no erros according to LSF 6.4
Steps for building gcc (according to LSF 6.4):
../gcc-4.3.2/configure \
--target=powerpc-405-linux-gnu --prefix=/tools \
--disable-nls --disable-shared --disable-multilib \
--disable-decimal-float --disable-threads \
--disable-libmudflap --disable-libssp \
--disable-libgomp --enable-languages=c
make
After a while I got the following error:
checking dynamic linker characteristics... configure: error: Link tests are not
allowed after GCC_NO_EXECUTABLES.
make[1]: *** [configure-target-libssp] Error 1
make[1]: Leaving directory `/HMeyzam08/a99059/GNU/gcc/bin/gcc-4.3.2'
make: *** [all] Error 2
In config.log I got the following errors:
conftest.c:2: error: expected '=', ',', ';', 'asm' or '__attribute__' before
'me'
configure:3636: $? = 1
configure: failed program was:
| #ifndef __cplusplus
| choke me
| #endif
-
conftest.cc: In function 'int main()':
conftest.cc:13: error: 'exit' was not declared in this scope
configure:4088: $? = 1
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME
| #define PACKAGE_TARNAME
| #define PACKAGE_VERSION
| #define PACKAGE_STRING
| #define PACKAGE_BUGREPORT
| /* end confdefs.h. */
|
| int
| main ()
| {
| exit (42);
| ;
| return 0;
| }
configure:4616: gcc -B/usr/bin/ -o conftest -g -O2conftest.c -lmpfr -lgmp
5
conftest.c: In function 'main':
conftest.c:19: error: 'choke' undeclared (first use in this function)
conftest.c:19: error: (Each undeclared identifier is reported only once
conftest.c:19: error: for each function it appears in.)
conftest.c:19: error: expected ';' before 'me'
conftest.c:21: error: 'n' undeclared (first use in this function)
configure:4622: $? = 1
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME
| #define PACKAGE_TARNAME
| #define PACKAGE_VERSION
| #define PACKAGE_STRING
| #define PACKAGE_BUGREPORT
| #ifdef __cplusplus
| extern C void std::exit (int) throw (); using std::exit;
| #endif
| /* end confdefs.h. */
| #include gmp.h
| #include mpfr.h
| int
| main ()
| {
|
| #if MPFR_VERSION MPFR_VERSION_NUM(2,3,0)
| choke me
| #endif
| mpfr_t n; mpfr_init(n);
|
| ;
| return 0;
| }
configure:4643: result: buggy but acceptable
What is missing in my build ?
I'm using the gmp,mpfr installed in red-hat 5.1.
I didn't install gmp-4.2.4, mpfr-2.3.2.
Thanks.
--
Summary: error: Link tests are not allowed after
GCC_NO_EXECUTABLES
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: veredz at elta dot co dot il
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: powerpc-405-linux-gnu
GCC target triplet: powerpc-405-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38847
[Bug c/38847] error: Link tests are not allowed after GCC_NO_EXECUTABLES
--- Comment #1 from veredz at elta dot co dot il 2009-01-14 18:38 --- Created an attachment (id=17101) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17101action=view) config.log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38847
Re: [Bug middle-end/38846] New: [Graphite] 70% slower using -floop* than without graphite (gas_dyn of Polyhedron)
Hi, Thanks for this report. Please also test with the code of graphite branch that contains a patch that schedules several scalar optimizations that can improve the quality of the code generated. Thanks, Sebastian Pop -- AMD - GNU Tools
[Bug middle-end/38846] [Graphite] 70% slower using -floop* than without graphite (gas_dyn of Polyhedron)
--- Comment #1 from sebpop at gmail dot com 2009-01-14 18:42 --- Subject: Re: New: [Graphite] 70% slower using -floop* than without graphite (gas_dyn of Polyhedron) Hi, Thanks for this report. Please also test with the code of graphite branch that contains a patch that schedules several scalar optimizations that can improve the quality of the code generated. Thanks, Sebastian Pop -- AMD - GNU Tools -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38846
[Bug middle-end/38846] [Graphite] 70% slower using -floop* than without graphite (gas_dyn of Polyhedron)
--- Comment #2 from burnus at gcc dot gnu dot org 2009-01-14 18:45 --- The culprit is -floop-block (which is already enabled by default in the graphite branch with -O2). Using only -floop-interchange -floop-strip-mine I get a run time inbetween (16.5s, single run). Using only -fgraphite-identity I also get ~16.5s. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38846
[Bug tree-optimization/38785] huge performance regression on EEMBC bitmnp01
--- Comment #9 from amylaar at gcc dot gnu dot org 2009-01-14 18:47 --- I think the disregard for conditional execution opportunities and the assumption that phi nodes have no execution cost are two separate issues. I'd like to address the latter first, because it causes exponential code and execution time growth. A phi node joining two constants has at least the cost of a constant load. A phi node joining two different variables which are initialized by a graph with constant leafs costs at least a reg-reg copy on one arm, plus the cost of its parents if these are needed solely for this phi node. Therefore, if an expression is only partially anticipatable, we should compare the cost of any phi node needed to compute it early with the estimated likelyhod that such a computatatio, once done, is actually needed, multiplied with the cost of the replaced operation. Can we use edge probabilities inside tree-pre to calculate execution probabilities? Can we calculate the cost of replaced expressions? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38785
[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath
--- Comment #21 from r dot emrich at de dot tecosim dot com 2009-01-14 18:47 --- The link step for libstdc++.la gives warnings for failed file format test using a file magic. This is wrong! The problem results from different output of native file command and the linux file command. libtool uses the following regex: (s[0-9][0-9][0-9]|ELF-[0-9][0-9]) shared object file - PA-RISC [0-9].[0-9] This matches for the native file command output: libm.2: ELF-64 shared object file - PA-RISC 2.0 (LP64) But not for the output of the Linux file command: libm.2: ELF 64-bit MSB shared object, PA-RISC 2.0 (LP64) version 1, not stripped Any idea how to fix this? I think in libtool.m4 in the top directory. But I'm lost with regex expressions. I dont't know if the warnings at the end of this message are a result of this issue or different one. The linker complains about fde encoding in .libs/bitmap_allocator.o(.eh_frame) prevents .eh_frame_hdr table being created. There are a lot. Rainer /bin/sh ../libtool --tag CXX --mode=link /SCRATCH/tmp.jrCZz25467/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.4.0-test/gcc-4.4.0-test/./gcc/xgcc -shared-libgcc -B/SCRATCH/tmp.jrCZz25467/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.4.0-test/gcc-4.4.0-test/./gcc -nostdinc++ -L/SCRATCH/tmp.jrCZz25467/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.4.0-test/gcc-4.4.0-test/hppa64-hp-hpux11.00/libstdc++-v3/src -L/SCRATCH/tmp.jrCZz25467/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.4.0-test/gcc-4.4.0-test/hppa64-hp-hpux11.00/libstdc++-v3/src/.libs -B/opt/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/cross/HP-UX/hppa64-hp-hpux11.00/B.11.00/gcc-4.4.0-test/hppa64-hp-hpux11.00/bin/ -B/opt/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/cross/HP-UX/hppa64-hp-hpux11.00/B.11.00/gcc-4.4.0-test/hppa64-hp-hpux11.00/lib/ -isystem /opt/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/cross/HP-UX/hppa64-hp-hpux11.00/B.11.00/gcc-4.4.0-test/hppa64-hp-hpux11.00/include -isystem /opt/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/cross/HP-UX/hppa64-hp-hpux11.00/B.11.00/gcc-4.4.0-test/hppa64-hp-hpux11.00/sys-include -Wl,-O1 -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -o libstdc++.la -rpath /opt/gnu/cross-gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/cross/HP-UX/hppa64-hp-hpux11.00/B.11.00/gcc-4.4.0-test/hppa64-hp-hpux11.00/lib -version-info 6:11:0 -Wl,--version-script=libstdc++-symbols.ver -lm atomic.lo bitmap_allocator.lo pool_allocator.lo mt_allocator.lo codecvt.lo compatibility.lo complex_io.lo ctype.lo debug.lo functexcept.lo hash.lo hash_c++0x.lo globals_io.lo hashtable.lo hashtable_c++0x.lo ios.lo ios_failure.lo ios_init.lo ios_locale.lo limits.lo limits_c++0x.lo list.lo debug_list.lo locale.lo locale_init.lo locale_facets.lo localename.lo stdexcept.lo strstream.lo system_error.lo tree.lo allocator-inst.lo concept-inst.lo fstream-inst.lo ext-inst.lo ios-inst.lo iostream-inst.lo istream-inst.lo istream.lo locale-inst.lo misc-inst.lo ostream-inst.lo sstream-inst.lo streambuf-inst.lo streambuf.lo string-inst.lo valarray-inst.lo wlocale-inst.lo wstring-inst.lo mutex.lo condition_variable.lo chrono.lo thread.lo atomicity.lo codecvt_members.lo collate_members.lo ctype_members.lo messages_members.lo monetary_members.lo numeric_members.lo time_members.lo basic_file.lo c++locale.lo parallel_list.lo parallel_settings.lo ../libmath/libmath.la ../libsupc++/libsupc++convenience.la -lm *** Warning: linker path does not have real file for library -lm. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libm and none of the candidates passed a file format test *** using a file magic. Last file checked: /opt/tec/setup/sys-root/HP-UX/hppa64-hp-hpux11.00/B.11.00/usr/lib/pa20_64/./libm.2 *** Warning: linker path does not have real file for library -lgcc_s. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libgcc_s and none of the candidates passed a file format test *** using a file magic. Last file checked: /opt/gnu/gcc/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.4.0-test/lib/libgcc_s.so.1 *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. libtool: link: /SCRATCH/tmp.jrCZz25467/Linux/x86_64-unknown-linux-gnu/openSUSE_10.3/gcc-4.4.0-test/gcc-4.4.0-test/./gcc/xgcc -shared-libgcc
[Bug c++/38844] [4.3/4.4 Regression] deadlock with __attribute__((always_inline)) at -O1 and above
--- Comment #2 from zsojka at seznam dot cz 2009-01-14 19:03 --- Created an attachment (id=17102) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17102action=view) another testcase, this one fails _only_ with -O1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38844
[Bug middle-end/38616] [4.3 Regression] Wrong code when -O3 or -O2 -fstack-protector used
--- Comment #10 from danglin at gcc dot gnu dot org 2009-01-14 19:18 --- Test fails on hppa64-hp-hpux11.11: Executing on host: /mnt/gnu/gcc/objdir/gcc/xgcc -B/mnt/gnu/gcc/objdir/gcc/ /mnt/ gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr38616.c -O2 -fstack-protector -fno-show-col umn -lm -o ./pr38616.exe(timeout = 300) /mnt/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr38616.c:1: warning: -fstack-protector no t supported for this target ld: Can't find library for -lssp_nonshared Fatal error. collect2: ld returned 1 exit status compiler exited with status 1 output is: /mnt/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr38616.c:1: warning: -fstack-protector no t supported for this target ld: Can't find library for -lssp_nonshared Fatal error. collect2: ld returned 1 exit status -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38616
[Bug libstdc++/35569] [c++0x] std::bind result functor doesn't accept rvalues
--- Comment #2 from jeff at schwabcenter dot com 2009-01-14 19:20 ---
I'm seeing the same thing with Boost.Bind (boost 1.37, GCC 4.2.1).
#include boost/bind.hpp
#include functional
using boost::bind;
using std::multiplies;
int main() {
// Fine.
int const lvalue = 5;
bind(multipliesint(),4,_1)(lvalue);
// Mistaken for a cast.
bind(multipliesint(),4,_1)(5);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35569
[Bug middle-end/38616] [4.3 Regression] Wrong code when -O3 or -O2 -fstack-protector used
--- Comment #11 from pinskia at gcc dot gnu dot org 2009-01-14 19:24 --- /mnt/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr38616.c:1: warning: -fstack-protector That has already been fixed: http://gcc.gnu.org/ml/gcc-cvs/2009-01/msg00372.html Fixed so closing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38616
[Bug target/17381] Unnecessary register move for float extend
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-01-14 19:52 --- I almost have a patch for this. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17381
[Bug c/38848] New: Optimizer -O2 doesn't work on linear algebra code on double data type
/* The program doesn't terminate with -O2 but works with no optimization on
double Datatype */
#includestdio.h
#includestdlib.h
#includesys/types.h
#includesys/time.h
#includeunistd.h
#define STRMAX 1000
#ifdef FLOAT
#define FTYPE(function) function##_f
#define DTYPE float
#define SIZE 4
#endif
#ifdef DOUBLE
#define FTYPE(function) function##_d
#define DTYPE double
#define SIZE 8
#endif
#ifdef EXTENDED
#define FTYPE(function) function##_e
#define DTYPE long double
#define SIZE 16
#endif
void FTYPE(LEAST_SQUARE_QR)(DTYPE *A, DTYPE *x, DTYPE *b, int ZA, int SA)
{
DTYPE *R, *Qinvb;
int i,j,k,l;
DTYPE *ai,an,e,*b1;
R=(DTYPE *)malloc(ZA*SA*SIZE);
Qinvb=(DTYPE *)malloc(ZA*SIZE);
ai=(DTYPE *)malloc(ZA*SIZE);
b1=(DTYPE *)malloc(ZA*SIZE);
FTYPE(COPY)(A,R,ZA*SA);
FTYPE(COPY)(b,Qinvb,ZA);
i=0;
for(j=0;ji;j++)
{
*(ai+j)=0.0;
}
an=0.0;
for(j=i;jZA;j++)
{
*(ai+j)=*(R+j*SA+i);
an+=*(ai+j) * *(ai+j);
}
an=FTYPE(SQUARE_ROOT)(an);
if(*(ai+i)0)
{
*(ai+i)+=an;
}
else
{
*(ai+i)-=an;
}
an=0.0;
for(j=i;jZA;j++)
{
an+= *(ai+j) * *(ai+j);
}
an=FTYPE(SQUARE_ROOT)(an);
an=1.0/an;
for(j=i;jZA;j++)
{
*(ai+j)=*(ai+j)*an;
}
for(l=0;lSA;l++)
{
for(k=0;kZA;k++)
{
*(b1+k)=0.0;
for(j=0;jk;j++)
{
e= -2.0* *(ai+j) * *(ai+k);
*(b1+k)+=e * *(R+j*SA+l);
}
e=1.0 - 2.0* *(ai+j) * *(ai+k);
*(b1+k)+=e * *(R+j*SA+l);
for(j=k+1;jZA;j++)
{
e= -2.0* *(ai+j) * *(ai+k);
*(b1+k)+=e * *(R+j*SA+l);
}
}
for(k=0;kZA;k++)
{
*(R+k*SA+l)=*(b1+k);
}
}
for(k=1;kZA;k++)
{
*(R+k*SA)=0.0;
}
for(k=0;kZA;k++)
{
*(b1+k)=0.0;
}
for(k=0;kZA;k++)
{
for(j=0;jk;j++)
{
e = -2.0* *(ai+j) * *(ai+k);
*(b1+k) +=e * *(Qinvb+j);
}
e=1.0 - 2.0* *(ai+j) * *(ai+k);
*(b1+k)+=e * *(Qinvb+j);
for(j=k+1;jZA;j++)
{
e= -2.0* *(ai+j) * *(ai+k);
*(b1+k)+=e * *(Qinvb+j);
}
}
for(k=0;kZA;k++)
{
*(Qinvb+k)=*(b1+k);
}
for(i=1;iSA;i++)
{
for(j=0;ji;j++)
{
*(ai+j)=0.0;
}
an=0.0;
for(j=i;jZA;j++)
{
*(ai+j)=*(R+j*SA+i);
an+=*(ai+j) * *(ai+j);
}
an=FTYPE(SQUARE_ROOT)(an);
if(*(ai+i)0)
{
*(ai+i)+=an;
}
else
{
*(ai+i)-=an;
}
an=0.0;
for(j=i;jZA;j++)
{
an+= *(ai+j) * *(ai+j);
}
an=FTYPE(SQUARE_ROOT)(an);
an=1.0/an;
for(j=i;jZA;j++)
{
*(ai+j)=*(ai+j)*an;
}
for(l=i;lSA;l++)
{
for(k=0;kZA;k++)
{
*(b1+k)=0.0;
for(j=0;jk;j++)
{
e= -2.0* *(ai+j) * *(ai+k);
*(b1+k)+=e * *(R+j*SA+l);
}
e=1.0 - 2.0* *(ai+j) * *(ai+k);
*(b1+k)+=e * *(R+j*SA+l);
for(j=k+1;jZA;j++)
{
e= -2.0* *(ai+j) * *(ai+k);
*(b1+k)+=e * *(R+j*SA+l);
}
}
for(k=0;kZA;k++)
{
*(R+k*SA+l)=*(b1+k);
}
}
for(k=0;kZA;k++)
{
*(b1+k)=0.0;
for(j=0;jk;j++)
{
e= -2.0* *(ai+j) * *(ai+k);
*(b1+k)+=e * *(Qinvb+j);
}
e=1.0 - 2.0* *(ai+j) * *(ai+k);
*(b1+k)+=e * *(Qinvb+j);
for(j=k+1;jZA;j++)
{
e= -2.0* *(ai+j) * *(ai+k);
*(b1+k)+=e * *(Qinvb+j);
}
}
for(k=0;kZA;k++)
{
*(Qinvb+k)=*(b1+k);
}
for(k=i+1;kZA;k++)
{
*(R+k*SA+i)=0.0;
}
}
for(i=SA;i=1;i--)
{
*(x+i-1)=*(Qinvb+i-1);
for(j=i+1;j=SA;j++)
{
*(x+i-1)-= *(x+j-1) * *(R+SA*(i-1)+j-1);
}
*(x+i-1)=*(x+i-1)/ *(R+SA*(i-1)+i-1);
}
free(b1);
free(R);
free(Qinvb);
free(ai);
return;
}
--
Summary: Optimizer -O2 doesn't work on linear algebra code on
double data type
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rbenedik at fsmat dot htu dot tuwien dot ac dot at
GCC build triplet: gcc-Version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC)
GCC host triplet: x86_64-redhat-linux - Fedora 10.0
GCC target triplet: x86_64-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38848
[Bug middle-end/38848] Optimizer -O2 doesn't work on linear algebra code on double data type
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38848
[Bug fortran/38813] ICE with C_LOC(array)
--- Comment #3 from mikael at gcc dot gnu dot org 2009-01-14 20:07 --- is_scalar_expr_ptr is weird. Those are the things to change in it, IMHO: - is_scalar_expr_ptr does not need to check whether character lengths are equal to 1 as arbitrary length character variables are considered as scalars by the standard; - full arrays, (and array ranges as well) are non-scalar even if they are of size 1; - the whole reference chain should be checked, not only the last one. Hum, may be it could be reduced to a mere expr-rank == 0 ? -- mikael at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-14 20:07:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38813
[Bug target/38824] [4.4 regression] performance regression of sse code from 4.2/4.3
--- Comment #3 from hubicka at gcc dot gnu dot org 2009-01-14 20:20 --- It might be IRA change. Chips generally preffer separate load and execute instruction as in the old loop over the load+execute since they are easier to retire. Splitting the instruction post reload probably won't do much good, since there is extra move already. If just splitting the instruction would help, we can macroize: (define_peephole2 [(match_scratch:SI 2 r) (parallel [(set (match_operand:SI 0 register_operand ) (match_operator:SI 3 arith_or_logical_operator [(match_dup 0) (match_operand:SI 1 memory_operand )])) (clobber (reg:CC FLAGS_REG))])] optimize_insn_for_speed_p () ! TARGET_READ_MODIFY [(set (match_dup 2) (match_dup 1)) (parallel [(set (match_dup 0) (match_op_dup 3 [(match_dup 0) (match_dup 2)])) (clobber (reg:CC FLAGS_REG))])] ) peephole for vector modes too. Vladimir, perhaps IRA can be tweaked here somehow? -- hubicka at gcc dot gnu dot org changed: What|Removed |Added CC||vmakarov at redhat dot com, ||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38824
[Bug target/38824] [4.4 Regression] performance regression of sse code from 4.2/4.3
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||missed-optimization Summary|[4.4 regression] performance|[4.4 Regression] performance |regression of sse code from |regression of sse code from |4.2/4.3 |4.2/4.3 Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38824
[Bug target/38811] [4.4 Regression] internal compiler error: in compensate_edge, at reg-stack.c:2754
--- Comment #8 from jakub at gcc dot gnu dot org 2009-01-14 20:29 --- Fixed. The testcase was added in http://gcc.gnu.org/viewcvs?root=gccview=revrev=143376 -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38811
[Bug target/38824] [4.4 regression] performance regression of sse code from 4.2/4.3
--- Comment #4 from hubicka at gcc dot gnu dot org 2009-01-14 20:31 --- Actually perhaps in simple case like this even peep2 will work since we can copyprop will fix it later. I am trying to add the peep -- hubicka at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |hubicka at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Keywords|missed-optimization | Last reconfirmed|-00-00 00:00:00 |2009-01-14 20:31:52 date|| Summary|[4.4 Regression] performance|[4.4 regression] performance |regression of sse code from |regression of sse code from |4.2/4.3 |4.2/4.3 Target Milestone|4.4.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38824
[Bug fortran/38849] New: ICE in fold_convert with C_F_POINTER and C binding
This program gives an ICE when compiled with gfortran 4.4 trunk: FUNCTION myfortran_error () USE ISO_C_BINDING IMPLICIT NONE CHARACTER(LEN=5) :: myfortran_error CHARACTER(KIND=C_CHAR, LEN=5), POINTER :: chararr TYPE(C_PTR) :: c_str c_str = C_NULL_PTR CALL C_F_POINTER (c_str, chararr) myfortran_error(1:1) = chararr(1) END FUNCTION myfortran_error bash-3.2# gfortran-dev reduced.f03 reduced.f03: In function 'myfortran_error': reduced.f03:8: internal compiler error: in fold_convert, at fold-const.c:2649 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. gfortran 4.3 compiles it but fails with an undefined reference to `chararr_'. Actually I'm not proficient with C binding, so I would not bet the code above is legal or doing correct things with the pointers... However, it should not ICE. -- Summary: ICE in fold_convert with C_F_POINTER and C binding Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: domob at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38849
[Bug java/38840] GCJ internal compiler error in handle_constant under very specific combination of conditions
--- Comment #1 from nils dot de dot reus at ivm dot vu dot nl 2009-01-14
20:44 ---
It is a bit further removed from the real life situation I am dealing with, but
to make testing easier I've moved it all into one file so you don't need to
bother with importing or package structure.
// - Test.java ---
import java.lang.annotation.*;
@Retention(RetentionPolicy.RUNTIME)
@interface TestAnnotation {
String eggs() default ;
int spam() default 0;
boolean foo() default false;
};
@TestAnnotation(eggs = yolk, spam = 5, foo = true)
public class Test {
static final int bar = 1;
};
// ---
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38840
[Bug other/38805] sed Unterminated `s' command
--- Comment #8 from thomas dot jourdan at gmail dot com 2009-01-14 20:45
---
Hi all
I did my homework tonight and I found the problem, thanks to your help. For
other purposes, I had to export a function in my shell this way :
---8---
function install() { ginstall $@; }
export -f install
---8---
To fool a configure script (not related to gcc) which needed GNU install
instead of SunOS install.
I had no knowledge of `config.status -d`, but this helped me a lot. I've been
able to see the confstat temporary files and figure out the problem. Thanks for
pointing this out, this will help me a lot to debug ct-ng and cross tool chain
building.
Thanks again for your help and sorry for the false alarm !
Regards,
Thomas
--
thomas dot jourdan at gmail dot com changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution||FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38805
[Bug middle-end/38503] [4.4 regression] warnings from -isystem headers strikes back.
--- Comment #11 from rguenther at suse dot de 2009-01-14 20:50 --- Subject: Re: [4.4 regression] warnings from -isystem headers strikes back. On Wed, 14 Jan 2009, pluto at agmk dot net wrote: --- Comment #10 from pluto at agmk dot net 2009-01-14 18:29 --- (In reply to comment #9) I just installed a fix - can you verify if all the annoying warnigns are gone? Thx! they are still there. Then they are either real bugs in the testcase or in PTA. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38503
[Bug tree-optimization/38785] huge performance regression on EEMBC bitmnp01
--- Comment #10 from rguenther at suse dot de 2009-01-14 20:51 --- Subject: Re: huge performance regression on EEMBC bitmnp01 On Wed, 14 Jan 2009, amylaar at gcc dot gnu dot org wrote: I think the disregard for conditional execution opportunities and the assumption that phi nodes have no execution cost are two separate issues. I'd like to address the latter first, because it causes exponential code and execution time growth. A phi node joining two constants has at least the cost of a constant load. A phi node joining two different variables which are initialized by a graph with constant leafs costs at least a reg-reg copy on one arm, plus the cost of its parents if these are needed solely for this phi node. Therefore, if an expression is only partially anticipatable, we should compare the cost of any phi node needed to compute it early with the estimated likelyhod that such a computatatio, once done, is actually needed, multiplied with the cost of the replaced operation. Can we use edge probabilities inside tree-pre to calculate execution probabilities? Can we calculate the cost of replaced expressions? You would completely underestimate the optimization opportunities PRE unleashes. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38785
[Bug c++/38850] New: Cannot find inline friend function in template class when called from within a template function
Compiling the following program:
template typename VType
class Vector2 {
private:
VType c_[2];
public:
typedef Vector2VType Self;
Vector2(const VType x, const VType y) {
c_[0] = x;
c_[1] = y;
}
friend inline Self Max(const Self v1, const Self v2) {
return Self(v1.c_[0], v1.c_[1]);
}
};
template class T
Vector2float foo(T x) {
Vector2float y(0,0);
return Max(y, y);
}
int main() {
foo(3);
return 0;
}
gives the following error:
test.cc: In function 'Vector2float foo(T) [with T = int]':
test.cc:25: instantiated from here
test.cc:13: error: no matching function for call to 'Max(Vector2float,
Vector2float)'
When compiled using GCC 4.4.0 trunk. The command line used for the compile is:
g++ -c test.cc
The output of gcc -v is:
Using built-in specs.
Target: i686-unknown-linux-gnu
Configured with: src/configure --disable-nls --enable-threads=posix
--enable-symvers=gnu --enable-__cxa_atexit --enable-c99 --enable-long-long
--with-gnu-as --with-gnu-ld --build=i686-host_pc-linux-gnu
--host=i686-host_pc-linux-gnu
--enable-shared=libgcc,libmudflap,libssp,libstdc++
--enable-languages=c,c++,fortran --with-gmp=/usr/grte/v1
--prefix=/tmp/gcc-4.3.1-glibc-2.3.6-grte/i686-unknown-linux-gnu
--target=i686-unknown-linux-gnu --enable-static-nss --with-arch=pentium3
--with-tune=pentium4
Thread model: posix
gcc version 4.4.0 20090114 (experimental)
COLLECT_GCC_OPTIONS='-v' '-c' '-shared-libgcc' '-mtune=pentium4'
'-march=pentium3'
--
Summary: Cannot find inline friend function in template class
when called from within a template function
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nvachhar at google dot com
GCC build triplet: i686-unknown-linux-gnu
GCC host triplet: i686-unknown-linux-gnu
GCC target triplet: i686-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38850
[Bug c++/38850] Cannot find inline friend function in template class when called from within a template function
--- Comment #1 from nvachhar at google dot com 2009-01-14 20:53 --- Created an attachment (id=17103) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17103action=view) Test case program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38850
[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS
--- Comment #28 from mikael at gcc dot gnu dot org 2009-01-14 20:53 --- Subject: Bug 35681 Author: mikael Date: Wed Jan 14 20:53:18 2009 New Revision: 143383 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143383 Log: 2009-01-14 Mikael Morin mikael.mo...@tele2.fr PR fortran/35681 * ChangeLog: Fix function name. PR fortran/38487 * dependency.c (gfc_check_argument_var_dependency): Move the check for pointerness inside the if block so that it doesn't affect the return value. PR fortran/38669 * trans-stmt.c (gfc_trans_call): Add the dependency code after the loop bounds calculation one. 2009-01-14 Mikael Morin mikael.mo...@tele2.fr PR fortran/38669 * gfortran.dg/elemental_dependency_3.f90: New test. * gfortran.dg/elemental_subroutine_7.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/elemental_dependency_3.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/elemental_subroutine_7.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/dependency.c branches/gcc-4_3-branch/gcc/fortran/trans-stmt.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35681
[Bug fortran/38487] Bogus Warning: INTENT(INOUT) actual argument might interfere with actual argument
--- Comment #8 from mikael at gcc dot gnu dot org 2009-01-14 20:53 --- Subject: Bug 38487 Author: mikael Date: Wed Jan 14 20:53:18 2009 New Revision: 143383 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143383 Log: 2009-01-14 Mikael Morin mikael.mo...@tele2.fr PR fortran/35681 * ChangeLog: Fix function name. PR fortran/38487 * dependency.c (gfc_check_argument_var_dependency): Move the check for pointerness inside the if block so that it doesn't affect the return value. PR fortran/38669 * trans-stmt.c (gfc_trans_call): Add the dependency code after the loop bounds calculation one. 2009-01-14 Mikael Morin mikael.mo...@tele2.fr PR fortran/38669 * gfortran.dg/elemental_dependency_3.f90: New test. * gfortran.dg/elemental_subroutine_7.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/elemental_dependency_3.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/elemental_subroutine_7.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/dependency.c branches/gcc-4_3-branch/gcc/fortran/trans-stmt.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38487
