[Bug libgomp/64635] darwin produces libgomp-plugin-host_nonshm.1.dylib but tries to load libgomp-plugin-host_nonshm.so.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64635 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Better add config/darwin/ and some header to it that defines SONAME_SUFFIX(n), where it would be .so. #n in config/posix/ version of the header and . #n .dylib in the config/darwin/ version of the header.
[Bug c++/64647] [5 Regression] [C++14] std::__max_element contains code not allowed in constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64647
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
CC||jason at redhat dot com
Component|libstdc++ |c++
--- Comment #1 from Ville Voutilainen ville.voutilainen at gmail dot com ---
This code
templatetypename T
constexpr T foo(T t)
{
T tt = t;
++tt;
return tt;
}
struct X
{
X() { }
X operator++() { return *this; }
};
int main()
{
X x;
foo(x);
}
is accepted by clang but rejected by gcc. Moving to front-end.
[Bug c++/63287] __STDCPP_THREADS__ is not defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63287 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-17 Ever confirmed|0 |1
[Bug fortran/64578] [OOP] Seg-fault and ICE with unlimited polymorphic array pointer function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64578 --- Comment #11 from Paul Thomas pault at gcc dot gnu.org --- Author: pault Date: Sat Jan 17 20:44:07 2015 New Revision: 219802 URL: https://gcc.gnu.org/viewcvs?rev=219802root=gccview=rev Log: 2015-01-17 Paul Thomas pa...@gcc.gnu.org PR fortran/64578 * trans-expr.c (gfc_trans_pointer_assignment): Make sure that before reinitializing rse, to add the rse.pre to block before creating 'ptrtemp'. * trans-intrinsic.c (gfc_conv_associated): Deal with the class data being a descriptor. 2015-01-17 Paul Thomas pa...@gcc.gnu.org PR fortran/64578 * gfortran.dg/unlimited_polymorphic_21.f90: New test Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog
[Bug boehm-gc/64042] FAIL: boehm-gc.c/gctest.c -O2 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64042 Iain Sandoe iains at gcc dot gnu.org changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #10 from Iain Sandoe iains at gcc dot gnu.org --- I got 1 fail in a 1000 on x86_64-darwin12, so it is not Linux-specific.
[Bug libstdc++/64649] New: regex_traits::lookup_classname() only works with random access iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64649
Bug ID: 64649
Summary: regex_traits::lookup_classname() only works with
random access iterators
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
#include regex
#include forward_list
int main()
{
std::forward_listchar f{ 'A' };
std::regex_traitschar{}.lookup_collatename(f.begin(), f.end());
}
This function should work with ForwardIterators, but it fails because of line
300 in bits/regex.tcc
std::string __s(__last - __first, '?');
[Bug fortran/64578] [OOP] Seg-fault and ICE with unlimited polymorphic array pointer function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64578 --- Comment #12 from Dominique d'Humieres dominiq at lps dot ens.fr --- AFAICT gfortran.dg/unlimited_polymorphic_21.f90 has not yet been committed.
[Bug libstdc++/64651] New: std::rethrow_exception not found by ADL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64651
Bug ID: 64651
Summary: std::rethrow_exception not found by ADL
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
This fails (using -std=c++11):
#include exception
int main()
{
std::exception_ptr e;
rethrow_exception(e);
}
The standard declares:
typedef _unspecified_ exception_ptr;
[[noreturn]] void rethrow_exception(exception_ptr p);
So it's conforming for exception_ptr to be a typedef for a type in a different
namespace, and in that case ADL won't find std::rethrow_exception, but it's not
very helpful to users for it to fail.
This makes it work as expected:
--- a/libstdc++-v3/libsupc++/exception_ptr.h
+++ b/libstdc++-v3/libsupc++/exception_ptr.h
@@ -68,6 +68,8 @@ namespace std
namespace __exception_ptr
{
+using std::rethrow_exception;
+
/**
* @brief An opaque pointer to an arbitrary exception.
* @ingroup exceptions
[Bug libstdc++/64638] [5 Regression] Build failure with recent futex changes in libstdc++, likely all non-gthreads targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64638 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Hans-Peter Nilsson hp at gcc dot gnu.org --- (In reply to Jonathan Wakely from comment #5) It should be fixed now, but I'll leave this open until someone confirms the build works again. Fixed for cris-elf, for example at r219800. I see a conversation that other targets may have different experiences, but I'll let them deal with that, suggesting to take the lock and either re-opening and (hopefully in due time also) re-closing this PR, or a new one.
[Bug libstdc++/64647] New: [5 Regression] [C++14] std::__max_element contains code not allowed in constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64647
Bug ID: 64647
Summary: [5 Regression] [C++14] std::__max_element contains
code not allowed in constexpr function
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
CC: ville.voutilainen at gmail dot com
#include forward_list
#include algorithm
int main()
{
std::forward_listint v;
std::max_element(v.begin(), v.end());
}
Compiling with -std=c++14 gives:
In file included from /home/jwakely/gcc/5/include/c++/5.0.0/algorithm:62:0,
from max.cc:2:
/home/jwakely/gcc/5/include/c++/5.0.0/bits/stl_algo.h: In instantiation of
‘constexpr _ForwardIterator std::__max_element(_ForwardIterator,
_ForwardIterator, _Compare) [with _ForwardIterator =
std::_Fwd_list_iteratorint; _Compare = __gnu_cxx::__ops::_Iter_less_iter]’:
/home/jwakely/gcc/5/include/c++/5.0.0/bits/stl_algo.h:5514:43: required from
‘constexpr _FIter std::max_element(_FIter, _FIter) [with _FIter =
std::_Fwd_list_iteratorint]’
max.cc:7:38: required from here
/home/jwakely/gcc/5/include/c++/5.0.0/bits/stl_algo.h:5489:35: error: variable
‘__result’ of non-literal type ‘std::_Fwd_list_iteratorint’ in ‘constexpr’
function
_ForwardIterator __result = __first;
^
In file included from /home/jwakely/gcc/5/include/c++/5.0.0/forward_list:38:0,
from max.cc:1:
/home/jwakely/gcc/5/include/c++/5.0.0/bits/forward_list.h:120:12: note:
‘std::_Fwd_list_iteratorint’ is not literal because:
struct _Fwd_list_iterator
^
/home/jwakely/gcc/5/include/c++/5.0.0/bits/forward_list.h:120:12: note:
‘std::_Fwd_list_iteratorint’ is not an aggregate, does not have a trivial
default constructor, and has no constexpr constructor that is not a copy or
move constructor
[Bug libstdc++/64647] [5 Regression] [C++14] std::__max_element contains code not allowed in constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64647 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-17 Known to work||4.9.2 Ever confirmed|0 |1
[Bug fortran/60357] [F08] structure constructor with unspecified values for allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60357 --- Comment #13 from Paul Thomas pault at gcc dot gnu.org --- Author: pault Date: Sat Jan 17 18:08:38 2015 New Revision: 219801 URL: https://gcc.gnu.org/viewcvs?rev=219801root=gccview=rev Log: 2015-01-17 Andre Vehreschild ve...@gmx.de PR fortran/60357 * primary.c (build_actual_constructor): Prevent warning. * trans-expr.c (alloc_scalar_allocatable_for_subcomponent_ assignment): New function encapsulates treatment of allocatable components. (gfc_trans_subcomponent_assign): Needed to distinguish between regular assignment and initilization. (gfc_trans_structure_assign): Same. (gfc_conv_structure): Same. PR fortran/61275 * gfortran.h: deferred_parameter is not needed, because it artificial does the trick completely. * primary.c (build_actual_constructor): Same. (gfc_convert_to_structure_constructor): Same. * resolve.c (resolve_fl_derived0): Same. * trans-expr.c (gfc_conv_component_ref): Prevent treating allocatable deferred length char arrays here. (gfc_trans_subcomponent_assign): Same as above. * trans-types.c (gfc_sym_type): This is done in gfc_get_derived_type already. 2015-01-17 Andre Vehreschild ve...@gmx.de PR fortran/60357 * gfortran.dg/alloc_comp_assign_13.f08: New test. PR fortran/61275 * gfortran.dg/alloc_comp_assign_14.f08: New test. PR fortran/55932 * gfortran.dg/alloc_comp_initializer_4.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/alloc_comp_assign_13.f08 trunk/gcc/testsuite/gfortran.dg/alloc_comp_assign_14.f08 trunk/gcc/testsuite/gfortran.dg/alloc_comp_initializer_4.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/primary.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/55932] [F03] ICE for structure constructor with scalar allocatable component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55932 --- Comment #10 from Paul Thomas pault at gcc dot gnu.org --- Author: pault Date: Sat Jan 17 18:08:38 2015 New Revision: 219801 URL: https://gcc.gnu.org/viewcvs?rev=219801root=gccview=rev Log: 2015-01-17 Andre Vehreschild ve...@gmx.de PR fortran/60357 * primary.c (build_actual_constructor): Prevent warning. * trans-expr.c (alloc_scalar_allocatable_for_subcomponent_ assignment): New function encapsulates treatment of allocatable components. (gfc_trans_subcomponent_assign): Needed to distinguish between regular assignment and initilization. (gfc_trans_structure_assign): Same. (gfc_conv_structure): Same. PR fortran/61275 * gfortran.h: deferred_parameter is not needed, because it artificial does the trick completely. * primary.c (build_actual_constructor): Same. (gfc_convert_to_structure_constructor): Same. * resolve.c (resolve_fl_derived0): Same. * trans-expr.c (gfc_conv_component_ref): Prevent treating allocatable deferred length char arrays here. (gfc_trans_subcomponent_assign): Same as above. * trans-types.c (gfc_sym_type): This is done in gfc_get_derived_type already. 2015-01-17 Andre Vehreschild ve...@gmx.de PR fortran/60357 * gfortran.dg/alloc_comp_assign_13.f08: New test. PR fortran/61275 * gfortran.dg/alloc_comp_assign_14.f08: New test. PR fortran/55932 * gfortran.dg/alloc_comp_initializer_4.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/alloc_comp_assign_13.f08 trunk/gcc/testsuite/gfortran.dg/alloc_comp_assign_14.f08 trunk/gcc/testsuite/gfortran.dg/alloc_comp_initializer_4.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/primary.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/61275] Invalid initialization expression for ALLOCATABLE component in structure constructor at (1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61275 --- Comment #2 from Paul Thomas pault at gcc dot gnu.org --- Author: pault Date: Sat Jan 17 18:08:38 2015 New Revision: 219801 URL: https://gcc.gnu.org/viewcvs?rev=219801root=gccview=rev Log: 2015-01-17 Andre Vehreschild ve...@gmx.de PR fortran/60357 * primary.c (build_actual_constructor): Prevent warning. * trans-expr.c (alloc_scalar_allocatable_for_subcomponent_ assignment): New function encapsulates treatment of allocatable components. (gfc_trans_subcomponent_assign): Needed to distinguish between regular assignment and initilization. (gfc_trans_structure_assign): Same. (gfc_conv_structure): Same. PR fortran/61275 * gfortran.h: deferred_parameter is not needed, because it artificial does the trick completely. * primary.c (build_actual_constructor): Same. (gfc_convert_to_structure_constructor): Same. * resolve.c (resolve_fl_derived0): Same. * trans-expr.c (gfc_conv_component_ref): Prevent treating allocatable deferred length char arrays here. (gfc_trans_subcomponent_assign): Same as above. * trans-types.c (gfc_sym_type): This is done in gfc_get_derived_type already. 2015-01-17 Andre Vehreschild ve...@gmx.de PR fortran/60357 * gfortran.dg/alloc_comp_assign_13.f08: New test. PR fortran/61275 * gfortran.dg/alloc_comp_assign_14.f08: New test. PR fortran/55932 * gfortran.dg/alloc_comp_initializer_4.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/alloc_comp_assign_13.f08 trunk/gcc/testsuite/gfortran.dg/alloc_comp_assign_14.f08 trunk/gcc/testsuite/gfortran.dg/alloc_comp_initializer_4.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/primary.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog
[Bug libgomp/64635] darwin produces libgomp-plugin-host_nonshm.1.dylib but tries to load libgomp-plugin-host_nonshm.so.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64635
--- Comment #3 from howarth at bromo dot med.uc.edu ---
The minimal fix would be...
Index: libgomp/configure.tgt
===
--- libgomp/configure.tgt (revision 219800)
+++ libgomp/configure.tgt (working copy)
@@ -133,6 +133,8 @@ case ${target} in
*-*-darwin*)
config_path=bsd posix
+ # Load plugin as dylib on darwin.
+ XCFLAGS=${XCFLAGS} -DDYLIB_SHLIBEXT
;;
*-*-freebsd*)
Index: libgomp/target.c
===
--- libgomp/target.c(revision 219800)
+++ libgomp/target.c(working copy)
@@ -1055,7 +1055,11 @@ static void
gomp_target_init (void)
{
const char *prefix =libgomp-plugin-;
+#ifdef DYLIB_SHLIBEXT
+ const char *suffix = .1.dylib;
+#else
const char *suffix = .so.1;
+#endif
const char *cur, *next;
char *plugin_name;
int i, new_num_devices;
[Bug libstdc++/64649] regex_traits::lookup_classname() only works with random access iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64649 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-17 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Actually it's even worse than that, the next line will only work with pointers and not even arbitrary random access iterators: __fctyp.narrow(__first, __last, '?', *__s.begin()); The signature of ctypecharT::narrow is const charT* ctypecharT::narrow(const charT*, const charT*, char, char*) const; So __first and __last are not acceptable arguments.
[Bug libstdc++/64650] New: std::experimental::bad_optional_access is not default constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64650 Bug ID: 64650 Summary: std::experimental::bad_optional_access is not default constructible Product: gcc Version: 4.9.3 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org This should compile using -std=c++14: #include experimental/optional std::experimental::bad_optional_access e; badopt.cc:3:40: error: no matching function for call to ‘std::experimental::fundamentals_v1::bad_optional_access::bad_optional_access()’ std::experimental::bad_optional_access e; ^
[Bug libstdc++/64650] std::experimental::bad_optional_access is not default constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64650 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-17 Ever confirmed|0 |1 Known to fail||4.9.3, 5.0
[Bug c/64648] New: Incorrect message description of -Wunused-value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64648
Bug ID: 64648
Summary: Incorrect message description of -Wunused-value
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: chengniansun at gmail dot com
GCC emits a -Wunused-value warning with a wrong description for the expression
(a = 0) = 0. There is no comma expression, but the message is
right-hand operand of comma expression has no effect
If I change the operator from = to !=, then the message is correct.
$: cat t.c
int a;
void f() {
(a = 0) != 0;
(a = 0) = 0;
}
$:
$: gcc-trunk -c -Wunused-value t.c
t.c: In function ‘f’:
t.c:3:11: warning: value computed is not used [-Wunused-value]
(a = 0) != 0;
^
t.c:4:11: warning: right-hand operand of comma expression has no effect
[-Wunused-value]
(a = 0) = 0;
^
$:
$: clang-trunk -c -Wunused-value t.c
t.c:3:11: warning: inequality comparison result unused [-Wunused-comparison]
(a = 0) != 0;
^~~~
t.c:4:11: warning: relational comparison result unused [-Wunused-comparison]
(a = 0) = 0;
^~~~
2 warnings generated.
$:
[Bug fortran/60922] [4.9/5 regression] Memory leak with allocatable CLASS components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60922
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org
--- Comment #10 from janus at gcc dot gnu.org ---
The following patchlet seems to fix it. Might just be a copy'n'paste error?
Index: gcc/fortran/class.c
===
--- gcc/fortran/class.c(Revision 219801)
+++ gcc/fortran/class.c(Arbeitskopie)
@@ -875,7 +875,7 @@ finalize_component (gfc_expr *expr, gfc_symbol *de
/* Add IF (fini_coarray). */
if (comp-attr.codimension
|| (comp-ts.type == BT_CLASS CLASS_DATA (comp)
- CLASS_DATA (comp)-attr.allocatable))
+ CLASS_DATA (comp)-attr.codimension))
{
block = gfc_get_code (EXEC_IF);
if (*code)
[Bug middle-end/44982] [4.8/4.9/5 Regression] ICE in get_narrower, at tree.c:7832
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44982 --- Comment #12 from tbsaunde at gcc dot gnu.org --- (In reply to rguent...@suse.de from comment #11) On Thu, 15 Jan 2015, tbsaunde at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44982 tbsaunde at gcc dot gnu.org changed: What|Removed |Added CC||tbsaunde at gcc dot gnu.org --- Comment #10 from tbsaunde at gcc dot gnu.org --- (In reply to Richard Biener from comment #1) Confirmed. hm, wfm, but it looks like the patch in comment 3 wasn't applied. Is there something to do here? Not sure if it was posted or tested - so maybe just do a bootstrap regtest with all languages and if that succeeds the patch (with the testcase) is preapproved. there is at least a large number of c++ test cases that fail with the patch. They all seem to be what you'd expect a file has errors before the new check, and more errors or warnings are expected to be emitted after the new check. It seems like some part of this setup is crazy, but I'm not really sure what to do about it at this point.
[Bug target/60884] [SH] improve inlined strlen-like builtin functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60884
--- Comment #5 from Oleg Endo olegendo at gcc dot gnu.org ---
The test case gcc.target/sh/memset.c:
void
test00(char *dstb)
{
__builtin_memset (dstb, 0, 15);
}
compiles to:
mov r4,r0
tst #3,r0
mov #0,r1
bf/s.L5
mov #15,r2
mov #3,r2
.L3:
mov.l r1,@r4loop runs 3x.
dt r2better emit 3x mov.l
bf/s.L3
add #4,r4
mov.b r1,@r4
add #1,r4
mov.b r1,@r4
add #1,r4
rts
mov.b r1,@r4
.align 1
.L5:
mov.b r1,@r4
dt r2
bf/s.L5
add #1,r4
rts
nop
Especially when the number of the iterations is known, we should try to unroll
the loops.
[Bug fortran/60922] [4.9/5 regression] Memory leak with allocatable CLASS components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60922 --- Comment #11 from janus at gcc dot gnu.org --- (In reply to janus from comment #10) The following patchlet seems to fix it. Might just be a copy'n'paste error? In any case it regtests cleanly.
[Bug c/64639] false negative of -Wunused-value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64639
--- Comment #3 from Chengnian Sun chengniansun at gmail dot com ---
(In reply to Chengnian Sun from comment #2)
(In reply to Andrew Pinski from comment #1)
(a = 0) != 0 has a side effect of setting a to 0.
I think in this case, clang is incorrectly warning about it.
I agree that (a = 0) has a side effect, but the comparison != is not used.
Please refer to the following test program. GCC emits a warning for the
expression (a = 0) != 0.
$: cat t.c
int a;
void f() {
(a = 0) != 0;
}
$: gcc-trunk -c -Wunused-value t.c
t.c: In function ¡®f¡¯:
t.c:3:11: warning: value computed is not used [-Wunused-value]
(a = 0) != 0;
^
[Bug c++/64653] Incomplete emission of D1/D2 destructors when optimising -- link failure with gold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64653 --- Comment #2 from Thiago Macieira thiago at kde dot org --- Created attachment 34472 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34472action=edit src1 assembly output by GCC 4.9
[Bug libgomp/64625] ___OFFLOAD_TABLE__ symbol not produced on x86_64 darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64625 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Target|x86_64-apple-darwin14 |x86_64-apple-darwin14, ||powerpc-ibm-aix* CC||dje at gcc dot gnu.org Host|x86_64-apple-darwin14 |x86_64-apple-darwin14, ||powerpc-ibm-aix* Build|x86_64-apple-darwin14 |x86_64-apple-darwin14, ||powerpc-ibm-aix* --- Comment #8 from David Edelsohn dje at gcc dot gnu.org --- The same libgomp testsuite failure occur on AIX.
[Bug target/64652] New: [SH] ICE when using -mdiv=call-fp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64652
Bug ID: 64652
Summary: [SH] ICE when using -mdiv=call-fp
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*
Compiling the following example:
int test (int a, int b, int c, int d)
{
return (a / b) + c + d;
}
with -O2 -m4 -ml -mdiv=call-fp
results in:
sh_tmp.cpp: In function 'test':
sh_tmp.cpp:672:1: error: unrecognizable insn:
}
^
(insn 50 30 12 (set (reg:SI 146 pr)
(unspec:SI [
(reg:SI 154 fpscr0)
] UNSPEC_SFUNC)) sh_tmp.cpp:671 -1
(nil))
sh_tmp.cpp:672:1: internal compiler error: in num_delay_slots, at
config/sh/sh.md:537
It looks like the SH mach pass expects the first use to be the GP reg that
holds the sfunc address. Changing the order of the uses seems to fix the
problem:
Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md(revision 219623)
+++ gcc/config/sh/sh.md(working copy)
@@ -2402,8 +2402,8 @@
(clobber (reg:SI R4_REG))
(clobber (reg:SI R5_REG))
(clobber (reg:SI FPSCR_STAT_REG))
- (use (reg:SI FPSCR_MODES_REG))
- (use (match_operand:SI 1 arith_reg_operand r))]
+ (use (match_operand:SI 1 arith_reg_operand r))
+ (use (reg:SI FPSCR_MODES_REG))]
TARGET_FPU_DOUBLE ! TARGET_FPU_SINGLE
jsr@%1%#
[(set_attr type sfunc)
@@ -2674,8 +2674,8 @@
(clobber (reg:DF DR0_REG))
(clobber (reg:DF DR2_REG))
(clobber (reg:SI FPSCR_STAT_REG))
- (use (reg:SI FPSCR_MODES_REG))
- (use (match_operand:SI 1 arith_reg_operand r))]
+ (use (match_operand:SI 1 arith_reg_operand r))
+ (use (reg:SI FPSCR_MODES_REG))]
TARGET_FPU_DOUBLE ! TARGET_FPU_SINGLE
jsr@%1%#
[(set_attr type sfunc)
[Bug libgomp/64625] ___OFFLOAD_TABLE__ symbol not produced on x86_64 darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64625 --- Comment #9 from David Edelsohn dje at gcc dot gnu.org --- Locally reverting the creation of offload_table may avoid the reference to the undefined symbol as a workaround to get sane testsuite results. tree offload_table = build_zero_cst (ptr_type_node); The failures on AIX are: FAIL: libgomp.c/examples-4/e.50.1.c (test for excess errors) Excess errors: ld: 0711-317 ERROR: Undefined symbol: __OFFLOAD_TABLE__ ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. WARNING: libgomp.c/examples-4/e.50.1.c compilation failed to produce executable
[Bug c++/64653] Incomplete emission of D1/D2 destructors when optimising -- link failure with gold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64653 --- Comment #1 from Thiago Macieira thiago at kde dot org --- Created attachment 34471 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34471action=edit src1 assembly output by GCC 4.9
[Bug c++/64653] New: Incomplete emission of D1/D2 destructors when optimising -- link failure with gold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64653 Bug ID: 64653 Summary: Incomplete emission of D1/D2 destructors when optimising -- link failure with gold Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: thiago at kde dot org Created attachment 34470 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34470action=edit Test project When the attached project is built with GCC 5 (x86-64, SVN build from 219682) and linked with gold, the linker exits with: /usr/bin/ld.gold: error: src2.o: requires dynamic R_X86_64_PC32 reloc against '_ZN5QListI7QStringED1Ev' which may overflow at runtime; recompile with -fPIC src2.cpp:3: warning: relocation refers to discarded section In other words: the linker wants to use a symbol that is present in the same .o file itself, but it has discarded that section. Since now the symbol is out-of-library, it prints an error about the relocation. It appears that the issue is highly dependent on optimisations applied to src1.cpp, which is why I am also attaching the generated assembly by my version of GCC. If I compare that generated assembly with the one generated by GCC 4.9, the following diff stands out: --- src1-4.9.s 2015-01-17 17:31:02.254643092 -0800 +++ src1-5.0.s 2015-01-17 17:30:50.795714657 -0800 @@ -38,9 +38,6 @@ .LCOLDE0: .section .text._ZN5QListI7QStringED2Ev,axG,@progbits,_ZN5QListI7QStringED5Ev,comdat .LHOTE0: - .weak _ZN5QListI7QStringED1Ev - .hidden _ZN5QListI7QStringED1Ev - .set_ZN5QListI7QStringED1Ev,_ZN5QListI7QStringED2Ev .section.text.unlikely,ax,@progbits In other words, the compiler failed to emit the symbol for the D1 destructor in src1.o. In this file, GCC emitted calls to the D2 destructor only. If we look at src2.o, the compiler emitted a call to the D1 destructor, not to D2. It did emit the correct section with the D1 symbol, but gold discarded this section, as it chose the one from src1.o. The regular ld.bfd does not seem to have a problem. It's not apparent to me why GCC chose D1 over D2 or vice-versa. This class has no base, let alone a virtual base, so both destructors are identical. Clang 3.5 and 3.6 emit only the D2 destructor; it doesn't seem to emit D1 at all, not even as an alias, in either source file. I expected the same problem to occur if I compiled src1 with clang and src2 with GCC, but there was no linker error. The only other difference was that Clang did not emit the D5 symbol. ICC emits both and calls D1 in src1.o (under -O0) and emits D1 only in src2.o, calling it. D5 is also missing.
[Bug libgomp/64635] darwin produces libgomp-plugin-host_nonshm.1.dylib but tries to load libgomp-plugin-host_nonshm.so.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64635 --- Comment #5 from howarth at bromo dot med.uc.edu --- Created attachment 34469 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34469action=edit proposed fix for plugin suffix Bootstrap and libgomp regression tested on x86_64-apple-darwin14.
[Bug c/64639] false negative of -Wunused-value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64639 Chengnian Sun chengniansun at gmail dot com changed: What|Removed |Added CC||chengniansun at gmail dot com --- Comment #2 from Chengnian Sun chengniansun at gmail dot com --- (In reply to Andrew Pinski from comment #1) (a = 0) != 0 has a side effect of setting a to 0. I think in this case, clang is incorrectly warning about it. I agree that (a = 0) has a side effect, but the comparison != is not used.
[Bug target/42759] libgcc fails to compile with segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42759 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |WORKSFORME --- Comment #2 from Jeffrey A. Law law at redhat dot com --- Just tried the testcase with reported options against the top of the trunk as well as the gcc-4.4 branch.
[Bug target/28040] [m68k]wrong move const extends output at coldfire v4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28040 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #2 from Jeffrey A. Law law at redhat dot com --- Fixed eons ago. Verified still works on trunk as well.
[Bug target/25678] -m68000 doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25678 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |INVALID --- Comment #1 from Jeffrey A. Law law at redhat dot com --- No testcase provided.
[Bug ada/64640] New: Ada build failure on cygwin-32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64640 Bug ID: 64640 Summary: Ada build failure on cygwin-32 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: bernd.edlinger at hotmail dot de I used r219767: /home/ED/gcc-build/./gcc/xgcc -B/home/ED/gcc-build/./gcc/ -B/home/ED/install/i686-pc-cygwin/bin/ -B/home/ED/install/i686-pc-cygwin/lib/ -isystem /home/ED/install/i686-pc-cygwin/include -isystem /home/ED/install/i686-pc-cygwin/sys-include-c -DIN_GCC -W -Wall -g -O2 -g -O2 -fexceptions -DIN_RTS -DHAVE_GETIPINFO \ -iquote . -iquote .. -iquote ../.. -iquote /home/ED/gcc-r219767/gcc/ada -iquote /home/ED/gcc-r219767/gcc -I/home/ED/gcc-r219767/include -I./../.. sysdep.c -o sysdep.o In file included from sysdep.c:138:0: sysdep.c: In function ‘__gnat_set_mode’: sysdep.c:170:35: error: ‘CurrentCCSEncoding’ undeclared (first use in this function) case 1 : WIN_SETMODE (handle, CurrentCCSEncoding); break; ^ sysdep.c:170:14: note: in expansion of macro ‘WIN_SETMODE’ case 1 : WIN_SETMODE (handle, CurrentCCSEncoding); break; ^ sysdep.c:170:35: note: each undeclared identifier is reported only once for each function it appears in case 1 : WIN_SETMODE (handle, CurrentCCSEncoding); break; ^ sysdep.c:170:14: note: in expansion of macro ‘WIN_SETMODE’ case 1 : WIN_SETMODE (handle, CurrentCCSEncoding); break; ^ sysdep.c:172:35: error: ‘_O_U8TEXT’ undeclared (first use in this function) case 3 : WIN_SETMODE (handle, _O_U8TEXT); break; ^ sysdep.c:172:14: note: in expansion of macro ‘WIN_SETMODE’ case 3 : WIN_SETMODE (handle, _O_U8TEXT); break; ^ sysdep.c:173:35: error: ‘_O_WTEXT’ undeclared (first use in this function) case 4 : WIN_SETMODE (handle, _O_WTEXT); break; ^ sysdep.c:173:14: note: in expansion of macro ‘WIN_SETMODE’ case 4 : WIN_SETMODE (handle, _O_WTEXT); break; ^ sysdep.c:174:35: error: ‘_O_U16TEXT’ undeclared (first use in this function) case 5 : WIN_SETMODE (handle, _O_U16TEXT); break; ^ sysdep.c:174:14: note: in expansion of macro ‘WIN_SETMODE’ case 5 : WIN_SETMODE (handle, _O_U16TEXT); break; ^ ../gcc-interface/Makefile:304: recipe for target 'sysdep.o' failed make[6]: *** [sysdep.o] Error 1 make[6]: Leaving directory '/home/ED/gcc-build/gcc/ada/rts' gcc-interface/Makefile:2750: recipe for target 'gnatlib' failed make[5]: *** [gnatlib] Error 2 make[5]: Leaving directory '/home/ED/gcc-build/gcc/ada' gcc-interface/Makefile:2858: recipe for target 'gnatlib-shared-win32' failed make[4]: *** [gnatlib-shared-win32] Error 2 make[4]: Leaving directory '/home/ED/gcc-build/gcc/ada' gcc-interface/Makefile:2911: recipe for target 'gnatlib-shared' failed make[3]: *** [gnatlib-shared] Error 2 make[3]: Leaving directory '/home/ED/gcc-build/gcc/ada' Makefile:113: recipe for target 'gnatlib-shared' failed make[2]: *** [gnatlib-shared] Error 2 make[2]: Leaving directory '/home/ED/gcc-build/i686-pc-cygwin/libada' Makefile:22345: recipe for target 'all-target-libada' failed make[1]: *** [all-target-libada] Error 2 make[1]: Leaving directory '/home/ED/gcc-build' Makefile:906: recipe for target 'all' failed make: *** [all] Error 2
[Bug c++/64641] New: ICE in get_polymorphic_call_info with C-cast to (polymorphic) object-reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64641
Bug ID: 64641
Summary: ICE in get_polymorphic_call_info with C-cast to
(polymorphic) object-reference
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: meisenmann@fh-salzburg.ac.at
Hi!
I've analyzed some (IMHO) malicious/mallformed cast(s) to a reference-type by
using a C-cast. I've determined a sample, which results in an ICE message on
GCC (release 4.9.2). I've used a (private) build of an GCC Cross-compiler
(target=i386-elf, host=mingw32), but the Mingw-W64 build of GCC 4.9.2 *) shows
the same result.
*) Downloaded from
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.2/threads-posix/dwarf/
(package i686-4.9.2-release-posix-dwarf-rt_v3-rev1.7z)
Following (minimal) sample:
/*-*/
class A
{
public:
virtual int get() const { return m_val; }
protected:
int m_val;
};
int Test2(int* arg)
{
A ref = (A) arg;
return ref.get();
}
/*-*/
and gcc -c test.cpp will show:
test.cpp: In function 'int Test2(int*)':
test.cpp:14:1: internal compiler error: in get_polymorphic_call_info, at
ipa-dev
irt.c:1223
}
^
Prior GCC releases (like 4.8.3 or 4.6.4) or the MS-VS2010 compiler does not
show a similar issue or compiler-warning/error.
Best regards from Salzburg,
Markus
[Bug middle-end/64642] New: Malformed code as result of C-cast to (polymorphic) object-reference (an opt-level ...)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64642
Bug ID: 64642
Summary: Malformed code as result of C-cast to (polymorphic)
object-reference (an opt-level ...)
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: meisenmann@fh-salzburg.ac.at
Hi!
I've analyzed some (IMHO) malicious/mallformed cast(s) to a reference-type by
using a C-cast. Additional to the already documented issue on an ICE (see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64641), I've determined a similar
test, which generates malformed (assembler) code.
Note: I've used a (private) build of an GCC Cross-compiler (target=i386-elf,
host=mingw32), but the Mingw-W64 build of GCC 4.9.2 *) shows the same result.
*) Downloaded from
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.2/threads-posix/dwarf/
(package i686-4.9.2-release-posix-dwarf-rt_v3-rev1.7z)
Following (minimal) sample:
/*-*/
class A
{
public:
virtual int get() const { return m_val; }
protected:
int m_val;
};
int Test3(int arg)
{
A ref = (A) arg;
return ref.get();
}
/*-*/
The difference to the ICE-sample (bug 64641) is only the type of the argument
(Ie. using 'int' instead of 'int*').
If the method get() has an inline-definition (like above) and if (for example)
the compiler-optimization '-Os' is used, the generated i386/x86-code is:
__Z5Test3i:
LFB1:
.cfi_startproc
pushl %ebp
.cfi_def_cfa_offset 8
.cfi_offset 5, -8
movl%esp, %ebp
.cfi_def_cfa_register 5
.cfi_endproc
And nothing more; Ie. only the function-prolog is there, but the body (cast,
virtual call) and function-epilog is dropped!
Note: As noted above, it' depends on the inline-definition and opt-level (maybe
other optimization-options).
Best regards from Salzburg,
Markus
[Bug c++/64643] New: bad location for multiple fields in union initialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64643
Bug ID: 64643
Summary: bad location for multiple fields in union initialized
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: deni_ at hotmail dot fr
For the following snipet of code
---
class a
{
union
{
bool b = false;
bool f = false;
};
};
--
with gcc 5.0 I get this warning:
./test.c:4:3: error: multiple fields in union ‘a::anonymous union’
initialized
{
^
What I would expect from gcc:
./test.c:5:5: error: multiple fields in union ‘a::anonymous union’
initialized
bool b = false;
^
./test.c:6:5 note: a field is already initialized here
bool f = false;
^
[Bug fortran/60334] Segmentation fault on character pointer assignments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60334 --- Comment #5 from Paul Thomas pault at gcc dot gnu.org --- Author: pault Date: Sat Jan 17 11:07:57 2015 New Revision: 219798 URL: https://gcc.gnu.org/viewcvs?rev=219798root=gccview=rev Log: 2015-01-17 Andre Vehreschild ve...@gmx.de PR fortran/60334 * trans-decl.c (gfc_get_symbol_decl):Use a ref on the string length when the symbol is declared to be a result. * trans-expr.c (gfc_conv_procedure_call): Strip deref on the string length when functions are nested and the string length is a reference already. 2015-01-17 Andre Vehreschild ve...@gmx.de PR fortran/60334 * gfortran.dg/deferred_type_param_6.f90: Add tests for this PR. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/deferred_type_param_6.f90
[Bug libstdc++/64638] Build failure with recent futex changes in libstdc++, likely all non-gthreads targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64638 Ulrich Weigand uweigand at gcc dot gnu.org changed: What|Removed |Added CC||uweigand at gcc dot gnu.org --- Comment #3 from Ulrich Weigand uweigand at gcc dot gnu.org --- I see the same failure on spu-elf (another non-gthreads target).
[Bug c++/64644] New: warning: anonymous union with no members should be an error with -pedantic-errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64644
Bug ID: 64644
Summary: warning: anonymous union with no members should be
an error with -pedantic-errors
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: harald at gigawatt dot nl
Compiling
static union { };
with gcc -std=c++11 -pedantic-errors gives
test.cc:1:16: warning: anonymous union with no members
static union { };
^
It's fine that it's a warning by default, but I think it should be an error
with -pedantic-errors, because it violates the last part of [dcl.dcl]p3: when
the init-declarator-list is omitted, the decl-specifier-seq shall introduce
one or more names into the program, or shall redeclare a name introduced by a
previous declaration. No exception is made for anonymous unions, so the only
way an anonymous union can avoid violating this is by having members.
(FWIW, I cannot find any options to get any warning whatsoever with clang,
Intel or Sun, and MSVC only warns at the highest warning level, regardless of
whether language extensions are enabled. As far as I can tell, GCC's current
handling is already the best of these five.)
[Bug tree-optimization/64601] Missed PRE on std::vector move assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64601
Marc Glisse glisse at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #9 from Marc Glisse glisse at gcc dot gnu.org ---
(In reply to Marc Glisse from comment #8)
The transformation is triggered by dereferences, and compares the types of
objects, not pointers, so it isn't obvious that the issues you were
describing apply to it.
It looks like they still do apply. I was just lucky that the folding was done
in an order where nothing bad happened in the tests. Your example
int *p = ((struct A *)b)-i;
*p = 0;
becomes *(int*)b=0, which is fine. But in a different order, what I wanted
could give: (*(struct A *)b).i=0 (access b as an A) which would be wrong for
TBAA. Although I don't see the point of writing that kind of code instead of:
int *p = (int*)((char*)b + offsetof(A, i));
So basically, a struct A * as an argument of a function doesn't carry any more
information than a void* :-( It is only if we can see an actual VAR_DECL or
similar that we may be able to reconstruct the access, but then we don't often
need to...
It is strange that [basic.lval] (or 6.5 Expressions in C99) is so lenient.
[class.mem] is a little bit more restrictive but still not much.
There is a little bit of divergence on function f below:
void f(struct A *a){ *a-i=0; }
void g(struct A *a){ int*p=a-i;*p=0; }
void h(struct A *a){ a-i=0; }
gcc, intel and oracle handle f like h, while clang is more conservative and
handles it like g (I actually tested on a function taking 2 std::pairint,int
by reference if a.first and b.second could alias).
Ok, I am starting to understand vaguely what C/C++ are saying about type
aliasing. I am horrified (this is a huge abstraction penalty), but at least I
am less confused. I'll close this PR as INVALID (the trick about the same
clobbering value is already in several other PRs, no need to keep this one as
well) (if you want to remove some current unsafe transformations, it would
probably be less confusing to open a different PR).
I wonder how feasible it would be to define a dialect where any non-zero struct
A* really points to a struct A... (we already have void* and char* for
untyped pointers)
gcc 4.9.2 cygwin64 internal error parsing decimal float point values
NOTE: I am not on neither of these mailing list so including me on any messages
which might require further information
The precompiled binary installed from the package manager labeled 4.9.2-1.
The following program reproduces:
-
int main()
{
float f = 1.17549435082228750797e-38F;
return f != 0x0.02P-126f;
}
init2.c:37: MPFR assertion failed: (32 - 0) == ((32 - 0)/8) * 8
sizeof(mp_limb_t) == ((32 - 0)/8)
test2.c: In function 'main':
test2.c:3:3: internal compiler error: Aborted
float f = 1.17549435082228750797e-38F;
^
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
For form sake: gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/4.9.2/lto-wrapper.exe
Target: x86_64-pc-cygwin
Configured with:
/cygdrive/i/szsz/tmpp/gcc/gcc-4.9.2-1.x86_64/src/gcc-4.9.2/configure
--srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-4.9.2-1.x86_64/src/gcc-4.9.2
--prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
--libexecdir=/usr/libexec --datadir=/usr/share --localstatedir=/var
--sysconfdir=/etc --libdir=/usr/lib --datarootdir=/usr/share
--docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C
--build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin
--without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib
--enable-shared --enable-shared-libgcc --enable-static
--enable-version-specific-runtime-libs --enable-bootstrap --enable-__cxa_atexit
--with-dwarf2 --with-tune=generic
--enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-graphite
--enable-threads=posix --enable-libatomic --enable-libgomp --disable-libitm
--enable-libquadmath --enable-libquadmath-support --enable-libssp
--enable-libada --enable-libgcj-sublibs --disable-java-awt --disable-symvers
--with-ecj-jar=/usr/share/java/ecj.jar --with-gnu-ld --with-gnu-as
--with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix
--without-libintl-prefix --with-system-zlib --enable-linker-build-id
Thread model: posix
gcc version 4.9.2 (GCC)
[Bug libstdc++/64638] [5 Regression] Build failure with recent futex changes in libstdc++, likely all non-gthreads targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64638 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-01-17 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |5.0 Summary|Build failure with recent |[5 Regression] Build |futex changes in libstdc++, |failure with recent futex |likely all non-gthreads |changes in libstdc++, |targets |likely all non-gthreads ||targets Ever confirmed|0 |1
[Bug libffi/64645] New: liibffi fails to build on cygwin-32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64645 Bug ID: 64645 Summary: liibffi fails to build on cygwin-32 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libffi Assignee: unassigned at gcc dot gnu.org Reporter: bernd.edlinger at hotmail dot de I used r219767: depbase=`echo src/x86/sysv.lo | sed 's|[^/]*$|.deps/|;s|\.lo$||'`;\ /bin/sh ./libtool --mode=compile /home/ED/gcc-build/./gcc/xgcc -B/home/ED/gcc-build/./gcc/ -B/home/ED/install/i686-pc-cygwin/bin/ -B/home/ED/install/i686-pc-cygwin/lib/ -isystem /home/ED/install/i686-pc-cygwin/include -isystem /home/ED/install/i686-pc-cygwin/sys-include-DHAVE_CONFIG_H -I. -I../../../gcc-r219767/libffi -I. -I../../../gcc-r219767/libffi/include -Iinclude -I../../../gcc-r219767/libffi/src -I. -I../../../gcc-r219767/libffi/include -Iinclude -I../../../gcc-r219767/libffi/src -g -O2 -MT src/x86/sysv.lo -MD -MP -MF $depbase.Tpo -c -o src/x86/sysv.lo ../../../gcc-r219767/libffi/src/x86/sysv.S \ mv -f $depbase.Tpo $depbase.Plo libtool: compile: /home/ED/gcc-build/./gcc/xgcc -B/home/ED/gcc-build/./gcc/ -B/home/ED/install/i686-pc-cygwin/bin/ -B/home/ED/install/i686-pc-cygwin/lib/ -isystem /home/ED/install/i686-pc-cygwin/include -isystem /home/ED/install/i686-pc-cygwin/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc-r219767/libffi -I. -I../../../gcc-r219767/libffi/include -Iinclude -I../../../gcc-r219767/libffi/src -I. -I../../../gcc-r219767/libffi/include -Iinclude -I../../../gcc-r219767/libffi/src -g -O2 -MT src/x86/sysv.lo -MD -MP -MF src/x86/.deps/sysv.Tpo -c ../../../gcc-r219767/libffi/src/x86/sysv.S -DDLL_EXPORT -DPIC -o src/x86/.libs/sysv.o ../../../gcc-r219767/libffi/src/x86/sysv.S: Assembler messages: ../../../gcc-r219767/libffi/src/x86/sysv.S:828: Error: junk at end of line, first unrecognized character is `,' Makefile:1177: recipe for target 'src/x86/sysv.lo' failed make[4]: *** [src/x86/sysv.lo] Error 1 make[4]: Leaving directory '/home/ED/gcc-build/i686-pc-cygwin/libffi' Makefile:1433: recipe for target 'all-recursive' failed make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory '/home/ED/gcc-build/i686-pc-cygwin/libffi' Makefile:465: recipe for target 'all' failed make[2]: *** [all] Error 2 make[2]: Leaving directory '/home/ED/gcc-build/i686-pc-cygwin/libffi' Makefile:20613: recipe for target 'all-target-libffi' failed make[1]: *** [all-target-libffi] Error 2 make[1]: Leaving directory '/home/ED/gcc-build' Makefile:906: recipe for target 'all' failed make: *** [all] Error 2
[Bug libstdc++/64638] [5 Regression] Build failure with recent futex changes in libstdc++, likely all non-gthreads targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64638 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Sat Jan 17 13:48:48 2015 New Revision: 219799 URL: https://gcc.gnu.org/viewcvs?rev=219799root=gccview=rev Log: PR libstdc++/64638 * include/bits/atomic_futex.h: Use appropriate config macros for availability of std::mutex, std::condition and std::chrono. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/atomic_futex.h
[Bug libstdc++/64638] [5 Regression] Build failure with recent futex changes in libstdc++, likely all non-gthreads targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64638 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Known to work||4.9.3 Version|unknown |5.0 Known to fail||5.0 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- It should be fixed now, but I'll leave this open until someone confirms the build works again.
[Bug ada/64640] Ada build failure on cygwin-32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64640 --- Comment #1 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Created attachment 34468 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34468action=edit possible fix
[Bug fortran/60922] [4.9/5 regression] Memory leak with INTENT(OUT) CLASS argument w/ allocatable CLASS components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60922
--- Comment #7 from janus at gcc dot gnu.org ---
Looking at the output of -fdump-tree-original for comment 6, one sees with 4.8:
d_vect_bld_x (struct __class_test_leak_D_vect_type restrict x)
{
if (x-_data-v._data != 0B)
{
__builtin_free ((void *) x-_data-v._data);
}
while trunk shows:
d_vect_bld_x (struct __class_test_leak_D_vect_type_t restrict x)
{
if (x-_vptr-_final != 0B)
{
{
struct array0_d_vect_type desc.7;
desc.7.dtype = 1064;
desc.7.data = (void * restrict) x-_data;
x-_vptr-_final (desc.7, x-_vptr-_size, 0);
}
}
That is: In 4.8 the argument x is directly freed when entering the function. On
trunk (after the implementation of finalization) the _final routine is called
instead. Apparently the latter fails to properly free the allocatable class
component.
[Bug fortran/60922] [4.9/5 regression] Memory leak with allocatable CLASS components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60922 janus at gcc dot gnu.org changed: What|Removed |Added Summary|[4.9/5 regression] Memory |[4.9/5 regression] Memory |leak with INTENT(OUT) CLASS |leak with allocatable CLASS |argument w/ allocatable |components |CLASS components| --- Comment #8 from janus at gcc dot gnu.org --- As comment 7 shows, the problem is not specific to intent(out) arguments but can occur also in other contexts where deallocation/finalization should occur. The following test case demonstrates the same leak with an auto-deallocated local variable (again leaks with 4.9 and trunk, but not 4.8): program test_leak implicit none type d_base_vect_type end type type d_vect_type class(d_base_vect_type), allocatable :: v end type call test() contains subroutine test() class(d_vect_type), allocatable :: x allocate(x) allocate(x%v) print *,allocated! end subroutine end
[Bug fortran/60922] [4.9/5 regression] Memory leak with allocatable CLASS components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60922
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #9 from janus at gcc dot gnu.org ---
Looking at the dump of the finalizer function (__final_test_leak_D_vect_type)
shows that it indeed has code to free the component v:
if (fini_coarray)
{
{
integer(kind=4) stat.5;
if (ptr-v._data == 0B)
{
stat.5 = 1;
}
else
{
if (ptr-v._vptr-_final != 0B)
{
{
struct array0_d_base_vect_type desc.6;
desc.6.dtype = 40;
desc.6.data = (void * restrict) ptr-v._data;
ptr-v._vptr-_final (desc.6, ptr-v._vptr-_size, 0);
}
}
__builtin_free ((void *) ptr-v._data);
stat.5 = 0;
}
However, it is guarded by the check for 'fini_coarray', which is the third
argument of the finalizer function and is being set to zero on invocation:
x._vptr-_final (desc.8, x._vptr-_size, 0);
The documentation of 'generate_finalization_wrapper' in class.c says:
If fini_coarray is false, coarray components are not finalized to allow for
the correct semantic with intrinsic assignment.
So I guess it should only apply to COARRAY components, not to CLASS components.
Tobias: I guess you were the one who implemented it. Could you please comment
on this?
Re: gcc 4.9.2 cygwin64 internal error parsing decimal float point values
On 1/17/2015 21:10, Marc Reynolds wrote:
NOTE: I am not on neither of these mailing list so including me on any
messages which might require further information
The precompiled binary installed from the package manager labeled 4.9.2-1.
The following program reproduces:
-
int main()
{
float f = 1.17549435082228750797e-38F;
return f != 0x0.02P-126f;
}
Works for me in all optimization levels, I guess it is something to do
with the compile options used.
signature.asc
Description: OpenPGP digital signature
[Bug libstdc++/64646] New: New overloads of std::is_permutation dereference past-the-end iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64646
Bug ID: 64646
Summary: New overloads of std::is_permutation dereference
past-the-end iterator
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
#include algorithm
#include forward_list
#include assert.h
int main()
{
std::forward_listint l1{0}, l2;
assert( !std::is_permutation(l1.begin(), l1.end(), l2.begin(), l2.end()) );
}
Aborts when compiled with -std=c++14 -D_GLIBCXX_DEBUG
There's a missing range check:
--- a/libstdc++-v3/include/bits/stl_algo.h
+++ b/libstdc++-v3/include/bits/stl_algo.h
@@ -3604,7 +3607,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
// Efficiently compare identical prefixes: O(N) if sequences
// have the same elements in the same order.
- for (; __first1 != __last1; ++__first1, ++__first2)
+ for (; __first1 != __last1 __first2 != __last2; ++__first1,
++__first2)
if (!__pred(__first1, __first2))
break;
[Bug libstdc++/64646] New overloads of std::is_permutation dereference past-the-end iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64646 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-17 Version|5.0 |4.9.3 Ever confirmed|0 |1 Known to fail||4.9.2, 5.0
