[Bug libstdc++/37582] [4.3 Regression] std::pow strange overload resolution
--- Comment #12 from jakub at gcc dot gnu dot org 2008-12-12 08:47 --- Subject: Bug 37582 Author: jakub Date: Fri Dec 12 08:46:26 2008 New Revision: 142704 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142704 Log: PR c++/37582 * include/bits/cpp_type_traits.h (struct __traitand): New. * include/c_global/cmath (std::atan2, std::pow): Use __traitand instead of as first argument to __enable_if. * include/c_std/cmath (std::atan2): Likewise. * testsuite/26_numerics/headers/cmath/37582.cc: New. Added: branches/gcc-4_3-branch/libstdc++-v3/testsuite/26_numerics/headers/cmath/37582.cc Modified: branches/gcc-4_3-branch/libstdc++-v3/ChangeLog branches/gcc-4_3-branch/libstdc++-v3/include/bits/cpp_type_traits.h branches/gcc-4_3-branch/libstdc++-v3/include/c_global/cmath branches/gcc-4_3-branch/libstdc++-v3/include/c_std/cmath -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37582
[Bug libstdc++/37582] [4.3 Regression] std::pow strange overload resolution
--- Comment #13 from jakub at gcc dot gnu dot org 2008-12-12 08:51 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37582
[Bug middle-end/38486] Missing warning about type punning
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-12-12 10:11 ---
Yes. Though you have to be careful not to create false positives for
float f;
struct X { int i; };
struct X *p = (struct X *)f;
float *q = (float *)p-i;
return *q;
if the code is obfuscated enough that the definition of p is not visible.
Or, one could even say that creating VIEW_CONVERT_EXPR float (p-i) is
an invalid transformation and causes an alias violation. Do we do this
transformation in this case? I think we should avoid doing it here
(that is, whenever the expression we view-convert contains a pointer
dereference).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38486
[Bug libstdc++/38477] [strict-aliasing] warning message contains compiler-generated symbols
--- Comment #3 from paolo dot carlini at oracle dot com 2008-12-12 11:10 --- Can you explain in better detail which aliasing issues you are seeing in _Rb_tree_impl (per Comment #1)? At line 530 I cannot see anything obviously wrong: a pointer to the base is casted to the derived type (just a static cast) and then _M_value_field of the latter is accessed. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||paolo at gcc dot gnu dot ||org, rguenth at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38477
[Bug libstdc++/37582] [4.3 Regression] std::pow strange overload resolution
--- Comment #14 from jakub at gcc dot gnu dot org 2008-12-12 11:23 --- Subject: Bug 37582 Author: jakub Date: Fri Dec 12 11:22:33 2008 New Revision: 142707 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142707 Log: PR c++/37582 * testsuite/26_numerics/headers/cmath/37582.cc: New. Added: trunk/libstdc++-v3/testsuite/26_numerics/headers/cmath/37582.cc Modified: trunk/libstdc++-v3/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37582
[Bug libstdc++/38477] [strict-aliasing] warning message contains compiler-generated symbols
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-12-12 11:24 --- The access is ((const struct _Rb_tree_node *) ctx.foo._M_t._M_impl._M_header.D.9518)-_M_value_field.pair_ptr but _M_header is of type _Rb_tree_node_base (and is embedded in _M_impl). _Rb_tree_node_base does not have a _M_value_field member, so I do not see that the memory that is accessed is really there. This D.9518 thing may somehow magically cover for it (but it's at offset zero of _M_header), but certainly TBAA isn't aware that this is a legal access. Of course I lack complete understanding of how the implementation details of the rb tree are supposed to work. So, if this is not a libstdc++ problem then it is a C++ FE problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38477
[Bug tree-optimization/38491] excessive note generation
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-12-12 10:06 --- *** This bug has been marked as a duplicate of 38445 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38491
[Bug target/37680] ICE: unable to generate reloads for: (insn:QI
--- Comment #5 from mkuvyrkov at gcc dot gnu dot org 2008-12-12 11:31 --- Sorry, I've closed this bug hastily though the bug is not fixed 4.3 branch; the patch I was reffering to was only committed to trunk. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37680
[Bug middle-end/38503] [4.4 regression] warnings from -isystem headers strikes back.
--- Comment #1 from pluto at agmk dot net 2008-12-12 11:37 --- Created an attachment (id=16897) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16897action=view) testcase. to reproduce bug you also need the boost-1.37.0 headers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38503
[Bug libstdc++/38477] [strict-aliasing] warning message contains compiler-generated symbols
--- Comment #5 from paolo dot carlini at oracle dot com 2008-12-12 11:39 --- Sorry, but I still do not understand: __x (a const _Rb_tree_node_base *) is casted to _Const_Link_type (a const _Rb_tree_node_Val *) before the access, then of course an _M_value_field esists. By the way, all these cast games are very, very old (I hope we are not uncovering one more aliasing issue in the HP/SGI code)... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38477
[Bug libstdc++/38477] [strict-aliasing] warning message contains compiler-generated symbols
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-12-12 11:44 ---
But there is no space for _Rb_tree_node_Val in ctx.foo._M_t._M_impl.
struct _Rb_tree_impl : public _Node_allocator
{
_Key_compare _M_key_compare;
_Rb_tree_node_base_M_header;
size_type _M_node_count;
the _M_header member is of type _Rb_tree_node_base, so I don't see how you
can cast that to _Rb_tree_node_Val and expect the _M_value_field to magically
appear in memory. At least this is what the alias analysis code complains
about and thus says this access accesses nothing (legally).
Now you can of course tell me that .D.9518 makes the difference, but this
difference is not communicated to the middle-end properly by the C++
frontend.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38477
[Bug libstdc++/38477] [strict-aliasing] warning message contains compiler-generated symbols
--- Comment #7 from paolo dot carlini at oracle dot com 2008-12-12 11:53
---
(In reply to comment #6)
But there is no space for _Rb_tree_node_Val in ctx.foo._M_t._M_impl.
struct _Rb_tree_impl : public _Node_allocator
{
_Key_compare _M_key_compare;
_Rb_tree_node_base_M_header;
size_type _M_node_count;
This has nothing to do with the allocated nodes.
the _M_header member is of type _Rb_tree_node_base, so I don't see how you
can cast that to _Rb_tree_node_Val and expect the _M_value_field to
magically
appear in memory.
Hey Richard, don't tell me it's the first time you see production code casting
a pointer from base to derived and accessing a member existing only in the
derived type. Indeed, the HP / SGI STL people did that, not the worse
programmers in the world ;) Anyway, if you think this is something wrong from
the aliasing specifications point of view, please point me to the relevant
sections of the Standard, let's work this out, is going to be painful and
risky, I'm afraid...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38477
[Bug libstdc++/38477] [strict-aliasing] warning message contains compiler-generated symbols
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-12-12 11:56 --- Heh, of course not - I have been doing this myself gazillions of times. I am just looking at this from the middle-end perspective where the middle-end appears to see an _object_ ctx with a specific member layout. If you then access this with a different layout then you are doomed. I have to dig into the trees coming from the FE in this case, but now I'm leaving for a 2+ week vacation w/o internet access, so ... this has to wait. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38477
[Bug libstdc++/38477] [strict-aliasing] warning message contains compiler-generated symbols
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-12-12 12:09 --- Btw, if you want to dig yourself - the problem is that the alias set of const struct _Rb_tree_node is not a subset of struct test. So the access of any part of an object of type struct test through a pointer of type const struct _Rb_tree_node * invokes undefined behavior (from the middle-end perspective). See alias.c:record_component_aliases for how the relationship is built. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38477
[Bug middle-end/38503] New: [4.4 regression] warnings from -isystem headers strikes back.
/local/devel/toolchain44/x86_64-gnu-linux/bin/x86_64-gnu-linux-g++ -dumpversion 4.4.0 /local/devel/toolchain44/x86_64-gnu-linux/bin/x86_64-gnu-linux-g++ -c -Wall -O2 -g0 -fPIC --save-temps \ -isystem ./buildenv/linux/gcc-4.4/64/boost-stlport-1.37.0/include \ bug.cpp bug.cpp: In function 'void foo()': bug.cpp:6: warning: dereferencing pointer 'anonymous' does break strict-aliasing rules ./buildenv/linux/gcc-4.4/64/boost-stlport-1.37.0/include/boost/optional/optional.hpp:315: note: initialized from here bug.cpp:6: warning: dereferencing pointer 'anonymous' does break strict-aliasing rules ./buildenv/linux/gcc-4.4/64/boost-stlport-1.37.0/include/boost/optional/optional.hpp:594: note: initialized from here on 4.3.2 it compiles cleanly. -- Summary: [4.4 regression] warnings from -isystem headers strikes back. Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net GCC target triplet: x86_64-gnu-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38503
[Bug middle-end/38503] [4.4 regression] warnings from -isystem headers strikes back.
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-12-12 11:53 --- Related to/dup of PR38477. I'll leave this one for the system header issue and PR38477 for the libstdc++/C++ alias problem. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org OtherBugsDependingO||38477 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38503
[Bug target/37680] ICE: unable to generate reloads for: (insn:QI
--- Comment #3 from schwab at suse dot de 2008-12-12 11:00 --- 1d86aeab250b3c69bf826385bd6875cf0b9ea459 is first bad commit commit 1d86aeab250b3c69bf826385bd6875cf0b9ea459 Author: mkuvyrkov mkuvyr...@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Tue Sep 11 13:56:30 2007 + * config/m68k/predicates.md (movsi_const0_operand, non_symbolic_call_operand): New predicates. * config/m68k/constraints.md: (Cs, Ci, C0, Cj, CQ, CW, CZ, CS, Ap, Ac): New constraints. * doc/md.texi (Constraints for Particular Machines: Motorola 680x0): Document constraints N, O, P, R, S, T, Q, U, W, Cs, Ci, C0, Cj, CQ, CW, CZ, CS, Ap and Ac. * config/m68k/m68k.md (UNSPEC_IB): New constant. (constraints.md): New include. (cpu, type, type1, opx, opy, opx_type, opy_type, size, opx_access, opx_mem, opy_mem, op_mem, guess, split): New attributes. (movdf_internal): Name pattern. Fix to use alternatives. Add split. Specify attributes. (pushdi): Add split. (tstsi_internal): Name pattern. Fix to use alternatives. Specify attributes. Split tstsi_internal_68020_cf from it. (tstsi_internal_68020_cf): New pattern. (tsthi_internal, tstqi_internal): Name pattern. Specify attributes. (tstmode_cf): Specify attributea. (cmpsi_cf): Name pattern. Specify attributes. (cmpmode_68881, cmpmode_cf): Specify type attribute. (pushexthisi_const): Fix to use alternatives. Specify attributes. (movsi_const0): Split movsi_const0_68000_10 and movsi_const0_68040_60 from it. Fix to use alternatives. Specify attributes. (movsi_const0_68040_10, movsi_const0_68040_60): New patterns. (movsi_cf, movstrictqi_cf): Fix to use alternatives. Specify attributes. (movsf_cf_soft): Specify attributes. (movdf_cf_soft): Add split. (pushasi, zero_extendhisi2_cf, zero_extendqisi2_cfv4, cfv4_extendhisi2, 68k_extendhisi2, extendqihi2, cfv4_extendqisi2, 68k_extendqisi2, truncdfsf2_cf): Specify attributes. (truncdfsf2_68881): Name pattern. Specify attributes. (floatsimode2_cf, floathimode2_68881, floathimode2_cf, floatqimode2_68881, floatqimode2_cf, ftruncmode2_cf, fixmodeqi2_cf, fixmodehi2_cf, fixmodesi2_cf, adddi_dishl32): Specify attributes. (addsi3_5200): Fix to use alternatives. Specify attributes. Add splits. (addmode3_cf, subdi_dishl32): Specify attributes. (subsi3): Add alternative for subq.l. Specify attributes. (submode3_cf, mulhi3, mulhisi3): Specify attributes. (mulhisisi3_s, mulsi3_68020, mulsi3_cf): Name pattern. Specify attributes. (umulhisi3): Specify attributes. (mulhisisi3_z): Name pattern. Specify attributes. (fmulmode3_cf, divmode3_cf, negsi2_internal, negsi2_5200, sqrtmode2_68881, clzsi2, one_cmplsi2_5200, subreghi1ashrdi_const32, subregsi1ashrdi_const32, ashrsi3, subreg1lshrdi_const32, lshrsi3, bsetmemqi): Specify attributes. (bsetmemqi_ext): Name pattern. Specify attributes. (bclrmemqi): Specify attributes. (bclrmemqi_ext, scc, sls): Name pattern. Specify attributes. (beq, bne, bgt, bgtu, blt, bltu, bge, bgeu, ble, bleu): Specify attributes. (beq2, bne2, bgt2, bgtu2, blt2, bltu2, bge2, bgeu2, ble2, bleu2): Name pattern. Specify attributes. (jump): Specify attributes. (tablejump_internal): Name pattern. Specify attributes. (call_value): Split into non_symbolic_call_value, symbolic_call_value_jsr, symbolic_call_value_bsr. Fix to use alternatives. Specify attributes. (non_symbolic_call_value, symbolic_call_value_jsr, symbolic_call_value_bsr): New patterns. (nop, return, unlink, indirect_jump): Specify attributes. (trap): Fix condition. Specify attributes. (ib): New pattern. * config/m68k/m68k.c (m68k_symbolic_call_var): New variable. (override_options): Initialize it. Initialize m68k_sched_cpu. (CONST_METHOD): Rename to M68K_CONST_METHOD, move to m68k.h. (const_method): Make global, rename to m68k_const_method. (const_int_cost, output_move_const_into_data_reg): Update. (output_move_double): Parametrize to emit rtl code, rename to handle_move_double. (output_reg_adjust, emit_reg_adjust, output_compadr, output_movsi, emit_movsi): New static functions. (output_move_double): New function with semantics of old output_move_double. (m68k_emit_move_double): New function. (m68k_sched_cpu): New variable. (attr_op_type): New enum. (sched_guess_p): New variable. (sched_address_type, sched_operand_type, sched_attr_op_type): New static functions.
[Bug target/37680] ICE: unable to generate reloads for: (insn:QI
--- Comment #4 from mkuvyrkov at gcc dot gnu dot org 2008-12-12 11:28 --- This was fixed on trunk, presumably by IRA. I've also checked a clean up patch that fixed this failure on 4.3. See http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01031.html. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37680
[Bug tree-optimization/38445] [4.4 Regression] ICE in tree-ssa-struct-alias when compiling grub-0.97
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-12-12 10:06 --- *** Bug 38491 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dcb314 at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38445
[Bug fortran/38504] New: double minus sign when printing integer?
There seems to be a small bug when writing an 8 byte integer to a character variable, as shown by this little test program: program IntAdtest integer, parameter :: i8_ = Selected_Int_Kind(18) ! = integer*8 character(len=22) :: str_value integer(i8_) :: value character(len=*), parameter :: format_IntAd = (i22) value = -9223372036854775807_i8_ write(str_value, format_IntAd) value print *,str_value = [//str_value//] value = -9223372036854775807_i8_ -1 write(str_value, format_IntAd) value print *,str_value = [//str_value//] end program IntAdtest When compiled with: gfortran -o IntAdtest IntAdtest.F90 I get the following output for the gfortran compiled executable: IntAdtest str_value = [ -9223372036854775807] str_value = [ --9223372036854775808] For all several other compilers the result is as expected: IntAdtest str_value = [ -9223372036854775807] str_value = [ -9223372036854775808] I used the following gfortran version for this test: gfortran --version GNU Fortran (GCC) 4.4.0 20081021 (experimental) [trunk revision 141258] Copyright (C) 2008 Free Software Foundation, Inc. best regards, Jos de Kloe -- Summary: double minus sign when printing integer? Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kloedej at knmi dot nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38504
[Bug fortran/36355] matmul argument-check: wrong error messages
--- Comment #6 from dfranke at gcc dot gnu dot org 2008-12-12 13:24 --- Subject: Bug 36355 Author: dfranke Date: Fri Dec 12 13:22:55 2008 New Revision: 142709 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142709 Log: gcc/fortran: 2008-12-12 Daniel Franke franke.dan...@gmail.com PR fortran/36355 * check.c (gfc_check_matmul): Fixed error message for invalid types to correctly identify the offending argument, added check for mismatching types. gcc/testsuite: 2008-12-12 Daniel Franke franke.dan...@gmail.com PR fortran/36355 * gfortran.dg/matmul_argument_types.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/matmul_argument_types.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36355
[Bug fortran/36355] matmul argument-check: wrong error messages
--- Comment #7 from dfranke at gcc dot gnu dot org 2008-12-12 13:26 --- Fixed in trunk. Closing. -- dfranke 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=36355
[Bug fortran/38504] double minus sign when printing integer?
--- Comment #1 from dfranke at gcc dot gnu dot org 2008-12-12 13:55 --- Sort of confirmed. You are aware that 'value-1' corresponds to '-HUGE(value)-1', which is out of range for integer numbers of that kind? Reduced testcase: IntAdtest integer, parameter :: i8_ = Selected_Int_Kind(18) ! = integer*8 integer(i8_) :: value value = -9223372036854775807_i8_ write(*, FMT=(i22)) value, -HUGE(value) value = -9223372036854775807_i8_ -1 write(*, FMT=(i22)) value, -HUGE(value)-1 end program IntAdtest Adding Jerry as CC. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org, jvdelisle at gcc dot ||gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-12-12 13:55:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38504
[Bug target/38402] Undocumented Yz constraint
--- Comment #1 from hjl at gcc dot gnu dot org 2008-12-12 14:33 --- Subject: Bug 38402 Author: hjl Date: Fri Dec 12 14:32:00 2008 New Revision: 142710 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142710 Log: 2008-12-12 H.J. Lu hongjiu...@intel.com PR target/38402 * gcc/doc/md.texi: Remove Y and document Yz, Y2, Yi and Ym constraints for x86. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/md.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38402
[Bug target/38402] Undocumented Yz constraint
--- Comment #2 from hjl at gcc dot gnu dot org 2008-12-12 14:35 --- Subject: Bug 38402 Author: hjl Date: Fri Dec 12 14:34:21 2008 New Revision: 142711 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142711 Log: 2008-12-12 H.J. Lu hongjiu...@intel.com Backport from mainline: 2008-12-12 H.J. Lu hongjiu...@intel.com PR target/38402 * gcc/doc/md.texi: Remove Y and document Yz, Y2, Yi and Ym constraints for x86. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/doc/md.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38402
[Bug target/38402] Undocumented Yz constraint
--- Comment #3 from hjl dot tools at gmail dot com 2008-12-12 14:36 --- Fixed -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38402
[Bug fortran/38504] double minus sign when printing integer?
--- Comment #2 from kloedej at knmi dot nl 2008-12-12 14:47 --- (In reply to comment #1) Sort of confirmed. You are aware that 'value-1' corresponds to '-HUGE(value)-1', which is out of range for integer numbers of that kind? Thanks for your reply. Yes I am aware that defining an integer constant with value '-HUGE(value)-1' is not allowed, but as far as I know the variable type is allowed to contain that value. So if: value = -9223372036854775807_i8_ -1 is illegal, then something like: value = -9223372036854775807_i8_ value = value-1 should be legal, and still be within the range of an 8 byte integer. See also this discussion: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29580 Anyway, the point is that gfortran does accept this code, but if you write to a character variable the result is strange. Best regards, Jos de Kloe -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38504
[Bug testsuite/35677] Intermitent failure FAIL: libgomp.fortran/crayptr2.f90
--- Comment #18 from dave at hiauly1 dot hia dot nrc dot ca 2008-12-12 15:04 --- Subject: Re: Intermitent failure FAIL: libgomp.fortran/crayptr2.f90 I assume I am using emutls since I see... nm crayptr2.exe | grep emut 1cd0 t ___emutls_get_address 1c90 t ___emutls_register_common 2014 d ___emutls_v.ip.1499 1f10 t _emutls_destroy 1ed0 t _emutls_init 2090 b _emutls_key 2040 d _emutls_mutex 2094 b _emutls_size I'll try a build of current gcc trunk with your patch and see if it helps. I probably was too quick to close this PR. The emutls support in darwin's libgcc is botched. The routines are present in libgcc_eh.a but not in the shared libraries. As I understand the situation from the gcc list, the Apple darwin maintainers oppose the addition of emutls support to the shared libgcc libraries. The emutls support is licensed under GPLv2, so that shouldn't block adoption. However, Apple may still want to provide its own TLS support. On the other hand, Apple is phasing out use of gcc. So, the issue of control might be something the steering committee should discuss. From my perspective, most of the support and testing of the darwin port in recent months has come from non-Apple developpers. I think the only way forward is to disable TLS support on darwin in gcc 4.3 and 4.4. Probably, a new PR should be created for this. Any testcases that use TLS and lack a dg-require-effective-target tls_runtime comment need updating. Those changes are obvious. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35677
[Bug regression/38505] New: internal compiler error: Segmentation fault
testcase produces internal compiler error (SegFault).
Error occurs with trunk rev. 142153 ... 142709.
Rev. 142038 was ok.
$ gcc-4.4 -O2 -c tst.c
tst.c: In function 'foo1':
tst.c:26: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
Exit 1
/* Source: */
typedef long unsigned int size_t;
extern void *memcpy (void *__restrict __dest,
__const void *__restrict __src, size_t __n)
__attribute__ ((__nothrow__)) __attribute__ ((__nonnull__ (1, 2)));
typedef struct
{
unsigned short a [100];
unsigned short v [20];
unsigned short b [100];
}
str_t;
extern int foo2 ( int *n );
extern unsigned short bar[];
void foo1 (void)
{
str_t h;
unsigned short * const h_ptr = (unsigned short *) h;
unsigned short h_k[200];
int x;
memcpy( h_ptr, h_k, 100 );
memcpy( h.v, bar, 40 );
foo2 (x);
}
--
Summary: internal compiler error: Segmentation fault
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: holger dot hopp at sap dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38505
[Bug fortran/38504] double minus sign when printing integer?
--- Comment #3 from kargl at gcc dot gnu dot org 2008-12-12 15:15 --- (In reply to comment #1) Sort of confirmed. You are aware that 'value-1' corresponds to '-HUGE(value)-1', which is out of range for integer numbers of that kind? ( Ihaven't had my morning coffe, but ...) No. It is in range. It is the only way (other than TRANSFER) to get the most negative integer value in a simple assignment. Now, if you write value = 9223372036854775807_i8_ + 1 write(*, FMT=(i22)) value, HUGE(value)+1 This results in out of range values, and wrap around semantics still gives --9223372036854775808 --9223372036854775808 Also, note that if one uses integer(4), you get the right output. -2147483647 -2147483647 -2147483648 -2147483648 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38504
[Bug fortran/38504] double minus sign when printing integer?
--- Comment #4 from dfranke at gcc dot gnu dot org 2008-12-12 15:59 --- Sort of confirmed. You are aware that 'value-1' corresponds to '-HUGE(value)-1', which is out of range for integer numbers of that kind? No. It is in range. Loose wording on my side, s/range/model/ then :) *hands over a cup of morning coffee* -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38504
[Bug c++/38489] [c++0x] ICE in digest_init_r, at cp/typeck2.c:821 on auto t = 0r; (fixed fp)
--- Comment #1 from cfairles at gcc dot gnu dot org 2008-12-12 15:59 --- cc'ing Jason -- cfairles at gcc dot gnu dot org changed: What|Removed |Added CC||jason at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38489
[Bug fortran/38504] double minus sign when printing integer?
--- Comment #5 from kargl at gcc dot gnu dot org 2008-12-12 16:03 ---
Looking at the -fdump-tree-original, I suspect that the minus sign in
the hex formatted number is redundant. To keep things short, I've removed
the dt_parm setup code. _gfortran_transfer_integer probably outputs -,
then converts 0x80 to -9223
value = -0x8000;
{
struct __st_parameter_dt dt_parm.2;
_gfortran_transfer_integer (dt_parm.2, value, 8);
{
static integer(kind=8) C.1495 = -0x8000;
_gfortran_transfer_integer (dt_parm.2, C.1495, 8);
}
_gfortran_st_write_done (dt_parm.2);
}
value4 = -2147483648;
{
struct __st_parameter_dt dt_parm.4;
_gfortran_st_write (dt_parm.4);
_gfortran_transfer_integer (dt_parm.4, value4, 4);
{
static integer(kind=4) C.1499 = -2147483648;
_gfortran_transfer_integer (dt_parm.4, C.1499, 4);
}
_gfortran_st_write_done (dt_parm.4);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38504
[Bug fortran/38506] New: Character storage association - actual - dummy argument
Cloned from PR 36771. See also
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/3d909edac01e60e2#
Since F2003 one can pass a string to a character(len=1),dimension(*)
dummy. The question is whether this should also work for generic
resolution or not.
The call One('String') (one = generic name) of the following program
is rejected by gfortran, ifort, NAG f95 and g95, stating that no
matching specific procedure could be found. On the other hand, all of
them accept call Two (= specific name). My question is now whether
call One should work as well (which would indicate a bug in all four
compilers) or not.
My gut feeling is that it is valid, but I cannot really pin point it in
the standard.*
*** Action item: If valid, gfortran should accept this.
Another question: Am I reading it correctly that if the default kind has
not the same value as UCS4 = selected_char_kind('ISO_10646') then a
call with an actual argument ucs4_string to a procedure with
array-valued ucs4-kind dummy argument is invalid Fortran 2003 and should
be rejected by the compiler with -std=f2003? This also holds for Fortran
2008 (current draft), does it?**
*** Action item: If invalid, we need to rejected (kind /= 1) character used
with storage association when -std gnu is given. (I'm almost positive that it
is invalid.)
(One needs to be careful this also works with rank 1.)
MODULE modtest
USE ISO_C_BINDING
INTERFACE One
MODULE PROCEDURE Two
END INTERFACE
CONTAINS
SUBROUTINE Two( chr ) bind(C)
CHARACTER(LEN=1, KIND=C_CHAR), DIMENSION(*) :: chr
END SUBROUTINE Two
END MODULE modtest
PROGRAM main
USE ISO_C_BINDING
USE modtest
CHARACTER(LEN=4, KIND=C_CHAR) :: chrScalar
chrScalar = 'Scal'
CALL One( chrScalar )
CALL Two( chrScalar )
END PROGRAM main
* Regarding the standard, I think 12.4.1.5 Sequence association is the
most important section, but I also looked at 12.4.1.2 Actual arguments
associated with dummy data objects, 16.4.3 Storage association and
(for c_char) 15.2 Interoperability between Fortran and C entities.
** 12.5.2.11 Sequence association also talks about default kind and
c_char only.
--
Summary: Character storage association - actual - dummy
argument
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: rejects-valid, 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=38506
[Bug fortran/38507] New: Bogus Warning: Deleted feature: GOTO jumps to END of construct
Hi, assuming that my reading of the standard is correct, the following warning is inappropriate: % cat gfcbug83.f90program gfcbug83 do 10 i = 1, 5 if (i == 3) goto 10 10 end do end program gfcbug83 % gfc4x gfcbug83.f90 gfcbug83.f90:3.24: if (i == 3) goto 10 1 gfcbug83.f90:4.9: 10 end do 2 Warning: Deleted feature: GOTO at (1) jumps to END of construct at (2) No other compiler seems to complain, not even NAG f95. The F2003 draft standard mentions in appendix B.1(2) branching to an ENDIF, but not ENDDO, for the reasons explained therein. I suggest this warning be removed. Cheers, Harald -- Summary: Bogus Warning: Deleted feature: GOTO jumps to END of construct Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anlauf at gmx dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38507
[Bug fortran/36771] Non-Standard addition for C_LOC and character strings
--- Comment #2 from burnus at gcc dot gnu dot org 2008-12-12 16:19 ---
I have the gut feeling that the program in comment 1 is valid, even though
gfortran, g95, ifort and NAG f95 reject it. See PR 38506.
Regarding the c_loc: I think that should be possible; I'm not 100% sure whether
there exists scenarios where it causes problems, but ad hoc I don't see any.
Patch:
--- resolve.c (Revision 142706)
+++ resolve.c
@@ -2165,7 +2165,7 @@ gfc_iso_c_func_interface (gfc_symbol *sy
if (args_sym-attr.dimension != 0
(args_sym-as args_sym-as-rank == 0))
{
- gfc_error_now (Allocatable variable '%s' used as a
+ gfc_notify_std (GFC_STD_F2003, Allocatable variable
'%s' used as a
parameter to '%s' at %L must not be
an array of zero size,
args_sym-name, sym-name,
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36771
[Bug regression/38505] [4.4 Regression] Revision142061 may cause __builtin_memcpy to segfault
--- Comment #1 from hjl dot tools at gmail dot com 2008-12-12 17:11 --- It is very likely caused by revision 142061: http://gcc.gnu.org/ml/gcc-cvs/2008-11/msg00562.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||jakub at redhat dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-12-12 17:11:04 date|| Summary|internal compiler error:|[4.4 Regression] |Segmentation fault |Revision142061 may cause ||__builtin_memcpy to segfault http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38505
[Bug regression/38505] [4.4 Regression] Revision 142061 caused ICE on __builtin_memcpy
--- Comment #2 from hjl dot tools at gmail dot com 2008-12-12 17:20 --- Revision 142061 is the cause. -- hjl dot tools at gmail dot com changed: What|Removed |Added Summary|[4.4 Regression]|[4.4 Regression] Revision |Revision142061 may cause|142061 caused ICE on |__builtin_memcpy to segfault|__builtin_memcpy http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38505
[Bug middle-end/38505] [4.4 Regression] Revision 142061 caused ICE on __builtin_memcpy
--- Comment #3 from hjl dot tools at gmail dot com 2008-12-12 17:22 --- It happens on ia32, x86-64 and ia64. -- hjl dot tools at gmail dot com changed: What|Removed |Added Component|regression |middle-end GCC build triplet|x86_64-unknown-linux-gnu| GCC host triplet|x86_64-unknown-linux-gnu| GCC target triplet|x86_64-unknown-linux-gnu| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38505
[Bug middle-end/38409] [graphite] ICE : in canonicalize_loop_ivs, at tree-parloops.c:1384
--- Comment #5 from spop at gcc dot gnu dot org 2008-12-12 17:29 --- Subject: Bug 38409 Author: spop Date: Fri Dec 12 17:28:06 2008 New Revision: 142716 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142716 Log: 2008-12-12 Sebastian Pop sebastian@amd.com PR middle-end/38409 * gcc.dg/graphite/pr38409.c: New. * graphite.c (nb_reductions_in_loop): Use simple_iv. Added: trunk/gcc/testsuite/gcc.dg/graphite/pr38409.c Modified: trunk/gcc/ChangeLog trunk/gcc/graphite.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38409
[Bug fortran/38507] Bogus Warning: Deleted feature: GOTO jumps to END of construct
--- Comment #1 from kargl at gcc dot gnu dot org 2008-12-12 17:42 --- Not only do I agree that warning is bogus, I think we get it wrong even with END IF. From Annex B, (2) Branching to an END IF statement from outside its block. In Fortran 77, and for consistency also in Fortran 90, it was possible to branch to an END IF statement from outside the IF construct; this has been deleted. A similar result can be achieved by branching to a CONTINUE statement that is immediately after the END IF statement. Notice the from outside its block and consider program a i = 1 goto 1 ! No warning? Outside of if-then-endif block if (i == 1) then goto 1 ! Warning issued? print *, i 1 end if end program a -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38507
[Bug testsuite/35677] Intermitent failure FAIL: libgomp.fortran/crayptr2.f90
--- Comment #19 from howarth at nitro dot med dot uc dot edu 2008-12-12 17:52 --- Well, they are phasing it out in the long run perhaps but Apple is just transitioning to gcc 4.2.1 at the moment so gcc will be in use for awhile yet on darwin. I am unclear on what the clang/llvm will use for its libgcc equivalent. Perhaps Chris Lattner can enlighten us on that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35677
[Bug c++/38377] __builtin_constant_p(t) ? t : 1 is not considered a constant integer expression
--- Comment #6 from sabre at nondot dot org 2008-12-12 18:02 ---
Here are the testcases I checked in with the clang implementation of this if
you're interested:
// __builtin_constant_p as the condition of ?: allows arbitrary foldable
// constants to be transmogrified into i-c-e's.
char b[__builtin_constant_p((int)(1.0+2.0)) ? (int)(1.0+2.0) : -1];
struct c {
int a : ( // expected-error {{expression is not an integer constant
expression}}
__builtin_constant_p((int)(1.0+2.0)) ? (int)(1.0+
expr // expected-note {{subexpression not valid in an integer constant
expression}}
) : -1);
};
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38377
[Bug c++/38377] __builtin_constant_p(t) ? t : 1 is not considered a constant integer expression
--- Comment #7 from sabre at nondot dot org 2008-12-12 18:04 --- oh, that also has 'int expr;' at global scope earlier. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38377
[Bug testsuite/35677] Intermitent failure FAIL: libgomp.fortran/crayptr2.f90
--- Comment #20 from dave at hiauly1 dot hia dot nrc dot ca 2008-12-12 18:41 --- Subject: Re: Intermitent failure FAIL: libgomp.fortran/crayptr2.f90 Well, they are phasing it out in the long run perhaps but Apple is just transitioning to gcc 4.2.1 at the moment so gcc will be in use for awhile yet on darwin. I am unclear on what the clang/llvm will use for its libgcc equivalent. Perhaps Chris Lattner can enlighten us on that. In principle, users can install libgcc* wherever they like. I think the install path for shared libraries is hardcoded in executables (otool -L). There's also DYLD_LIBRARY_PATH and DYLD_FALLBACK_LIBRARY_PATH. As far as I know, the libgcc libraries shipped with 4.3 and in 4.4 are backwards compatible with earlier versions. My impression is that this issue is not confined to libgcc. The same problem is present for all the libraries provided by gcc. Any added features are going to make the new version incompatible with the system version, irrespective of ABI changes. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35677
[Bug testsuite/35677] Intermitent failure FAIL: libgomp.fortran/crayptr2.f90
--- Comment #21 from mrs at apple dot com 2008-12-12 18:42 --- My long term guidance would be to engineer gcc to use its copy of the libgcc_s dylib and link against it. This would mean that the newly installed libgcc_s should be found first, over /usr/lib, and that development and support mirror linux, in all the usual ways. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35677
[Bug testsuite/35677] Intermitent failure FAIL: libgomp.fortran/crayptr2.f90
--- Comment #22 from dave at hiauly1 dot hia dot nrc dot ca 2008-12-12 19:27 --- Subject: Re: Intermitent failure FAIL: libgomp.fortran/crayptr2.f90 My long term guidance would be to engineer gcc to use its copy of the libgcc_s dylib and link against it. This would mean that the newly installed libgcc_s should be found first, over /usr/lib, and that development and support mirror linux, in all the usual ways. That's certainly reasonable. However, linux style TLS support needs help from the assembler, linker and dynamic loader. So, unless this is going to happen, the best that can be achieved is that provided by the emulation layer. Tracking linux might be straight forward if the kernel supported ELF executables. Then, x86 linux tools would work essentially as is. However, I'm sure there would be issues with syscalls, etc. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35677
[Bug target/11594] testcase gcc.dg/20020103-1.c fails with scan-assembler-not LC
--- Comment #11 from janis at gcc dot gnu dot org 2008-12-12 19:36 --- Subject: Bug 11594 Author: janis Date: Fri Dec 12 19:34:48 2008 New Revision: 142718 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142718 Log: PR target/11594 * gcc.dg/20020103-1.c: Remove XFAIL for powerpc. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/20020103-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11594
[Bug target/11594] testcase gcc.dg/20020103-1.c fails with scan-assembler-not LC
--- Comment #12 from janis at gcc dot gnu dot org 2008-12-12 19:37 --- Fixed. From the patch mail: The scan assembler check in gcc.dg/20020103-1.c is now XPASS for all powerpc targets reported in the gcc-testresults archive. It started passing for powerpc64-unknown-linux-gnu with -m32 sometime between r139537 (2008-08-25) and r139604 (2008-08-27). This patch removes the xfail for that check. The test fails for powerpc64-unknown-linux-gnu with -m64, so I left the restriction that on powerpc*-*-* it it only run for ilp32. -- janis at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11594
[Bug middle-end/38505] [4.4 Regression] Revision 142061 caused ICE on __builtin_memcpy
--- Comment #4 from jakub at gcc dot gnu dot org 2008-12-12 19:36 ---
Shorter testcase:
struct S
{
unsigned short a[50];
unsigned short b[20];
};
extern void bar (void);
extern unsigned short d[];
void
foo (void)
{
struct S s;
unsigned short g[50];
__builtin_memcpy (s, g, sizeof (g));
__builtin_memcpy (s.b, d, sizeof (s.b));
bar ();
}
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org |
Status|NEW |ASSIGNED
Last reconfirmed|2008-12-12 17:11:04 |2008-12-12 19:36:22
date||
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38505
[Bug testsuite/29071] gcc.dg/20020919-1.c compilation test fails on powerpc-apple-darwin8 at -m64
--- Comment #10 from janis at gcc dot gnu dot org 2008-12-12 19:41 --- There are no archived test results for powerpc64-*-darwin*, so if someone can verify that this fixes the test, please report that here or close this PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29071
[Bug bootstrap/38508] New: [4.4 Regression] Bootstrap of r142717 broken in libstdc++-v3
At revision 142717 bootstrapping on i686-apple-darwin9 fails with: Making all in src /bin/sh ../libtool --tag CXX --mode=compile /opt/gcc/i686-darwin/./gcc/xgcc -shared-libgcc -B/opt/gcc/i686-darwin/./gcc -nostdinc++ -L/opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/src -L/opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/src/.libs -B/opt/gcc/gcc4.4w/i686-apple-darwin9/bin/ -B/opt/gcc/gcc4.4w/i686-apple-darwin9/lib/ -isystem /opt/gcc/gcc4.4w/i686-apple-darwin9/include -isystem /opt/gcc/gcc4.4w/i686-apple-darwin9/sys-include -I/opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/i686-apple-darwin9 -I/opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include -I/opt/gcc/gcc-4.4-work/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -fvisibility-inlines-hidden -ffunction-sections -fdata-sections -g -O2-x c++ -std=gnu++0x -c ../../../../gcc-4.4-work/libstdc++-v3/src/atomic.cc libtool: compile: /opt/gcc/i686-darwin/./gcc/xgcc -shared-libgcc -B/opt/gcc/i686-darwin/./gcc -nostdinc++ -L/opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/src -L/opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/src/.libs -B/opt/gcc/gcc4.4w/i686-apple-darwin9/bin/ -B/opt/gcc/gcc4.4w/i686-apple-darwin9/lib/ -isystem /opt/gcc/gcc4.4w/i686-apple-darwin9/include -isystem /opt/gcc/gcc4.4w/i686-apple-darwin9/sys-include -I/opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/i686-apple-darwin9 -I/opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include -I/opt/gcc/gcc-4.4-work/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -fvisibility-inlines-hidden -ffunction-sections -fdata-sections -g -O2 -x c++ -std=gnu++0x -c ../../../../gcc-4.4-work/libstdc++-v3/src/atomic.cc -fno-common -DPIC -o .libs/atomic.o In file included from /usr/include/wchar.h:114, from /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/cwchar:52, from /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/bits/postypes.h:47, from /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/iosfwd:47, from /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/system_error:45, from /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/mutex:50, from ../../../../gcc-4.4-work/libstdc++-v3/src/atomic.cc:33: /usr/include/_wctype.h:52: error: '__darwin_wctype_t' does not name a type In file included from /usr/include/wchar.h:114, from /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/cwchar:52, from /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/bits/postypes.h:47, from /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/iosfwd:47, from /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/system_error:45, from /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/mutex:50, from ../../../../gcc-4.4-work/libstdc++-v3/src/atomic.cc:33: /usr/include/_wctype.h:90: error: 'wctype_t' has not been declared /usr/include/_wctype.h:177: error: 'wctype_t' does not name a type In file included from /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/i686-apple-darwin9/bits/gthr-default.h:44, from /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/i686-apple-darwin9/bits/gthr.h:165, from /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/ext/atomicity.h:39, from /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/bits/basic_string.h:46, from /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/string:58, from /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/stdexcept:44, from /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/system_error:46, from /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/mutex:50, from ../../../../gcc-4.4-work/libstdc++-v3/src/atomic.cc:33: /usr/include/pthread.h:384: error: expected ',' or '...' before '*' token In file included from /usr/include/unistd.h:515, from /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/i686-apple-darwin9/bits/gthr-default.h:45, from /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/i686-apple-darwin9/bits/gthr.h:165, from /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/ext/atomicity.h:39, from /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/bits/basic_string.h:46, from /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/string:58, from /opt/gcc/i686-darwin/i686-apple-darwin9/libstdc++-v3/include/stdexcept:44,
[Bug fortran/38507] Bogus Warning: Deleted feature: GOTO jumps to END of construct
--- Comment #2 from kargl at gcc dot gnu dot org 2008-12-12 20:07 --- I have a semi-working patch for this. Harald's original problem is easy to fix, but the branching into a IF block requires a little more clean. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P4 Last reconfirmed|-00-00 00:00:00 |2008-12-12 20:07:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38507
[Bug middle-end/38505] [4.4 Regression] Revision 142061 caused ICE on __builtin_memcpy
--- Comment #5 from jakub at gcc dot gnu dot org 2008-12-12 20:19 ---
I'd say the bug is in may_propagate_address_into_dereference, called with addr:
addr_expr 0x77ffb780
type pointer_type 0x7320f600
type integer_type 0x731f8480 short unsigned int sizes-gimplified
public unsigned HI
size integer_cst 0x731e7960 constant 16
unit size integer_cst 0x731e7990 constant 2
align 16 symtab 0 alias set -1 canonical type 0x731f8480
precision 16 min integer_cst 0x731e79c0 0 max integer_cst 0x731e7930
65535
pointer_to_this pointer_type 0x7320f600
unsigned DI
size integer_cst 0x731e7b70 constant 64
unit size integer_cst 0x731e7ba0 constant 8
align 64 symtab 0 alias set -1 canonical type 0x7320f600
constant
arg 0 var_decl 0x732bd960 d
type array_type 0x730f9c00 type integer_type 0x731f8480 short
unsigned int
BLK
align 16 symtab 0 alias set -1 canonical type 0x730f9c00
pointer_to_this pointer_type 0x731123c0
addressable used public external common BLK file pr38505.c line 7 col
23
align 16
chain function_decl 0x730f8f00 foo type function_type
0x7321
public static QI file pr38505.c line 10 col 1 align 8 initial
block 0x7310f2a0 result result_decl 0x7311 D.1597
(mem:QI (symbol_ref:DI (foo) [flags 0x3] function_decl
0x730f8f00 foo) [0 S1 A8])
saved-insns 0x732bda00
and deref:
indirect_ref 0x77ffb540
type array_type 0x730f9a80
type integer_type 0x731f8480 short unsigned int sizes-gimplified
public unsigned HI
size integer_cst 0x731e7960 constant 16
unit size integer_cst 0x731e7990 constant 2
align 16 symtab 0 alias set -1 canonical type 0x731f8480
precision 16 min integer_cst 0x731e79c0 0 max integer_cst 0x731e7930
65535
pointer_to_this pointer_type 0x7320f600
sizes-gimplified BLK
size integer_cst 0x7310d9c0 constant 320
unit size integer_cst 0x7310db70 constant 40
align 16 symtab 0 alias set 2 canonical type 0x730f9a80
domain integer_type 0x730f99c0 type integer_type 0x731f8000
long unsigned int
sizes-gimplified DI
size integer_cst 0x731e7b70 constant 64
unit size integer_cst 0x731e7ba0 constant 8
align 64 symtab 0 alias set -1 canonical type 0x730f99c0
precision 64 min integer_cst 0x731e7720 0 max integer_cst 0x7310dab0
19
pointer_to_this pointer_type 0x73112240
arg 0 ssa_name 0x731e5d20
type pointer_type 0x73112240 type array_type 0x730f9a80
static unsigned DI size integer_cst 0x731e7b70 64 unit size
integer_cst 0x731e7ba0 8
align 64 symtab 0 alias set -1 canonical type 0x73112240
visited var var_decl 0x732bdbe0 d.0def_stmt d.0_1 = (short
unsigned int[20] * {ref-all}) d;
version 1
It allows propagating of an incomplete type var, which it certainly shouldn't
allow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38505
[Bug target/38419] [4.3 Regression] ICE (SIGSEGV) with -O
--- Comment #3 from doko at ubuntu dot com 2008-12-12 20:21 --- this now works without the definition of DH_USES -- doko at ubuntu dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38419
[Bug tree-optimization/32044] [4.3/4.4 Regression] final value replacement too aggressive for e.g. targets with no native div/mod insns
--- Comment #65 from rakdver at gcc dot gnu dot org 2008-12-12 20:34 --- Subject: Bug 32044 Author: rakdver Date: Fri Dec 12 20:32:47 2008 New Revision: 142719 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142719 Log: PR tree-optimization/32044 * tree-scalar-evolution.h (expression_expensive_p): Declare. * tree-scalar-evolution.c (expression_expensive_p): New function. (scev_const_prop): Avoid introducing expensive expressions. * tree-ssa-loop-ivopts.c (may_eliminate_iv): Ditto. * gcc.dg/pr34027-1.c: Change outcome. * gcc.dg/tree-ssa/pr32044.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr32044.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr34027-1.c trunk/gcc/tree-scalar-evolution.c trunk/gcc/tree-scalar-evolution.h trunk/gcc/tree-ssa-loop-ivopts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug tree-optimization/32044] [4.3/4.4 Regression] final value replacement too aggressive for e.g. targets with no native div/mod insns
--- Comment #66 from rakdver at gcc dot gnu dot org 2008-12-12 20:42 --- (In reply to comment #64) I agree that the most practical short-term solution is to avoid transforming the loop into a division. However, I'm also interested in what we think the right long-term solution is. I'm not convinced that our goal should be to preserve the form used by the user; rather, I'm inclined to say that our goal should be to (a) recognize the loop as division, and, (b) generate loops to implement division when profitable. It's reasonable is to say that the form user by the user influences the decision about profitability made in (b). Agreed; there are also other parts of tree-rtl expansion that could benefit from using the information about the distribution of the inputs, whether obtained from value profiling, VRP, scev analysis, guesses based on the structure of the program (as in this case), or possibly hints by the user (builtin_expect). I do not have time to work on that now, though (I think it would make a rather nice gsoc project, or a student project in general). -- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|rakdver 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=32044
[Bug middle-end/38492] [graphite] segfaulting code when compiled with -fgraphite -fgraphite-identity
--- Comment #2 from spop at gcc dot gnu dot org 2008-12-12 21:52 --- Subject: Bug 38492 Author: spop Date: Fri Dec 12 21:50:57 2008 New Revision: 142722 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142722 Log: 2008-12-12 Sebastian Pop sebastian@amd.com PR tree-optimization/38492 * graphite.c (rename_map_elt, debug_rename_elt, debug_rename_map_1, debug_rename_map, new_rename_map_elt, rename_map_elt_info, eq_rename_map_elts, get_new_name_from_old_name, bb_in_sese_p): Moved around. (sese_find_uses_to_rename_use): Renamed sese_build_livein_liveouts_use. (sese_find_uses_to_rename_bb): Renamed sese_build_livein_liveouts_bb. (sese_build_livein_liveouts): New. (new_sese, free_sese): New. (new_scop): Call new_sese. (free_scop): Call free_sese. (rename_variables_from_edge, rename_phis_end_scop): Removed. (register_old_new_names): Renamed register_old_and_new_names. (register_scop_liveout_renames, add_loop_exit_phis, insert_loop_close_phis, struct igp, default_liveout_before_guard, add_guard_exit_phis, insert_guard_phis, copy_renames): New. (translate_clast): Call insert_loop_close_phis and insert_guard_phis. (sese_add_exit_phis_edge): Renamed scop_add_exit_phis_edge. (rewrite_into_sese_closed_ssa): Renamed scop_insert_phis_for_liveouts. (scop_adjust_phis_for_liveouts): New. (gloog): Call scop_adjust_phis_for_liveouts. * graphite.h (struct sese): Documented. Added fields liveout, num_ver and livein. (SESE_LIVEOUT, SESE_LIVEIN, SESE_LIVEIN_VER, SESE_NUM_VER): New. (new_sese, free_sese, sese_build_livein_liveouts): Declared. (struct scop): Added field liveout_renames. (SCOP_LIVEOUT_RENAMES): New. Modified: branches/graphite/gcc/ChangeLog.graphite branches/graphite/gcc/graphite.c branches/graphite/gcc/graphite.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38492
[Bug middle-end/38492] [graphite] segfaulting code when compiled with -fgraphite -fgraphite-identity
--- Comment #3 from spop at gcc dot gnu dot org 2008-12-12 22:05 --- 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=38492
[Bug objc++/31032] [4.3/4.4 Regression] expected tree that contains 'decl with RTL' structure, have 'field_decl' in assemble_external_real, at varasm.c:2225
--- Comment #10 from janis at gcc dot gnu dot org 2008-12-12 22:15 --- Subject: Bug 31032 Author: janis Date: Fri Dec 12 22:14:39 2008 New Revision: 142723 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142723 Log: PR objc++/31032 * obj-c++.dg/bitfield-1.mm: Remove XFAIL for ICE. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/obj-c++.dg/bitfield-1.mm -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31032
[Bug libfortran/24685] real(16) formatted input is broken for huge values (gfortran.dg/default_format_2.f90)
--- Comment #33 from janis at gcc dot gnu dot org 2008-12-12 22:18 --- Subject: Bug 24685 Author: janis Date: Fri Dec 12 22:17:31 2008 New Revision: 142724 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142724 Log: PR libgfortran/24685 * gfortran.dg/default_format_denormal_2.f90: Change XFAIL to check for size of long double. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/default_format_denormal_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24685
[Bug libfortran/24685] real(16) formatted input is broken for huge values (gfortran.dg/default_format_2.f90)
--- Comment #34 from janis at gcc dot gnu dot org 2008-12-12 22:22 --- Subject: Bug 24685 Author: janis Date: Fri Dec 12 22:21:14 2008 New Revision: 142725 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142725 Log: PR libgfortran/24685 * gfortran.dg/default_format_denormal_2.f90: Change XFAIL to check for size of long double. Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/default_format_denormal_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24685
[Bug objc++/31032] [4.3/4.4 Regression] expected tree that contains 'decl with RTL' structure, have 'field_decl' in assemble_external_real, at varasm.c:2225
--- Comment #11 from janis at gcc dot gnu dot org 2008-12-12 22:23 --- This ICE still happens on the 4.3 branch but it was fixed on mainline sometime between r142476 (20081205) and r142646 (20081210). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31032
[Bug middle-end/38500] [graphite] ICE : in verify_loop_structure, at cfgloop.c:1569
--- Comment #2 from hjagasia at gcc dot gnu dot org 2008-12-12 22:27 --- Created an attachment (id=16898) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16898action=view) Proposed Patch 2008-12-12 Jan Sjodin jan.sjo...@amd.com Harsha Jagasia harsha.jaga...@amd.com PR tree-optimization/38500 * gcc.dg/graphite/pr38500.c: New. * graphite.c (create_sese_edges): Call fix_loop_structure after splitting blocks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38500
[Bug fortran/38507] Bogus Warning: Deleted feature: GOTO jumps to END of construct
--- Comment #3 from burnus at gcc dot gnu dot org 2008-12-12 22:28 --- What is about the obsolescent DO related part? Do we need to do something there (from F95, B.2): Shared DO termination and termination on a statement other than END DO or CONTINUE use an END DO or a CONTINUE statement for each DO statement. 8.1.4.2 Range of the DO construct contains this small print (small = deprecated, might get removed in later versions): The range of a nonblock DO construct consists of the do-body and the following DO termination. The end of such a range is not bounded by a particular statement as for the other executable constructs (e.g., END IF); nevertheless, the range satisfies the rules for blocks (8.1.1). Transfer of control into the do-body or to the DO termination from outside the range is prohibited; in particular, it is permitted to branch to a do-term-shared-stmt only from within the range of the corresponding inner-shared-do-construct. Example: do 10 i = 1, 5 do 10 ii = 1,5 goto 10 10 continue end NAG f95 prints: Obsolescent: 10 is a shared DO termination label ifort -stand f95 prints: Warning: Sharing of a DO termination statement by more than one DO statement is an obsolescent feature in Fortran 95. Use an END DO or CONTINUE statement for each DO statement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38507
[Bug middle-end/38500] [graphite] ICE : in verify_loop_structure, at cfgloop.c:1569
--- Comment #3 from sebpop at gmail dot com 2008-12-12 22:31 --- Subject: Re: [graphite] ICE : in verify_loop_structure, at cfgloop.c:1569 2008-12-12 Jan Sjodin jan.sjo...@amd.com Harsha Jagasia harsha.jaga...@amd.com PR tree-optimization/38500 * gcc.dg/graphite/pr38500.c: New. * graphite.c (create_sese_edges): Call fix_loop_structure after splitting blocks. Okay for both trunk and branch. Thanks, Sebastian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38500
[Bug objc++/31032] [4.3/4.4 Regression] expected tree that contains 'decl with RTL' structure, have 'field_decl' in assemble_external_real, at varasm.c:2225
--- Comment #12 from ghazi at gcc dot gnu dot org 2008-12-12 22:31 --- I can narrow it down on mainline to somewhere between revisions 142545 and 142574 according to my testsuite results below: http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg00786.html http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg00896.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.2.0 |4.2.0 4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31032
[Bug c++/38509] New: Bogus attempt to free a non-heap object warning
class TestCase {
private:
const int *pointer;
public:
TestCase() {
static int non_heap = 0;
this-pointer = non_heap;
}
~TestCase() {
if (*this-pointer != 0) __builtin_free(const_castint *(this-pointer));
}
};
int main(int argc, const char *argv[]) {
TestCase test;
return 0;
}
/*
The code above, compiled g++ 4.4.0 with -O1 (or any -On except -O0) gives the
following warning:
test.cpp: In function âint main(int, const char**)â:
test.cpp:12: warning: attempt to free a non-heap object ânon_heapâ
In this case the warning is bogus because the free can never be reached.
Complete command line:
g++ -O1 -o test test.cpp
Output from g++ -v -O1 -o test test.cpp:
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --with-arch=pentium-m --enable-threads
--enable-languages=c,c++
Thread model: posix
gcc version 4.4.0 20081210 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-O1' '-o' 'test' '-shared-libgcc' '-mtune=generic'
'-march=pentium-m'
/usr/local/libexec/gcc/i686-pc-linux-gnu/4.4.0/cc1plus -quiet -v -D_GNU_SOURCE
test.cpp -quiet -dumpbase test.cpp -mtune=generic -march=pentium-m -auxbase
test -O1 -version -o /tmp/ccIffeq5.s
ignoring nonexistent directory
/usr/local/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../i686-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/local/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0
/usr/local/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0/i686-pc-linux-gnu
/usr/local/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0/backward
/usr/local/include
/usr/local/lib/gcc/i686-pc-linux-gnu/4.4.0/include
/usr/local/lib/gcc/i686-pc-linux-gnu/4.4.0/include-fixed
/usr/include
End of search list.
GNU C++ (GCC) version 4.4.0 20081210 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.4.0 20081210 (experimental), GMP version
4.2.2, MPFR version 2.3.2.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: b043f60097b3fa3e759e89265ea8ebdb
test.cpp: In function âint main(int, const char**)â:
test.cpp:12: warning: attempt to free a non-heap object ânon_heapâ
COLLECT_GCC_OPTIONS='-v' '-O1' '-o' 'test' '-shared-libgcc' '-mtune=generic'
'-march=pentium-m'
as -V -Qy -o /tmp/ccshvEr5.o /tmp/ccIffeq5.s
GNU assembler version 2.18.0 (i486-linux-gnu) using BFD version (GNU Binutils
for Debian) 2.18.0.20080103
COMPILER_PATH=/usr/local/libexec/gcc/i686-pc-linux-gnu/4.4.0/:/usr/local/libexec/gcc/i686-pc-linux-gnu/4.4.0/:/usr/local/libexec/gcc/i686-pc-linux-gnu/:/usr/local/lib/gcc/i686-pc-linux-gnu/4.4.0/:/usr/local/lib/gcc/i686-pc-linux-gnu/
LIBRARY_PATH=/usr/local/lib/gcc/i686-pc-linux-gnu/4.4.0/:/usr/local/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-O1' '-o' 'test' '-shared-libgcc' '-mtune=generic'
'-march=pentium-m'
/usr/local/libexec/gcc/i686-pc-linux-gnu/4.4.0/collect2 --eh-frame-hdr -m
elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o test /usr/lib/crt1.o
/usr/lib/crti.o /usr/local/lib/gcc/i686-pc-linux-gnu/4.4.0/crtbegin.o
-L/usr/local/lib/gcc/i686-pc-linux-gnu/4.4.0
-L/usr/local/lib/gcc/i686-pc-linux-gnu/4.4.0/../../.. /tmp/ccshvEr5.o -lstdc++
-lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/local/lib/gcc/i686-pc-linux-gnu/4.4.0/crtend.o /usr/lib/crtn.o
Note: this is a self-compiled binary of SVN revision 142654.
*/
--
Summary: Bogus attempt to free a non-heap object warning
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rubidium at openttd dot org
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=38509
[Bug testsuite/38163] gcc.dg/tree-ssa/loop-3.c failure at -m64 on i686-apple-darwin9
--- Comment #3 from uros at gcc dot gnu dot org 2008-12-12 22:41 --- Subject: Bug 38163 Author: uros Date: Fri Dec 12 22:39:43 2008 New Revision: 142726 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142726 Log: PR testsuite/38163 * gcc.dg/tree-ssa/loop-3.c: Compile only on nonpic x86 targets. Remove dg-skip-if directive. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-3.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38163
[Bug c/38510] New: Matrix.c from pymol 1.1r2 fails to compile with -O2 -fgraphite
The source file pymol-1.1/layer0/Matrix.c fails to compile under gcc trunk with either '-O2 -fgraphite-identity' or '-O1 -fgraphite-identity'. In the first case the failure is... gcc-4 -fgraphite-identity -O2 -D_HAVE_LIBPNG -D_PYMOL_MODULE -D_PYMOL_NUMPY -D_PYMOL_FINK -c -o Matrix.o Matrix.iMatrix.c: In function pymol_rg_:Matrix.c:3059: error: edge from 641 to 9 should be marked irreducible Matrix.c:3059: error: basic block 644 should be marked irreducible Matrix.c:3059: error: edge from 644 to 642 should be marked irreducible Matrix.c:3059: error: edge from 640 to 11 should be marked irreducible Matrix.c:3059: internal compiler error: in verify_loop_structure, at cfgloop.c:1569 In the second case, the failure is... gcc-4 -fgraphite-identity -O1 -D_HAVE_LIBPNG -D_PYMOL_MODULE -D_PYMOL_NUMPY -D_PYMOL_FINK -c -o Matrix.o Matrix.i Matrix.c: In function MatrixFitRMSTTTf: Matrix.c:963: internal compiler error: in canonicalize_loop_ivs, at tree-parloops.c:1385 Only '-O0 -fgraphite-identity' compiles this source file without compile time errors. -- Summary: Matrix.c from pymol 1.1r2 fails to compile with -O2 - fgraphite Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: i686-apple-darwin9 GCC host triplet: i686-apple-darwin9 GCC target triplet: i686-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38510
[Bug c/38510] Matrix.c from pymol 1.1r2 fails to compile with -O2 -fgraphite
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2008-12-12 22:44 --- Created an attachment (id=16899) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16899action=view) preprocessed source for pymol-1.1/layer0/Matrix.i Compile with either... gcc-4 -fgraphite-identity -O2 -D_HAVE_LIBPNG -D_PYMOL_MODULE -D_PYMOL_NUMPY -D_PYMOL_FINK -c -o Matrix.o Matrix.i or gcc-4 -fgraphite-identity -O1 -D_HAVE_LIBPNG -D_PYMOL_MODULE -D_PYMOL_NUMPY -D_PYMOL_FINK -c -o Matrix.o Matrix.i to reproduce the failures. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38510
[Bug middle-end/38509] Bogus attempt to free a non-heap object warning
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-12 22:42 --- static int non_heap = 0; bb 2: if (non_heap != 0) goto bb 3; else goto bb 4; bb 3: __builtin_free (non_heap); Hmm, since the address of non_heap is taken, we don't optimize away the conditional. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |middle-end Keywords||diagnostic, missed- ||optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38509
[Bug testsuite/38163] gcc.dg/tree-ssa/loop-3.c failure at -m64 on i686-apple-darwin9
--- Comment #4 from ubizjak at gmail dot com 2008-12-12 22:41 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38163
[Bug target/24779] [4.0 Regression] Python miscompilation - TOC reload
--- Comment #14 from pinskia at gcc dot gnu dot org 2008-12-12 22:55 --- Subject: Bug 24779 Author: pinskia Date: Fri Dec 12 22:54:09 2008 New Revision: 142727 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142727 Log: 2008-12-12 Andrew Pinski andrew_pins...@playstation.sony.com Peter Bergner berg...@vnet.ibm.com PR target/24779 * config/rs6000/rs6000.md (call_indirect_aix32): Move the load of the TOC into the call pattern. (call_indirect_aix64): Likewise. (call_value_indirect_aix32): Likewise. (call_value_indirect_aix64): Likewise. (call_indirect_nonlocal_aix32_internal): New insn and split patterns to split off the load of the TOC. (call_indirect_nonlocal_aix32): Enable only after reload. (call_indirect_nonlocal_aix64_internal): New insn and split patterns to split off the load of the TOC. (call_indirect_nonlocal_aix64): Enable only after reload. (call_value_indirect_nonlocal_aix32_internal): New insn and split patterns to split off the load of the TOC. (call_value_indirect_nonlocal_aix32): Enable only after reload. (call_value_indirect_nonlocal_aix64_internal): New insn and split patterns to split off the load of the TOC. (call_value_indirect_nonlocal_aix64): Enable only after reload. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24779
[Bug fortran/38507] Bogus Warning: Deleted feature: GOTO jumps to END of construct
--- Comment #4 from kargl at gcc dot gnu dot org 2008-12-12 22:58 --- (In reply to comment #3) What is about the obsolescent DO related part? Do we need to do something there (from F95, B.2): Shared DO termination and termination on a statement other than END DO or CONTINUE use an END DO or a CONTINUE statement for each DO statement. AFAICT, gfortran in resolve.c(resolve_branch) makes no distinction between a block do construct and a nonblock do construct. The issue Harald raised is jumping from some location inside the do-loop to a labeled end-do. Before CYCLE, this was a common way to skip to the end of the loop. I'm surprise that this hasn't come up before. In playing around with various Do---ENDDO and IF---ENDIF constructs, I've found that gfortran considerd ENDDO to be a part of its do block and ENDIF is not part of its if block. I haven't read the standard to determine if these are the correct semantics, but sure looks weird to me. troutmask:sgk[207] cat e.f90 program a i = 1 goto 1 if (i == 1) then i = i + 1 1 end if goto 2 do i = 1, 3 j = i 2 end do end program a troutmask:sgk[208] gfortran43 -c e.f90 e.f90:12.1: 2 end do 1 e.f90:9.8: goto 2 2 Warning: Label at (1) is not in the same block as the GOTO statement at (2) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38507
[Bug middle-end/38500] [graphite] ICE : in verify_loop_structure, at cfgloop.c:1569
--- Comment #4 from hjagasia at gcc dot gnu dot org 2008-12-12 23:01 --- Created an attachment (id=16900) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16900action=view) Forgot to add testcase to patch, updating patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38500
[Bug c++/38502] static_assert vs. enums
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-12 23:04 ---
Why do you think __m could even appear in a static_assert? It is a function
argument. Changing __m to a type of int shows the same.
Changing it to a template argument causes an ICE though:
t.cc: In function 'int f()':
t.cc:11: internal compiler error: in tsubst_decl, at cp/pt.c:8622
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
--- CUT ---
Testcase:
#include cassert
/// Enumeration for memory_order
typedef enum memory_order
{
memory_order_relaxed,
memory_order_consume,
memory_order_acquire,
memory_order_release,
memory_order_acq_rel,
memory_order_seq_cst
} memory_order;
class a
{
void
store1(void* __v, memory_order __m = memory_order_seq_cst) volatile
{
assert(__m == memory_order_acquire);
assert(__m == memory_order_acq_rel);
assert(__m == memory_order_consume);
}
templatememory_order __m = memory_order_seq_cst
void
store2(void* __v)
{
static_assert(__m == memory_order_acquire,
atomic_address::store requirements not met.);
static_assert(__m == memory_order_acq_rel,
atomic_address::store requirements not met.);
static_assert(__m == memory_order_consume,
atomic_address::store requirements not met.);
}
};
int f(void)
{
a b;
b.store2(0);
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords|rejects-valid |ice-on-valid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38502
[Bug middle-end/38500] [graphite] ICE : in verify_loop_structure, at cfgloop.c:1569
--- Comment #5 from hjagasia at gcc dot gnu dot org 2008-12-12 23:06 --- Subject: Bug 38500 Author: hjagasia Date: Fri Dec 12 23:05:09 2008 New Revision: 142728 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142728 Log: 2008-12-12 Jan Sjodin jan.sjo...@amd.com Harsha Jagasia harsha.jaga...@amd.com PR tree-optimization/38500 * gcc.dg/graphite/pr38500.c: New. * graphite.c (create_sese_edges): Call fix_loop_structure after splitting blocks. Added: branches/graphite/gcc/testsuite/gcc.dg/graphite/pr38500.c Modified: branches/graphite/gcc/graphite.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38500
[Bug ada/38511] New: Assert_Failure when compiling PolyOrb
gcc --version gcc (Ubuntu 4.3.2-1ubuntu11) 4.3.2 svn checkout http://svn.eu.adacore.com/anonsvn/Dev/trunk/polyorb cd polyorb ./support/reconfig ./configure make ... +===GNAT BUG DETECTED==+ | 4.3.2 (i486-pc-linux-gnu) Assert_Failure sinfo.adb:2023 | | Error detected at polyorb-references-ior.adb:135:15 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc-4.3 or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. /home/markus/src/ada/polyorb/src/polyorb-references-ior.adb /home/markus/src/ada/polyorb/src/polyorb-references-ior.ads /home/markus/src/ada/polyorb/src/polyorb-references.ads /home/markus/src/ada/polyorb/src/polyorb.ads /home/markus/src/ada/polyorb/src/polyorb-annotations.ads /home/markus/src/ada/polyorb/src/polyorb-utils.ads /home/markus/src/ada/polyorb/src/polyorb-utils-chained_lists.ads /home/markus/src/ada/polyorb/src/polyorb-binding_data.ads /home/markus/src/ada/polyorb/src/polyorb-components.ads /home/markus/src/ada/polyorb/src/polyorb-errors.ads /home/markus/src/ada/polyorb/src/polyorb-smart_pointers.ads /home/markus/src/ada/polyorb/src/polyorb-tasking.ads /home/markus/src/ada/polyorb/src/polyorb-tasking-mutexes.ads /home/markus/src/ada/polyorb/src/polyorb-types.ads /home/markus/src/ada/polyorb/src/polyorb-objects.ads /home/markus/src/ada/polyorb/src/polyorb-qos.ads /home/markus/src/ada/polyorb/src/polyorb-transport.ads /home/markus/src/ada/polyorb/src/polyorb-asynch_ev.ads /home/markus/src/ada/polyorb/src/polyorb-jobs.ads /home/markus/src/ada/polyorb/src/polyorb-buffers.ads /home/markus/src/ada/polyorb/src/polyorb-opaque.ads /home/markus/src/ada/polyorb/src/polyorb-opaque-chunk_pools.ads /home/markus/src/ada/polyorb/src/polyorb-utils-strings.ads /home/markus/src/ada/polyorb/src/polyorb-initialization.ads /home/markus/src/ada/polyorb/src/polyorb-utils-strings-lists.ads /home/markus/src/ada/polyorb/src/polyorb-log.ads /home/markus/src/ada/polyorb/src/polyorb-representations.ads /home/markus/src/ada/polyorb/src/polyorb-any.ads /home/markus/src/ada/polyorb/src/polyorb-representations-cdr.ads /home/markus/src/ada/polyorb/src/polyorb-utils-dynamic_tables.ads /home/markus/src/ada/polyorb/src/polyorb-representations-cdr-common.ads list may be incomplete compilation abandoned gnatmake: /home/markus/src/ada/polyorb/src/polyorb-references-ior.adb compilation error make: *** [src.gpr] Error 4 -- Summary: Assert_Failure when compiling PolyOrb Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: markus dot schoepflin at comsoft dot de GCC host triplet: i486-pc-linux-gnu GCC target triplet: i486-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38511
[Bug ada/38511] Assert_Failure when compiling PolyOrb
--- Comment #1 from markus dot schoepflin at comsoft dot de 2008-12-12 23:19 --- The last compile command executed was: ADA_PROJECT_PATH=/home/markus/src/ada/polyorb/projects:/home/markus/src/ada/polyorb/projects:$ADA_PROJECT_PATH \ gnatmake -P src.gpr --create-missing-dirs -g -O2 -XBuild=PRODUCTION -XWarnings_Mode=e -j4 -cargs gcc-4.3 -c -gnat05 -gnati1 -gnatf -gnatec=/home/markus/src/ada/polyorb/src/config.adc -gnatyg -gnatwale -gnatp -gnatn -g -O2 -I- -gnatA /home/markus/src/ada/polyorb/src/polyorb-references-ior.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38511
[Bug middle-end/38500] [graphite] ICE : in verify_loop_structure, at cfgloop.c:1569
--- Comment #6 from spop at gcc dot gnu dot org 2008-12-12 23:31 --- 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=38500
[Bug c++/38512] New: Was installing MySQL via FreeBSDs ports
Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.4.6 [FreeBSD] 20060305 I was using the MySQL-5.0.67 port, make install all clean.. if c++ -DMYSQL_SERVER -DDEFAULT_MYSQL_HOME=\/usr/local\ -DDATADIR=\/var/db/mysql\ -DSHAREDIR=\/usr/local/share/mysql\ -DHAVE_CONFIG_H -I. -I. -I../include -I../bdb/build_unix -I../innobase/include -I../innobase/include -I../include -I../include -I../regex -I. -DDBUG_OFF -O2 -fno-strict-aliasing -pipe -O2 -fno-strict-aliasing -pipe -felide-constructors -fno-rtti -fno-exceptions -fno-implicit-templates -fno-exceptions -fno-rtti -DMYSQLD_NET_RETRY_COUNT=100 -MT item_sum.o -MD -MP -MF .deps/item_sum.Tpo -c -o item_sum.o item_sum.cc; then mv -f .deps/item_sum.Tpo .deps/item_sum.Po; else rm -f .deps/item_sum.Tpo; exit 1; fi In file included from item.h:2202, from mysql_priv.h:588, from item_sum.cc:23: item_subselect.h:574: internal compiler error: Segmentation fault: 11 Please submit a full bug report, -- Summary: Was installing MySQL via FreeBSDs ports Product: gcc Version: 3.4.6 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: levi dot durfee at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38512
[Bug c++/38512] Was installing MySQL via FreeBSDs ports
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-13 00:07 --- Is this always reproducible? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38512
[Bug bootstrap/38383] fails to build cross gcc for target hppa64-hp-hpux11.00
--- Comment #2 from danglin at gcc dot gnu dot org 2008-12-13 00:15 --- Subject: Bug 38383 Author: danglin Date: Sat Dec 13 00:14:15 2008 New Revision: 142729 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142729 Log: PR bootstrap/38383 * pa64-hpux.h (LINK_GCC_C_SEQUENCE_SPEC): Don't hardcode search path for the milli.a library. Modified: trunk/gcc/ChangeLog trunk/gcc/config/pa/pa64-hpux.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38383
[Bug bootstrap/38383] fails to build cross gcc for target hppa64-hp-hpux11.00
--- Comment #3 from danglin at gcc dot gnu dot org 2008-12-13 00:19 --- Subject: Bug 38383 Author: danglin Date: Sat Dec 13 00:18:00 2008 New Revision: 142734 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142734 Log: PR bootstrap/38383 * pa64-hpux.h (LINK_GCC_C_SEQUENCE_SPEC): Don't hardcode search path for the milli.a library. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/pa/pa64-hpux.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38383
[Bug bootstrap/38383] fails to build cross gcc for target hppa64-hp-hpux11.00
--- Comment #4 from danglin at gcc dot gnu dot org 2008-12-13 00:23 --- Fixed. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Summary|fails to build cross gcc for|fails to build cross gcc for |target hppa64-hp-hpux11.00 |target hppa64-hp-hpux11.00 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38383
[Bug libstdc++/38384] fails to build cross gcc for target hppa64-hp-hpux11.00 in libstdc++/libmath
--- Comment #3 from danglin at gcc dot gnu dot org 2008-12-13 00:37 --- This doesn't occur in native builds because: /* Define to 1 if you have the `fabsf' function. */ #define HAVE_FABSF 1 -- 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=38384
[Bug c++/38512] Was installing MySQL via FreeBSDs ports
--- Comment #2 from levi dot durfee at gmail dot com 2008-12-13 01:11 --- (In reply to comment #1) Is this always reproducible? I'm sorry, this was my first time ever reporting a bug.. it works now -- levi dot durfee at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38512
[Bug libstdc++/37144] A bug in include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp
--- Comment #29 from hjl at gcc dot gnu dot org 2008-12-13 01:41 --- Subject: Bug 37144 Author: hjl Date: Sat Dec 13 01:40:15 2008 New Revision: 142736 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142736 Log: 2008-12-12 H.J. Lu hongjiu...@intel.com PR libstdc++/37144 * testsuite/util/regression/trait/assoc/type_trait.hpp (regression_test_type_traits): Add const to pair_type_rebind. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/util/regression/trait/assoc/type_trait.hpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37144
[Bug libstdc++/37144] A bug in include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp
--- Comment #30 from hjl at gcc dot gnu dot org 2008-12-13 01:47 --- Subject: Bug 37144 Author: hjl Date: Sat Dec 13 01:46:04 2008 New Revision: 142737 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142737 Log: 2008-12-12 H.J. Lu hongjiu...@intel.com Backport from mainline: 2008-12-12 H.J. Lu hongjiu...@intel.com PR libstdc++/37144 * testsuite/util/regression/trait/assoc/type_trait.hpp (regression_test_type_traits): Add const to pair_type_rebind. Modified: branches/gcc-4_3-branch/libstdc++-v3/ChangeLog branches/gcc-4_3-branch/libstdc++-v3/testsuite/util/regression/trait/assoc/type_trait.hpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37144
[Bug tree-optimization/38465] [4.4 Regression] graphite libraries undocumented
--- Comment #1 from spop at gcc dot gnu dot org 2008-12-13 01:52 --- Created an attachment (id=16901) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16901action=view) install documentation for graphite Hi, Here are the documentation changes. I will send the patch to the gcc-patches list. -- spop at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |spop at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38465
[Bug libstdc++/37144] A bug in include/ext/pb_ds/detail/pat_trie_/constructors_destructor_fn_imps.hpp
--- Comment #31 from hjl dot tools at gmail dot com 2008-12-13 02:02 --- Created an attachment (id=16902) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16902action=view) A patch to add -D_GLIBCXX_DEBUG to dg-options I am testing this patch to see if it can trigger the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37144
[Bug tree-optimization/38513] New: Only postreload will remove a no-op store
Take:
struct f{
float a;
float b;
float c;
float d;
};
struct f a;
void h(float, float, float, float);
void g(void)
{
float a1 = a.a, b = a.b, c = a.c, d = a.d;
a.a = a1;
a.b = b;
a.c = c;
a.d = d;
h(a1, b, c, d);
}
--- CUT ---
Currently only postreload will remove the store back to a.a, a.b, a.c, and a.d.
Note this code orginally came from inlined code and was just reduced to this.
And if this was done before postreload, we don't need a fmr which was produced
by the register allocator.
--
Summary: Only postreload will remove a no-op store
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: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38513
[Bug tree-optimization/38513] Only postreload will remove a no-op store
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-13 02:35 --- Also note if we do -Dfloat=int on a target like PPC, the stores are not removed because postreloadcse does not understand mode changes that well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38513
[Bug tree-optimization/38513] Only postreload will remove a no-op store
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-13 02:37 --- (In reply to comment #1) Also note if we do -Dfloat=int on a target like PPC, the stores are not removed because postreloadcse does not understand mode changes that well. I should say PPC64 or -Dfloat=short for PPC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38513
[Bug libgomp/38514] New: use -fopenmp compile gcc 4.4
$gcc --version $gcc (GCC) 4.4.0 20081213 (experimental) $echo $CFLAGS $-pipe -O3 -march=core2 -mfpmath=sse -ftree-vectorize -ftree-parallelize-loops=2 -pthread -fopenmp I compiled and installed gmp,mpfr with this cflags, after that, I try to compile gcc trunk and got : gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -o cc1-dummy c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o c-ppoutput.o c-cppbuiltin.o c-objc-common.o c-dump.o c-pch.o c-parser.o i386-c.o c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o dummy-checksum.o \ main.o tree-browser.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/gcc-4.4/gmp/lib -L/gcc-4.4/mpfr/lib -lmpfr -lgmp /gcc-4.4/mpfr/lib/libmpfr.so: undefined reference to `GOMP_parallel_end' /gcc-4.4/mpfr/lib/libmpfr.so: undefined reference to `omp_get_num_threads' /gcc-4.4/mpfr/lib/libmpfr.so: undefined reference to `GOMP_parallel_start' /gcc-4.4/mpfr/lib/libmpfr.so: undefined reference to `omp_get_thread_num' what's wrong ? -- Summary: use -fopenmp compile gcc 4.4 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: linuxl4 at sohu dot com GCC build triplet: X86_64-unknown-linux-gnu GCC host triplet: X86_64-unknown-linux-gnu GCC target triplet: X86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38514
