[Bug tree-optimization/63743] New: Thumb1: big regression for float operators by r216728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63743 Bug ID: 63743 Summary: Thumb1: big regression for float operators by r216728 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zhenqiang.chen at arm dot com Created attachment 33887 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33887action=edit test case Root cause: the fold_stmt swaps the operands, which leads to register shuffle. commit f619ecaed41d1487091098a0f4fdf4d6ed1fa379 Author: rguenth rguenth@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Mon Oct 27 11:30:23 2014 + 2014-10-27 Richard Biener rguent...@suse.de * tree-ssa-forwprop.c: Include tree-cfgcleanup.h and tree-into-ssa.h. (lattice): New global. (fwprop_ssa_val): New function. (fold_all_stmts): Likewise. (pass_forwprop::execute): Finally fold all stmts. * gcc.dg/tree-ssa/forwprop-6.c: Scan ccp1 dump instead. * gcc.dg/strlenopt-8.c: Adjust and XFAIL for non_strict_align target due to memcpy inline-expansion. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@216728 138bc75d-0d04-0410-961f-82ee72b054a4 A simplified case is attached. Options: -mthumb -Os -mcpu=cortex-m0 Before the patch, tree codes like _20 = _14 + _19; _21 = _20 * x_13; After the patch, tree codes like _20 = _14 + _19; _21 = x_13 * _20; Without HARD fpu support, all operators will be changed to function calls. The assemble codes change like: Before the patch, bl __aeabi_dadd ldr r2, [sp] ldr r3, [sp, #4] /* r0, r1 are reused from the return values of the previous call. */ bl __aeabi_dmul After the patch, bl __aeabi_dadd mov r2, r0 mov r3, r1 ldr r0, [sp] ldr r1, [sp, #4] bl __aeabi_dmul
[Bug tree-optimization/63743] Thumb1: big regression for float operators by r216728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63743 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Were we swapping operands before? I mean, if you rewrite the testcase to swap the * arguments in the source, did you get the same more efficient code in the past? In any case, this doesn't sound something that we should keep in mind in GIMPLE passes, + and * are just commutative, how they are expanded is a matter of expansion. So, either look for this during expansion (if a commutative operation is being expanded using libcall (or is this emitted by the backend?), see if one of the operands isn't result of immediately preceeding emitted call and if it is, perhaps swap the order of arguments), or add some register allocator smarts (add a way to mark library calls as commutative and allow RA to swap arguments to them if beneficial).
[Bug fortran/63744] New: Duplicate use-statement causes error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63744 Bug ID: 63744 Summary: Duplicate use-statement causes error Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: roger.ferrer at bsc dot es Hi, (I guess this is related to PR34657) The following snippet is accepted by gfortran -- test-ok.f90 MODULE MOO INTEGER :: S END MODULE MOO SUBROUTINE S1 USE MOO, ONLY: X = S, X = S X = 1 END SUBROUTINE S1 -- end of test-ok.f90 but it is rejected if the program unit SUBROUTINE S1 is renamed to SUBROUTINE S, as shown below -- test.f90 MODULE MOO INTEGER :: S END MODULE MOO SUBROUTINE S USE MOO, ONLY: X = S, X = S X = 1 END SUBROUTINE S -- end of test.f90 $ gfortran -c test.f90 test.f90:6.8: USE MOO, ONLY: X = S, X = S 1 Error: 's' of module 'moo', imported at (1), is also the name of the current program unit test.f90:8.5: X = 1 1 Error: Name 'x' at (1) is an ambiguous reference to 's' from module 'moo' Removing the second rename lets the code be accepted. USE MOO, ONLY: X = S A similar behaviour is observed if we have two repeated USE-statements rather than two repeated rename's in the rename-list USE MOO, ONLY: X = S USE MOO, ONLY: X = S Kind regards,
[Bug ipa/63745] New: [4.9/5 Regression] mythtv build failure due to aggressive speculative devirtualization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63745
Bug ID: 63745
Summary: [4.9/5 Regression] mythtv build failure due to
aggressive speculative devirtualization
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org
With the attached unreduced testcase I get:
markus@x4 /tmp % g++ -flto -O2 foo.ii 21 | grep
VideoBuffers::StartDisplayingFrame
markus@x4 /tmp % g++ -fno-devirtualize-speculatively -O2 foo.ii 21 | grep
VideoBuffers::StartDisplayingFrame
markus@x4 /tmp % g++ -O2 foo.ii 21 | grep
VideoBuffers::StartDisplayingFrame
/tmp/ccEenHoO.o:main.cpp:function VideoOutput::StartDisplayingFrame(): error:
undefined reference to 'VideoBuffers::StartDisplayingFrame()'
/tmp/ccEenHoO.o:main.cpp:function VideoPerformanceTest::Test(): error:
undefined reference to 'VideoBuffers::StartDisplayingFrame()'
Creduce came up with the following (invalid) testcase:
% cat main.ii
struct VideoBuffers
{
void StartDisplayingFrame ();
};
struct B
{
VideoBuffers vbuffers;
virtual void
StartDisplay ()
{
vbuffers.StartDisplayingFrame ();
}
};
struct VideoPerformanceTest
{
B *Test_vo;
void
Test ()
{
while (1)
Test_vo-StartDisplay ();
}
};
% g++ -fno-devirtualize-speculatively -O2 -Wl,--no-undefined main.ii
% g++ -flto -O2 -Wl,--no-undefined main.ii
% g++ -O2 -Wl,--no-undefined main.ii
/tmp/ccTlyhda.o:main.ii:function B::StartDisplay(): error: undefined reference
to 'VideoBuffers::StartDisplayingFrame()'
/tmp/ccTlyhda.o:main.ii:function main: error: undefined reference to
'VideoBuffers::StartDisplayingFrame()'
[Bug ipa/63745] [4.9/5 Regression] mythtv build failure due to aggressive speculative devirtualization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63745 --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Created attachment 33888 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33888action=edit unreduced testcase
[Bug ipa/63745] [4.9/5 Regression] mythtv build failure due to aggressive speculative devirtualization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63745
--- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
Sorry reduced testcase was cut off. Here it is in its full glory:
struct VideoBuffers
{
void StartDisplayingFrame ();
};
struct B
{
VideoBuffers vbuffers;
virtual void
StartDisplay ()
{
vbuffers.StartDisplayingFrame ();
}
};
struct VideoPerformanceTest
{
B *Test_vo;
void
Test ()
{
while (1)
Test_vo-StartDisplay ();
}
};
VideoPerformanceTest a;
int
main () { a.Test (); }
[Bug libstdc++/63746] New: i/o fragmentation inside basic_filebuf::xsputn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63746
Bug ID: 63746
Summary: i/o fragmentation inside basic_filebuf::xsputn
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: pluto at agmk dot net
Hi,
i'm trying to minimize small i/o operations for better overal
application perfromance over networked filesystems.
setting quite large stream buffer doesn't work as axpected
in some cases.
#include iostream
#include fstream
#include memory
#include sstream
#include string
int main()
{
std::size_t bufferSize = 1024*1024;
std::unique_ptr char buffer( new char[ bufferSize ] );
std::ofstream f;
f.rdbuf()-pubsetbuf( buffer.get(), bufferSize );
f.open( s.txt, std::ios_base::out | std::ios_base::binary );
std::stringstream ss;
std::string s1( 10240, 'x' );
ss.str( std::string() );
ss s1;
f ss.rdbuf();
ss.str( std::string() );
ss s1;
f ss.rdbuf();
f.close();
}
% g++ s.cpp -o s -Wall -g2 -std=c++11
% LANG=C strace ./s
(...)
open(s.txt, O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
writev(3, [{NULL, 0}, {..., 8136}], 2) = 8136
writev(3, [{, 0}, {..., 2104}], 2) = 2104
writev(3, [{, 0}, {..., 10240}], 2) = 10240
close(3)
i've expected that 20kB i/o from testcase will fit in the 1MB buffer
but the fstream.tcc contains magic const __chunk = 1k and logic that
not use the buffer in the optimal way.
[Bug rtl-optimization/63620] RELOAD lost SET_GOT dependency on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620 --- Comment #26 from Uroš Bizjak ubizjak at gmail dot com --- PR 63527 is probably related to this issue.
[Bug target/63679] [5.0 Regression][AArch64] Failure to constant fold.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679 --- Comment #5 from Tejas Belagod belagod at gcc dot gnu.org --- Index: passes.def === --- passes.def (revision 217035) +++ passes.def (working copy) @@ -255,7 +255,7 @@ NEXT_PASS (pass_reassoc); NEXT_PASS (pass_strength_reduction); NEXT_PASS (pass_tracer); - NEXT_PASS (pass_dominator); + NEXT_PASS (pass_fre); NEXT_PASS (pass_strlen); NEXT_PASS (pass_vrp); /* The only const/copy propagation opportunities left after ? Thanks. Still no luck :-(. Will keep digging.
[Bug tree-optimization/63743] Thumb1: big regression for float operators by r216728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63743
--- Comment #2 from Zhenqiang Chen zhenqiang.chen at arm dot com ---
(In reply to Jakub Jelinek from comment #1)
Were we swapping operands before? I mean, if you rewrite the testcase to
swap the * arguments in the source, did you get the same more efficient code
in the past?
Yes. I tried the test case:
double
test1 (double x, double y)
{
return x * (x + y);
}
double
test2 (double x, double y)
{
return (x + y) * x;
}
Without r216728, I got efficient codes for both functions. But with r216728, I
got inefficient codes for both functions.
[Bug tree-optimization/63747] New: [5 regression] icf mis-compares switch gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63747 Bug ID: 63747 Summary: [5 regression] icf mis-compares switch gimple Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: joey.ye at arm dot com ARM -Os bootstrap breaks. Root cause lies in ipa-icf-gimple.c where compare_gimple_switch doesn't compare case numbers correctly. Will upload a reduced test case soon.
[Bug ipa/63745] [4.9/5 Regression] mythtv build failure due to aggressive speculative devirtualization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63745
--- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
And here's a hopefully valid testcase:
markus@x4 tmp % cat main.ii
struct VideoBuffers
{
void StartDisplayingFrame ();
};
struct B
{
VideoBuffers vbuffers;
virtual void
StartDisplay ()
{
vbuffers.StartDisplayingFrame ();
}
};
struct VideoPerformanceTest
{
B *Test_vo;
void
Test ()
{
if (!Test_vo)
return;
while (1)
Test_vo-StartDisplay ();
}
};
VideoPerformanceTest a;
int
main () { a.Test (); }
[Bug tree-optimization/63743] Thumb1: big regression for float operators by r216728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63743
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Zhenqiang Chen from comment #2)
(In reply to Jakub Jelinek from comment #1)
Were we swapping operands before? I mean, if you rewrite the testcase to
swap the * arguments in the source, did you get the same more efficient code
in the past?
Yes. I tried the test case:
double
test1 (double x, double y)
{
return x * (x + y);
}
double
test2 (double x, double y)
{
return (x + y) * x;
}
Without r216728, I got efficient codes for both functions. But with r216728,
I got inefficient codes for both functions.
What about
double
test3 (double x, double y)
{
return (x + y) * (x - y);
}
? At least from quick looking at ppc -msoft-float -O2 -m32, I see the same
issue there, add called first, sub called second, and result of second returned
in the same registers as used for the first argument. So something to handle at
expansion or RA rather than in GIMPLE anyway IMHO.
[Bug tree-optimization/63721] [5 Regression] IPA ICF cause atomic-comp-swap-release-acquire.c ICE on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63721
Jiong Wang jiwang at gcc dot gnu.org changed:
What|Removed |Added
Target||arm-*-*, x86-64-*-*
--- Comment #1 from Jiong Wang jiwang at gcc dot gnu.org ---
the same ICE will happen on x86-64, if compile with -O2 -fPIC.
the reason is for the following two functions, they are identical, so IPA-ICF
pass try to transform the second function to call the first one directly.
int
atomic_compare_exchange_STRONG_RELEASE_ACQUIRE (int a, int b)
{
return __atomic_compare_exchange (v, a, b,
STRONG, __ATOMIC_RELEASE,
__ATOMIC_ACQUIRE);
}
int
atomic_compare_exchange_n_STRONG_RELEASE_ACQUIRE (int a, int b)
{
return __atomic_compare_exchange_n (v, a, b,
STRONG, __ATOMIC_RELEASE,
__ATOMIC_ACQUIRE);
}
while during this transformation, looks like there are something wrong with the
function argument handling. take a for example, because later there are a,
so it's marked as addressable. while after transformation, if we turn the
second function into
int atomic_compare_exchange_n_STRONG_RELEASE_ACQUIRE (int a, int b)
{
return atomic_compare_exchange_STRONG_RELEASE_ACQUIRE (a, b)
}
then argument a is no longer addressable.
so, in cgraph_node::release_body, when making the wrapper, except clearing the
function body, we should also clear the addressable flag for function args
because they are decided by the function body which is cleared.
I have a local patch under testing.
[Bug bootstrap/63740] [4.9 Regression] GCC 4.9.2 bootstrap fails on ARM, haifa-sched.c:6507:1: internal compiler error: in lra_create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63740 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #3 from ktkachov at gcc dot gnu.org --- (In reply to Aaro Koskinen from comment #2) Created attachment 33885 [details] haifa-sched preprocessed source This is the preprocessed source of haifa-sched produced with full original xg++ command line with -E added. I had to compress it as the plain/text version exceeded the 1000 KB attachment limit. I'm getting a whole bunch of frontend errors (and it seems that the .i file is actually another .gz file that needs to be uncompressed again?) Could you please produce the preprocessed output by adding -save-temps to the command line?
[Bug tree-optimization/63743] Thumb1: big regression for float operators by r216728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63743
--- Comment #4 from Zhenqiang Chen zhenqiang.chen at arm dot com ---
(In reply to Jakub Jelinek from comment #3)
(In reply to Zhenqiang Chen from comment #2)
(In reply to Jakub Jelinek from comment #1)
Were we swapping operands before? I mean, if you rewrite the testcase to
swap the * arguments in the source, did you get the same more efficient
code
in the past?
Yes. I tried the test case:
double
test1 (double x, double y)
{
return x * (x + y);
}
double
test2 (double x, double y)
{
return (x + y) * x;
}
Without r216728, I got efficient codes for both functions. But with r216728,
I got inefficient codes for both functions.
What about
double
test3 (double x, double y)
{
return (x + y) * (x - y);
}
? At least from quick looking at ppc -msoft-float -O2 -m32, I see the same
issue there, add called first, sub called second, and result of second
returned in the same registers as used for the first argument. So something
to handle at expansion or RA rather than in GIMPLE anyway IMHO.
Same issue for the case on Thumb1.
[Bug bootstrap/63740] [4.9 Regression] GCC 4.9.2 bootstrap fails on ARM, haifa-sched.c:6507:1: internal compiler error: in lra_create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63740 Aaro Koskinen aaro.koskinen at iki dot fi changed: What|Removed |Added Attachment #33885|0 |1 is obsolete|| --- Comment #4 from Aaro Koskinen aaro.koskinen at iki dot fi --- Created attachment 33889 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33889action=edit haifa-sched.ii.gz haifa-sched.ii (gzipped) from -save-temps.
[Bug bootstrap/63740] [4.9 Regression] GCC 4.9.2 bootstrap fails on ARM, haifa-sched.c:6507:1: internal compiler error: in lra_create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63740 --- Comment #5 from Aaro Koskinen aaro.koskinen at iki dot fi --- Created attachment 33890 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33890action=edit haifa-sched.s.gz haifa-sched.s (gzipped) from -save-temps.
[Bug fortran/47007] Values from namelist file should not depend on locale settings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added URL||https://gcc.gnu.org/ml/gcc- ||patches/2014-11/msg00277.ht ||ml --- Comment #23 from Janne Blomqvist jb at gcc dot gnu.org --- Patch at https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00277.html
[Bug fortran/61847] bug in gfortran runtime: digits cut off when reading floating point number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added URL||https://gcc.gnu.org/ml/gcc- ||patches/2014-11/msg00277.ht ||ml --- Comment #23 from Janne Blomqvist jb at gcc dot gnu.org --- Patch using POSIX 2008 functionality at https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00277.html
[Bug tree-optimization/63747] [5 regression] icf mis-compares switch gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63747 thopre01 at gcc dot gnu.org changed: What|Removed |Added CC||thopre01 at gcc dot gnu.org --- Comment #1 from thopre01 at gcc dot gnu.org --- The description of the problem you make seems to point to commit r216913.
[Bug tree-optimization/63721] [5 Regression] IPA ICF cause atomic-comp-swap-release-acquire.c ICE on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63721 thopre01 at gcc dot gnu.org changed: What|Removed |Added CC||thopre01 at gcc dot gnu.org --- Comment #2 from thopre01 at gcc dot gnu.org --- Shouldn't this be merged with PR63747?
[Bug tree-optimization/63721] [5 Regression] IPA ICF cause atomic-comp-swap-release-acquire.c ICE on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63721 --- Comment #3 from Jiong Wang jiwang at gcc dot gnu.org --- (In reply to thopre01 from comment #2) Shouldn't this be merged with PR63747? not sure, but looks like they are not the same issue. this failure happen on x86-64 also, and may happen on any target.
[Bug c/59708] clang-compatible checked arithmetic builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59708
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Attachment #33855|0 |1
is obsolete||
--- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org ---
Created attachment 33891
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33891action=edit
gcc5-pr59708-wip2.patch
Updated patch, this time __builtin_umul{,l,ll}_overflow should work fully, and
with the exception of widest type ({,un}signed __int128 on targets that do
support that, {,un}signed long long otherwise) also the type-generic variants.
What is still unhandled is in the widest type signed +- signed - unsigned,
unsigned +- unsigned - signed and mixed sign (either between operands, or
between operand and result) multiplication in the widest type.
[Bug rtl-optimization/63475] Postreload CSE propagates aliased memory operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63475 --- Comment #7 from uros at gcc dot gnu.org --- Author: uros Date: Wed Nov 5 12:02:17 2014 New Revision: 217119 URL: https://gcc.gnu.org/viewcvs?rev=217119root=gccview=rev Log: Backport from mainline: 2014-10-20 Uros Bizjak ubiz...@gmail.com * varasm.c (const_alias_set): Remove. (init_varasm_once): Remove initialization of const_alias_set. (build_constant_desc): Do not set alias set to const_alias_set. Backport from mainline: 2014-10-14 Uros Bizjak ubiz...@gmail.com PR rtl-optimization/63475 * alias.c (true_dependence_1): Always use get_addr to extract true address operands from x_addr and mem_addr. Use extracted address operands to check for references with alignment ANDs. Use extracted address operands with find_base_term and base_alias_check. For noncanonicalized operands call canon_rtx with extracted address operand. (write_dependence_1): Ditto. (may_alias_p): Ditto. Remove unused calls to canon_rtx. Backport from mainline: 2014-10-10 Uros Bizjak ubiz...@gmail.com PR rtl-optimization/63483 * alias.c (true_dependence_1): Do not exit early for MEM_READONLY_P references when alignment ANDs are involved. (write_dependence_p): Ditto. (may_alias_p): Ditto. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/alias.c branches/gcc-4_9-branch/gcc/varasm.c
[Bug target/63483] Scheduler performs Invalid move of aliased memory reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483 --- Comment #21 from uros at gcc dot gnu.org --- Author: uros Date: Wed Nov 5 12:02:17 2014 New Revision: 217119 URL: https://gcc.gnu.org/viewcvs?rev=217119root=gccview=rev Log: Backport from mainline: 2014-10-20 Uros Bizjak ubiz...@gmail.com * varasm.c (const_alias_set): Remove. (init_varasm_once): Remove initialization of const_alias_set. (build_constant_desc): Do not set alias set to const_alias_set. Backport from mainline: 2014-10-14 Uros Bizjak ubiz...@gmail.com PR rtl-optimization/63475 * alias.c (true_dependence_1): Always use get_addr to extract true address operands from x_addr and mem_addr. Use extracted address operands to check for references with alignment ANDs. Use extracted address operands with find_base_term and base_alias_check. For noncanonicalized operands call canon_rtx with extracted address operand. (write_dependence_1): Ditto. (may_alias_p): Ditto. Remove unused calls to canon_rtx. Backport from mainline: 2014-10-10 Uros Bizjak ubiz...@gmail.com PR rtl-optimization/63483 * alias.c (true_dependence_1): Do not exit early for MEM_READONLY_P references when alignment ANDs are involved. (write_dependence_p): Ditto. (may_alias_p): Ditto. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/alias.c branches/gcc-4_9-branch/gcc/varasm.c
[Bug target/63483] Scheduler performs Invalid move of aliased memory reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.3 --- Comment #22 from Uroš Bizjak ubizjak at gmail dot com --- Fixed for 4.9+.
[Bug rtl-optimization/63475] Postreload CSE propagates aliased memory operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63475 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|5.0 |4.9.3 --- Comment #8 from Uroš Bizjak ubizjak at gmail dot com --- Fixed for 4.9.3+.
[Bug tree-optimization/63747] [5 regression] icf mis-compares switch gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63747 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||arm Host||arm Target Milestone|--- |5.0 Build||arm
[Bug ipa/63745] [4.9/5 Regression] mythtv build failure due to aggressive speculative devirtualization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63745 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |4.9.3
[Bug tree-optimization/63743] Thumb1: big regression for float operators by r216728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63743
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #5 from Richard Biener rguenth at gcc dot gnu.org ---
This is just operand canonicalization according to tree_swap_operands which is
now consistently applied. It was a bug that it wasn't applied before (the
usual offender here is SSA rewriting that doesn't fold changed statements
nor re-canonicalizes).
You are just (un)lucky btw, try both
double
test1 (double x, double y)
{
double tem = x + y;
double tem2 = x;
return tem2 * tem;
}
and
double
test1 (double x, double y)
{
double tem = x + y;
double tem2 = x;
return tem * tem2;
}
there is nothing that forces ordering in the way you would prefer it. So as
Jakub says - this needs addressing in RTL expansion and/or TER and SSA
coalescing.
[Bug tree-optimization/61515] [4.9/5 Regression] Extremely long compile time for generated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61515 --- Comment #24 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Jeffrey A. Law from comment #23) The piece you're missing in this is that when we seen an assignment to some SSA_NAME, call it LHS and we've traversed a backedge, then we have to walk through all the equivalences and see if there's anything that's been marked as equivalent to LHS and invalidate those. Then we also ahve to invalidate LHS. for (unsigned int i = 1; i num_ssa_names; i++) if (ssa_name (i) SSA_NAME_VALUE (ssa_name (i)) == lhs) record_temporary_equivalence (ssa_name (i), NULL_TREE, stack); if (SSA_NAME_VALUE (lhs)) record_temporary_equivalence (lhs, NULL_TREE, stack); The loop finds handles things equivalent to LHS, the second handles LHS itself. Both are required for correctness. In the past there was a map similar to your implementation, but it's not sufficient. See pr61289.C and pr61289-2.C. The problem is you may need to invalidate equivalences that are created *outside* tree-ssa-threadedge.c. So any attempts to track inside tree-ssa-threadedge are not sufficient for correctness. What's still not clear to me here is *why* we're calling the invalidation code in the first place. It's only supposed to be called when we encounter a statement which produces an output that we can't handle *and* we've traversed a backedge. The combination of those two events is supposed to be very rare. Otherwise the invalidation is obviously too expensive. That's why I suggested in c#12 that we need to look at *why* we're calling the invalidation code at all. Well, I don't know the code at all so I can just try to fix the complexity in the present algorithm. Please have a look here during stage3.
[Bug bootstrap/63740] [4.9 Regression] GCC 4.9.2 bootstrap fails on ARM, haifa-sched.c:6507:1: internal compiler error: in lra_create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63740 --- Comment #6 from Aaro Koskinen aaro.koskinen at iki dot fi --- (In reply to Aaro Koskinen from comment #0) GCC 4.9.2 native bootstrap on ARM fails with ICE from the second stage compiler: /home/aaro/gcctest/build/./prev-gcc/xg++ Correction: stage_curr says stage2 after the failure. So the error is coming from a compiler built in stage1.
[Bug tree-optimization/63748] New: may be used uninitialized warning on variable definition with initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63748 Bug ID: 63748 Summary: may be used uninitialized warning on variable definition with initializer Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: amodra at gmail dot com Created attachment 33892 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33892action=edit preprocessed source Found when compiling gdb's eval.c using gcc-4.9.1 or current trunk, x86_64-linux or powerpc64-linux. /src/binutils-gdb/gdb/eval.c: In function ‘evaluate_subexp_standard’: /src/binutils-gdb/gdb/eval.c:745:16: error: ‘ret’ may be used uninitialized in this function [-Werror=maybe-uninitialized] struct value *ret = NULL; ^ More bogus warnings follow with -O -Wall on the attached preprocessed source.
[Bug debug/61033] [4.8/4.9 Regression] Infinite loop in variable tracking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61033 --- Comment #10 from Maxim Kuvyrkov mkuvyrkov at gcc dot gnu.org --- Michael, What is the status of this bug? Thanks.
[Bug tree-optimization/63748] [4.9/5 Regression] may be used uninitialized warning on variable definition with initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63748 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-05 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |4.9.3 Summary|may be used uninitialized |[4.9/5 Regression] may be |warning on variable |used uninitialized warning |definition with initializer |on variable definition with ||initializer Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug target/57792] toplevel configure should enable --with-sysroot=`xcrun --show-sdk-path` for darwin13 and later
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792 --- Comment #13 from howarth at bromo dot med.uc.edu --- Yes, I am pretty sure Apple has abandoned this for good. They only attempted the change because it was assumed to be completely transparent as the compiler looks in /usr/include by default. It wasn't appreciated that this would cause... radr://14320107 /usr/bin/python reports back include directories that are unpopulated where removal of /usr/include caused the system Python.h to point to an unpopulated header directory in INCLUDEPY. While I provided them with a patch to sysconfig.py to solve this, there is no stomach at Apple for pushing such changes upstream as other packages like perl that hardcode compiler options will need to be modified as well. While we could add this change to FSF gcc, I don't think we want to encourage users not to install the system headers in /usr/include via the Command Line Tools of Xcode as there are other configure scripts out there which will also need to be patched to find /usr/include with `xcrun --show-sdk-path`. If we made any change, I would rather it be a check in FSF gcc's configure for the presence of /usr/include on darwin which provided the appropriate error message to the user that the Command Line Tools needs to be installed.
[Bug ipa/63745] [4.9/5 Regression] mythtv build failure due to aggressive speculative devirtualization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63745
--- Comment #4 from Jan Hubicka hubicka at ucw dot cz ---
struct VideoBuffers
{
void StartDisplayingFrame ();
};
struct B
{
VideoBuffers vbuffers;
virtual void
StartDisplay ()
{
vbuffers.StartDisplayingFrame ();
}
So we devirtualize to StartDisplay but that leads to linker failure because
StartDisplayingFrame is not linked with the object file.
I think this is similar to some earlier testcases we run across in libreoffice
and we managed to declare it invalid - if you provide inline function body you
need to link the unit with symbols it uses.
Honza
[Bug ipa/63745] [4.9/5 Regression] mythtv build failure due to aggressive speculative devirtualization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63745
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #5 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #4)
struct VideoBuffers
{
void StartDisplayingFrame ();
};
struct B
{
VideoBuffers vbuffers;
virtual void
StartDisplay ()
{
vbuffers.StartDisplayingFrame ();
}
So we devirtualize to StartDisplay but that leads to linker failure because
StartDisplayingFrame is not linked with the object file.
I think this is similar to some earlier testcases we run across in
libreoffice
and we managed to declare it invalid - if you provide inline function body
you
need to link the unit with symbols it uses.
OK. That was my fist reaction, too.
But it is irritating that it succeeds with -flto.
[Bug libstdc++/63746] i/o fragmentation inside basic_filebuf::xsputn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63746 --- Comment #1 from Pawel Sikora pluto at agmk dot net --- Created attachment 33893 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33893action=edit my hack.
[Bug go/63269] libgo/math test failures in TestLog2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63269
--- Comment #4 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
regarding 2)
I'm not entirely persuaded by your argument for item 2. ...
Hm, good that you doubted it, because the actual mistake is somehwere else:
The unpatched code has
if l != float64(i)
but if you want to use a tolerance here this must become
if !veryclose(float64(i), l) {
With the argument reversed. This could/should be cleaned up by renaming the
arguments of the tolerance() function, e.g. a - expected, b - result, e -
maxerr.
Zero is a special
value. When we expect a zero, we should get a zero, not something close to
zero. I don't think this change is correct in general. It may be correct for
some specific cases, but then we need to investigate those.
Actually, this has nothing to do with 0 being special here, abut with scaling
of the allowed error: Multiplying it by 0 yields zero error tolerance, so the
tolerance() function does not do that.
-- This chunk is not necessary, but a (separate) cleanup patch might help to
avoid future confusion.
[Bug debug/63741] lm32 ICE in dwarf2out_frame_debug_expr, at dwarf2cfi.c:1677
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63741 --- Comment #2 from Joel Sherrill joel at gcc dot gnu.org --- Broken on head as well. lm32-rtems4.11-gcc (GCC) 5.0.0 20141104 (experimental)
[Bug tree-optimization/25290] PHI-OPT could be rewritten so that is uses fold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25290 --- Comment #7 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #5) Maybe not fold but rather what I am working on, gimple_combine. Rather now gimple_simplify (which is from the match-and-simplify branch).
[Bug target/63749] New: [4.9/5 Regression] registers may not be the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63749 Bug ID: 63749 Summary: [4.9/5 Regression] registers may not be the same Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Created attachment 33894 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33894action=edit test case seen with current 4.9 branch and trunk on arm-linux-gnueabihf $ gcc-4.8 -O2 -c reg.c $ gcc -O2 -c reg.c /tmp/ccQvkuYw.s: Assembler messages: /tmp/ccQvkuYw.s:106: Error: registers may not be the same -- `str r2,[r2],#4' $ gcc -O1 -fexpensive-optimizations -fschedule-insns -c reg.c /tmp/ccy5nxu8.s: Assembler messages: /tmp/ccy5nxu8.s:81: Error: registers may not be the same -- `str r2,[r2],#4'
[Bug fortran/63640] move_alloc memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63640 patnel97269-gfortran at yahoo dot fr changed: What|Removed |Added Severity|critical|normal
[Bug tree-optimization/61110] Simplify value_replacement in phiopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61110 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Depends on||25290 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- I think some of this should really be moved to match.pd and phi-opt use it instead.
[Bug bootstrap/63750] New: use of undeclared identifier 'do_not_use_isalnum_with_safe_ctype'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63750 Bug ID: 63750 Summary: use of undeclared identifier 'do_not_use_isalnum_with_safe_ctype' Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: howarth at bromo dot med.uc.edu The bootstrap on x86_64-apple-darwin14 at r217129. now fails to compile under Clang 6.0 with the errors... g++ -c -g -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc-5.0-20141105/gcc -I../../gcc-5.0-20141105/gcc/. -I../../gcc-5.0-20141105/gcc/../include -I../../gcc-5.0-20141105/gcc/../libcpp/include -I/sw/include -I/sw/include -I../../gcc-5.0-20141105/gcc/../libdecnumber -I../../gcc-5.0-20141105/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc-5.0-20141105/gcc/../libbacktrace -DCLOOG_INT_GMP -I/sw/include -DCLOOG_INT_GMP -I/sw/include -I/sw/include -o ipa-chkp.o -MT ipa-chkp.o -MMD -MP -MF ./.deps/ipa-chkp.TPo ../../gcc-5.0-20141105/gcc/ipa-chkp.c clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated In file included from ../../gcc-5.0-20141105/gcc/ipa-chkp.c:23: ../../gcc-5.0-20141105/gcc/coretypes.h:62:1: warning: class 'rtx_def' was previously declared as a struct [-Wmismatched-tags] class rtx_def; ^ ../../gcc-5.0-20141105/gcc/coretypes.h:55:8: note: previous use is here struct rtx_def; ^ In file included from ../../gcc-5.0-20141105/gcc/ipa-chkp.c:24: In file included from ../../gcc-5.0-20141105/gcc/tree-core.h:24: In file included from ../../gcc-5.0-20141105/gcc/hash-set.h:24: In file included from ../../gcc-5.0-20141105/gcc/hash-table.h:200: ../../gcc-5.0-20141105/gcc/ggc.h:315:15: warning: struct 'rtx_def' was previously declared as a class [-Wmismatched-tags] static inline struct rtx_def * ^ ../../gcc-5.0-20141105/gcc/coretypes.h:62:7: note: previous use is here class rtx_def; ^ In file included from ../../gcc-5.0-20141105/gcc/ipa-chkp.c:24: In file included from ../../gcc-5.0-20141105/gcc/tree-core.h:24: In file included from ../../gcc-5.0-20141105/gcc/hash-set.h:24: In file included from ../../gcc-5.0-20141105/gcc/hash-table.h:200: ../../gcc-5.0-20141105/gcc/ggc.h:318:11: warning: struct 'rtx_def' was previously declared as a class [-Wmismatched-tags] return (struct rtx_def *) ggc_internal_alloc (s PASS_MEM_STAT); ^ ../../gcc-5.0-20141105/gcc/coretypes.h:62:7: note: previous use is here class rtx_def; ^ In file included from ../../gcc-5.0-20141105/gcc/ipa-chkp.c:24: In file included from ../../gcc-5.0-20141105/gcc/tree-core.h:29: In file included from ../../gcc-5.0-20141105/gcc/double-int.h:23: ../../gcc-5.0-20141105/gcc/wide-int.h:370:3: warning: extraneous template parameter list in template specialization template ^~~ ../../gcc-5.0-20141105/gcc/wide-int.h:377:3: warning: extraneous template parameter list in template specialization template ^~~ ../../gcc-5.0-20141105/gcc/wide-int.h:384:3: warning: extraneous template parameter list in template specialization template ^~~ ../../gcc-5.0-20141105/gcc/wide-int.h:394:3: warning: extraneous template parameter list in template specialization template ^~~ ../../gcc-5.0-20141105/gcc/wide-int.h:401:3: warning: extraneous template parameter list in template specialization template ^~~ ../../gcc-5.0-20141105/gcc/wide-int.h:411:3: warning: extraneous template parameter list in template specialization template ^~~ ../../gcc-5.0-20141105/gcc/wide-int.h:422:3: warning: extraneous template parameter list in template specialization template ^~~ ../../gcc-5.0-20141105/gcc/wide-int.h:886:3: warning: extraneous template parameter list in template specialization template ^~~ ../../gcc-5.0-20141105/gcc/wide-int.h:965:3: warning: extraneous template parameter list in template specialization template ^~~ ../../gcc-5.0-20141105/gcc/wide-int.h:1127:1: warning: 'fixed_wide_int_storage' defined as a class template here but previously declared as a struct template [-Wmismatched-tags] class GTY(()) fixed_wide_int_storage ^ ../../gcc-5.0-20141105/gcc/wide-int.h:286:18: note: did you mean class here? template int N struct fixed_wide_int_storage; ^~ class ../../gcc-5.0-20141105/gcc/wide-int.h:1152:3: warning: extraneous template parameter list in template specialization template ^~~ In file included from ../../gcc-5.0-20141105/gcc/ipa-chkp.c:39: ../../gcc-5.0-20141105/gcc/ipa-ref.h:26:1: warning: class 'symtab_node' was previously
[Bug bootstrap/63750] use of undeclared identifier 'do_not_use_isalnum_with_safe_ctype'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63750 --- Comment #1 from howarth at bromo dot med.uc.edu --- Bootstrap attempted with... ../gcc-5.0-20141105/configure --prefix=/sw --prefix=/sw/lib/gcc5.0 --mandir=/sw/share/man --infodir=/sw/lib/gcc5.0/info --enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-isl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-5.0
[Bug other/60040] AVR: error: unable to find a register to spill in class 'POINTER_REGS'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60040 Joel Sherrill joel at gcc dot gnu.org changed: What|Removed |Added CC||joel at gcc dot gnu.org --- Comment #7 from Joel Sherrill joel at gcc dot gnu.org --- Was the proposed patch ever committed so this can be closed?
[Bug preprocessor/9449] UCNs not recognized in identifiers (c++/c99)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9449 --- Comment #47 from Joseph S. Myers jsm28 at gcc dot gnu.org --- Author: jsm28 Date: Wed Nov 5 16:19:10 2014 New Revision: 217144 URL: https://gcc.gnu.org/viewcvs?rev=217144root=gccview=rev Log: Enable -fextended-identifiers by default. As proposed at https://gcc.gnu.org/ml/gcc/2014-11/msg00014.html, this patch enables -fextended-identifiers by default for all standard versions including this feature (all C++ versions, C99 and above for C, but not C90 / C94 / gnu89 / preprocessing assembler). It adds a couple of tests for areas where I previously noted testsuite coverage for extended identifiers was lacking, removes -fextended-identifiers from existing tests, adds -g to various such tests to verify that extended identifiers don't break debug info generation and removes the test that was only there to verify that the feature was off by default. The current state of the feature may not correspond exactly to any particular checklist from 2004/5 (see bug 9449) of what was wanted before enabling the feature by default, but I don't think it's any worse than plenty of other features supported by default before every corner case is fully functional, and think problems can readily be fixed incrementally. The following aspects of extended identifiers could still do with more work (and should be straightforward): * C -aux-info (output should use UCNs). * ObjC -gen-decls (output should use UCNs; associated diagnostics from the ObjC front end should use extended characters or UCNs as appropriate to the locale, via using %qE or identifier_to_locale). * Use DW_AT_use_UTF8 in DWARF-3 debug info for compilation units built with extended identifiers enabled (or unconditionally). * cpplib diagnostics (outputting characters or UCNs as appropriate depending on the locale, as done for identifiers in non-cpplib diagnostics). * C++ test for UCN linking with C and extern C. * Check GDB support / file issues for support if needed. * Actual UTF-8 in identifiers (?). (Be careful about not affecting performance for the normal fast path of lexing identifiers, if possible.) The following may be trickier: * cpplib spelling preservation (required to diagnose macro redefinition with different spellings of the same identifier in the definition or argument names; different spellings of the name of the macro itself are OK, however; also required for correct handling of multiple stringizing in C++); correct output for -d (UCNs), DWARF debug info for macros (UCNs), PCH and PCH tests. (Spelling preservation is the issue that needs fixing to remove references to corner cases in the documentation of -std=c99 and -std=c11 and in c99status.html.) The idea would be to add a second pointer to cpp_identifier that stores the original spelling (whether for extended identifiers only, or for all identifiers); this does not enlarge cpp_token because the resulting larger cpp_identifier structure is no bigger than cpp_string. * C++ translation of extended characters (including $@` and various control characters) to UCNs in phase 1 (note diagnostics thus needed, but not for C++11, for control characters in strings / character constants as those UCNs invalid); a likely implementation approach is to do translation when identifiers / strings / character constants are lexed, together with errors for stray $@` / control characters in program as not being valid UCNs in identifiers ($ only if not accepted in identifiers); note that this translation should not take place inside raw string literals. Bootstrapped with no regressions on x86_64-unknown-linux-gnu. libcpp: PR preprocessor/9449 * init.c (lang_defaults): Enable extended identifiers for C++ and C99-based standards. gcc: PR preprocessor/9449 * doc/cpp.texi (Character sets, Tokenization) (Implementation-defined behavior): Don't refer to UCNs in identifiers requiring -fextended-identifiers. * doc/cppopts.texi (-fextended-identifiers): Document as enabled by default for C99 and later and C++. * doc/invoke.texi (-std=c99, -std=c11): Don't refer to extended identifiers needing -fextended-identifiers. gcc/testsuite: PR preprocessor/9449 * lib/target-supports.exp (check_effective_target_ucn_nocache): Don't use -fextended-identifiers. * c-c++-common/cpp/normalize-3.c, c-c++-common/cpp/ucnid-2011-1.c, g++.dg/cpp/ucn-1.C, g++.dg/cpp/ucnid-1.C, g++.dg/other/ucnid-1.C, gcc.dg/cpp/normalize-1.c, gcc.dg/cpp/normalize-2.c, gcc.dg/cpp/normalize-4.c: Don't use -fextended-identifiers. * gcc.dg/cpp/ucnid-1.c: Don't use -fextended-identifiers. Use -g3. * gcc.dg/cpp/ucnid-10.c, gcc.dg/cpp/ucnid-2.c, gcc.dg/cpp/ucnid-3.c, gcc.dg/cpp/ucnid-4.c, gcc.dg/cpp/ucnid-5.c, gcc.dg/cpp/ucnid-7.c, gcc.dg/cpp/ucnid-9.c, gcc.dg/cpp/warn-normalized-1.c, gcc.dg/cpp/warn-normalized-2.c, gcc.dg/cpp/warn-normalized-3.c:
[Bug c/63751] New: ICE in tree_to_uhwi, at tree.h:3668
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63751
Bug ID: 63751
Summary: ICE in tree_to_uhwi, at tree.h:3668
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
fails on the 4.9 branch, works on the trunk
$ cat tst.c
/* testatomic.c */
#include stdatomic.h
#include stdbool.h
struct myrcu_pointer
{
_Atomic(void *) p;
};
bool
myrcu_compare_exchange__(struct myrcu_pointer *pointer, const void *exp,
void *value, memory_order order_succ,
memory_order order_fail)
{
return atomic_compare_exchange_weak_explicit(pointer-p, (void *) exp,
value, order_succ,
order_fail);
}
$ gcc -c tst.c
tst.c: In function 'myrcu_compare_exchange__':
tst.c:15:5: internal compiler error: in tree_to_uhwi, at tree.h:3668
return atomic_compare_exchange_weak_explicit(pointer-p, (void *) exp,
^
Please submit a full bug report,
with preprocessed source if appropriate.
$ /usr/lib/gcc-snapshot/bin/gcc -c tst.c
In file included from tst.c:2:0:
tst.c: In function 'myrcu_compare_exchange__':
tst.c:15:12: error: size mismatch in argument 2 of '__atomic_compare_exchange'
return atomic_compare_exchange_weak_explicit(pointer-p, (void *) exp,
^
[Bug preprocessor/9449] UCNs not recognized in identifiers (c++/c99)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9449 Joseph S. Myers jsm28 at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #48 from Joseph S. Myers jsm28 at gcc dot gnu.org --- Enabled by default for relevant standards for GCC 5.
[Bug c/16989] [meta-bug] C99 conformance bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16989 Bug 16989 depends on bug 9449, which changed state. Bug 9449 Summary: UCNs not recognized in identifiers (c++/c99) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9449 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/63752] New: avr ICE at reload1.c:2128 building newlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63752
Bug ID: 63752
Summary: avr ICE at reload1.c:2128 building newlib
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
Created attachment 33895
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33895action=edit
Preprocessed newlib/libc/stdlib/mprec.c which generates the ICE
xgcc (GCC) 5.0.0 20141104 (experimental)
Bug triggered at -O2 and -0Os but not at -O0 or -O1.
/users/joel/test-gcc/b-avr-rtems4.11-gcc/./gcc/xgcc
-B/users/joel/test-gcc/b-avr-rtems4.11-gcc/./gcc/ -march=avr2 -O2 -c avr_bug.c
/users/joel/test-gcc/b-avr-rtems4.11-gcc/./gcc/xgcc
-B/users/joel/test-gcc/b-avr-rtems4.11-gcc/./gcc/ -nostdinc
-B/users/joel/test-gcc/b-avr-rtems4.11-gcc/avr-rtems4.11/avr2/newlib/ -isystem
/users/joel/test-gcc/b-avr-rtems4.11-gcc/avr-rtems4.11/avr2/newlib/targ-include
-isystem /users/joel/test-gcc/gcc/newlib/libc/include
-B/users/joel/test-gcc/install-head/avr-rtems4.11/bin/
-B/users/joel/test-gcc/install-head/avr-rtems4.11/lib/ -isystem
/users/joel/test-gcc/install-head/avr-rtems4.11/include -isystem
/users/joel/test-gcc/install-head/avr-rtems4.11/sys-include -march=avr2
-DPACKAGE_NAME=\newlib\ -DPACKAGE_TARNAME=\newlib\
-DPACKAGE_VERSION=\2.1.0\ -DPACKAGE_STRING=\newlib\ 2.1.0\
-DPACKAGE_BUGREPORT=\\ -DPACKAGE_URL=\\ -I.
-I../../../../../../gcc/newlib/libc/stdlib -Os -DPREFER_SIZE_OVER_SPEED
-mcall-prologues -D_COMPILING_NEWLIB -DMALLOC_PROVIDED -DEXIT_PROVIDED
-DSIGNAL_PROVIDED -DREENTRANT_SYSCALLS_PROVIDED -DHAVE_NANOSLEEP -DHAVE_BLKSIZE
-DHAVE_FCNTL -DHAVE_ASSERT_FUNC -D_NO_GETLOGIN -D_NO_GETPWENT -D_NO_GETUT
-D_NO_GETPASS -D_NO_SIGSET -D_NO_WORDEXP -D_NO_POPEN -D_NO_POSIX_SPAWN
-fno-builtin -g -O2 -c -o lib_a-mprec.o `test -f 'mprec.c' || echo
'../../../../../../gcc/newlib/libc/stdlib/'`mprec.c
../../../../../../gcc/newlib/libc/stdlib/mprec.c: In function '__multiply':
../../../../../../gcc/newlib/libc/stdlib/mprec.c:419:1: error: unable to find a
register to spill in class 'POINTER_REGS'
}
^
../../../../../../gcc/newlib/libc/stdlib/mprec.c:419:1: error: this is the
insn:
(insn 86 85 88 16 (set (reg:SI 68 [ D.3699 ])
(mem:SI (post_inc:HI (reg:HI 16 r16 [orig:45 ivtmp.143 ] [45])) [16
MEM[base: _146, offset: 0B]+0 S4 A8]))
../../../../../../gcc/newlib/libc/stdlib/mprec.c:370 94 {*movsi}
(expr_list:REG_INC (reg:HI 16 r16 [orig:45 ivtmp.143 ] [45])
(nil)))
../../../../../../gcc/newlib/libc/stdlib/mprec.c:419:1: internal compiler
error: in spill_failure, at reload1.c:2128
0x87df63 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/gcc/rtl-error.c:110
0x87d7fd spill_failure
../../gcc/gcc/reload1.c:2128
0x87d7fd find_reload_regs
../../gcc/gcc/reload1.c:2054
0x87d7fd select_reload_regs
../../gcc/gcc/reload1.c:2074
0x87d7fd reload(rtx_insn*, int)
../../gcc/gcc/reload1.c:1043
0x776eb3 do_reload
../../gcc/gcc/ira.c:5392
0x776eb3 execute
../../gcc/gcc/ira.c:5542
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
make: *** [lib_a-mprec.o] Error 1
[Bug c/63751] ICE in tree_to_uhwi, at tree.h:3668
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63751 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-05 CC||mpolacek at gcc dot gnu.org Version|5.0 |4.9.2 Target Milestone|--- |4.9.3 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- On trunk I fixed this with r211905. That needs to be backported to 4.9.
[Bug go/63269] libgo/math test failures in TestLog2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63269 --- Comment #5 from Dominik Vogt vogt at linux dot vnet.ibm.com --- regarding 1) My earlier explanation of the problem was wrong. Multiply and add is not generated; it probably only was in the artificial test case that I made and certainly did not compile with -ffp-contract=off. In this calculation in log2(), Log(frac)*(1/Ln2) + float64(exp) Gcc does constant folding for (1/Ln2) and generates a multiply instruction and then adds the second term. Same result if you write *Log2E instead of *(1/Ln2)). But with Log(frac)/Ln2 + float64(exp) it generates a divide instruction. The multiplication and the division yield results that differ in the least significant bit, and I don't see how this could be prevented in general; it's just an artifact of the floating point format. I've verified that the constants Ln2, 1/Ln2 and Log2E are bit correct. The easy way to fix this is increasing the allowed tolerance as my patch does (note that the arguments of the veryclose() call need to be swapped, see previous comment). The right way to fix this is to calculate platform specific ULPs for all the algorithms from the math library and use these. That's what glibc does.
[Bug tree-optimization/63595] [5.0 Regression] Segmentation faults inside kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63595 --- Comment #10 from Martin Liška marxin at gcc dot gnu.org --- Created attachment 33896 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33896action=edit reduced test case for tria.ii
[Bug driver/36312] should refuse to overwrite input file with output file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36312 --- Comment #8 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Author: manu Date: Wed Nov 5 17:23:46 2014 New Revision: 217149 URL: https://gcc.gnu.org/viewcvs?rev=217149root=gccview=rev Log: gcc/testsuite/ChangeLog: 2014-11-05 Anthony Brandon anthony.bran...@gmail.com PR driver/36312 * gcc.misc-tests/output.exp: New test case for identical input and output files. include/ChangeLog: 2014-11-05 Anthony Brandon anthony.bran...@gmail.com PR driver/36312 * filenames.h: Add prototype for canonical_filename_eq. gcc/ChangeLog: 2014-11-05 Anthony Brandon anthony.bran...@gmail.com PR driver/36312 * diagnostic-core.h: Add prototype for fatal_error. * diagnostic.c (fatal_error): New function fatal_error. * gcc.c (store_arg): Remove have_o_argbuf_index. (process_command): Check if input and output files are the same. * toplev.c (init_asm_output): Check if input and output files are the same. libiberty/ChangeLog: 2014-11-05 Anthony Brandon anthony.bran...@gmail.com PR driver/36312 * filename_cmp.c (canonical_filename_eq): New function to check if file names are the same. * functions.texi: Updated with documentation for new function. Added: trunk/gcc/testsuite/gcc.misc-tests/output.exp Modified: trunk/gcc/ChangeLog trunk/gcc/diagnostic-core.h trunk/gcc/diagnostic.c trunk/gcc/gcc.c trunk/gcc/testsuite/ChangeLog trunk/gcc/toplev.c trunk/include/ChangeLog trunk/include/filenames.h trunk/libiberty/ChangeLog trunk/libiberty/filename_cmp.c trunk/libiberty/functions.texi
[Bug target/63742] arm *movhi_insn_arch4 pattern may emit ldrh which is wrong for big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63742 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Richard Earnshaw rearnsha at gcc dot gnu.org --- Dup of 59593. *** This bug has been marked as a duplicate of bug 59593 ***
[Bug target/59593] [arm big-endian] using ldrh access a immediate which stored in a memory by word
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59593 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added CC||fei.yang0953 at gmail dot com --- Comment #2 from Richard Earnshaw rearnsha at gcc dot gnu.org --- *** Bug 63742 has been marked as a duplicate of this bug. ***
[Bug driver/36312] should refuse to overwrite input file with output file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36312 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Anthony Brandon updated my patch and added a testcase, so this is fixed in GCC 5.0. This was his second contribution to GCC, which shows that Contributing to GCC is hard is a myth.
Re: Suggestions welcomed to get bootstrap to work
You would probably be better of discussing this on gcc-help. gcc-bugs is rather full of bugzilla traffic and normal mails are easily missed. Have you tried setting CONFIG_SHELL in the environment? Also, when running the build use something like make SHELL=/bin/bash R. On 03/11/14 20:22, Michael Felt wrote: What I have not yet found is how to get the SHELL variable to not use /bin/sh because this is causing a failure immediately at the start of make: root@x064:[/data/prj/gnu/gcc/objdir/gcc-4.7.4]make [ -f stage_final ] || echo stage3 stage_final /bin/sh[3]: 0403-057 Syntax error at line 1 : `-qlanglvl=extc89' is not expected. make: *** [all] Error 2 Setting a link from /bin/sh to bash is just a way of breaking the host. I hope there is be a normal way to resolve this. regards, Michael p.s. 4.5.4 fails elsewhere - it does not come as far as 4.7.4 or 4.6.4 On Mon, Nov 3, 2014 at 9:19 PM, Michael Felt aixto...@gmail.com wrote: I fear that after being set to wontfix an entry such as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63714 will be completely ignored. That is not what I was expecting having spent nearly 8 hours yesterday looking for something I may have missed. I do not understand how to move forward from: Don't bootstrap GCC with IBM XLC. - considering that is the compiler I have. As I commented in the bug above, there are issues I have run into with gcc from other sources. If it turns out there is no other way, then that shall be the path forced upon me - but I prefer to research and package my own so that the demands on the host finally get documented - rather than libraries that step on each other and damage existing programs. That my submission is on the bug-list is because that is what seemed to be the correct path to submit a question. That gcc decides to never include any result in the source tree is of course your choice. I merely wish to express my hope for some sort of assistance in moving forward versus a stonewall of don't care. FYI: I am trying 4.5.4 now as well, but I fear the same result. Maybe it is just a shell thing (e.g. needs a specific bash behavior) I shall continue to post, suggestions welcome. Michael
[Bug bootstrap/63750] use of undeclared identifier 'do_not_use_isalnum_with_safe_ctype'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63750 --- Comment #2 from howarth at bromo dot med.uc.edu --- Created attachment 33897 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33897action=edit patch to pass fix by appending #include sstream to gcc/ipa-chkp.c
[Bug driver/36312] should refuse to overwrite input file with output file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36312 --- Comment #10 from Wojciech Koszek wkoszek at gmail dot com --- I'm very happy seeing it in GCC. On Wed, Nov 5, 2014 at 9:24 AM, manu at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36312 --- Comment #8 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Author: manu Date: Wed Nov 5 17:23:46 2014 New Revision: 217149 URL: https://gcc.gnu.org/viewcvs?rev=217149root=gccview=rev Log: gcc/testsuite/ChangeLog: 2014-11-05 Anthony Brandon anthony.bran...@gmail.com PR driver/36312 * gcc.misc-tests/output.exp: New test case for identical input and output files. include/ChangeLog: 2014-11-05 Anthony Brandon anthony.bran...@gmail.com PR driver/36312 * filenames.h: Add prototype for canonical_filename_eq. gcc/ChangeLog: 2014-11-05 Anthony Brandon anthony.bran...@gmail.com PR driver/36312 * diagnostic-core.h: Add prototype for fatal_error. * diagnostic.c (fatal_error): New function fatal_error. * gcc.c (store_arg): Remove have_o_argbuf_index. (process_command): Check if input and output files are the same. * toplev.c (init_asm_output): Check if input and output files are the same. libiberty/ChangeLog: 2014-11-05 Anthony Brandon anthony.bran...@gmail.com PR driver/36312 * filename_cmp.c (canonical_filename_eq): New function to check if file names are the same. * functions.texi: Updated with documentation for new function. Added: trunk/gcc/testsuite/gcc.misc-tests/output.exp Modified: trunk/gcc/ChangeLog trunk/gcc/diagnostic-core.h trunk/gcc/diagnostic.c trunk/gcc/gcc.c trunk/gcc/testsuite/ChangeLog trunk/gcc/toplev.c trunk/include/ChangeLog trunk/include/filenames.h trunk/libiberty/ChangeLog trunk/libiberty/filename_cmp.c trunk/libiberty/functions.texi -- You are receiving this mail because: You are on the CC list for the bug.
[Bug bootstrap/63622] [5.0 Regression] Bootstrap fails on x86_64-apple-darwin1[34] after revision r216305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63622 --- Comment #8 from howarth at bromo dot med.uc.edu --- At r217144 with https://gcc.gnu.org/bugzilla/attachment.cgi?id=33897 to fix PR63750, gcc trunk now bootstraps up to the illegal text reloc error. Is this problem understood well enough to debug or should I send a standalone test case to the darwin linker developer for further analysis of the linkage error?
[Bug c++/63753] New: std::transform does not change size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63753
Bug ID: 63753
Summary: std::transform does not change size
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: darkdragon-001 at web dot de
When using std::transform with a OutputIterator to std::vector then the vector
size is not updated (see code attached):
#include algorithm
#include iostream
#include vector
using namespace std;
int main() {
vectordouble v = {1,2,3,4,5};
vectordouble r;
r.reserve(v.size());
transform(v.begin(),v.end(),r.begin(),[](const double d) {
return 2*d;
});
cout size: r.size() front: r.front() endl;
return 0;
}
[Bug testsuite/63211] gcc.target/i386/avx2-*.c tests use broken type-punning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63211 --- Comment #2 from Kirill Yukhin kyukhin at gcc dot gnu.org --- Confirmed. We'll fix that.
[Bug target/63754] New: h8300 ICE in as_a, at is-a.h:192 during libgcc autoconf probe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63754
Bug ID: 63754
Summary: h8300 ICE in as_a, at is-a.h:192 during libgcc
autoconf probe
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
Created attachment 33898
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33898action=edit
autoconf probe for ICE
configure:: /users/joel/test-gcc/b-h8300-rtems4.11-gcc/./gcc/xgcc
-B/users/joel/test-gcc/b-h8300-rtems4.11-gcc/./gcc/ -nostdinc
-B/users/joel/test-gcc/b-h8300-rtems4.11-gcc/h8300-rtems4.11/h8300s/newlib/
-isystem
/users/joel/test-gcc/b-h8300-rtems4.11-gcc/h8300-rtems4.11/h8300s/newlib/targ-include
-isystem /users/joel/test-gcc/gcc/newlib/libc/include
-B/users/joel/test-gcc/install-head/h8300-rtems4.11/bin/
-B/users/joel/test-gcc/install-head/h8300-rtems4.11/lib/ -isystem
/users/joel/test-gcc/install-head/h8300-rtems4.11/include -isystem
/users/joel/test-gcc/install-head/h8300-rtems4.11/sys-include -ms -c
--save-temps -fexceptions conftest.c 5
conftest.c: In function 'foo':
conftest.c:19:1: internal compiler error: in as_a, at is-a.h:192
}
^
0xb62c73 rtx_insn* as_artx_insn*, rtx_def(rtx_def*)
../../gcc/gcc/is-a.h:192
0xb62c73 Fpa
../../gcc/gcc/config/h8300/h8300.c:525
0xb62c73 h8300_push_pop
../../gcc/gcc/config/h8300/h8300.c:719
0xb62fb9 h8300_push_pop
../../gcc/gcc/config/h8300/h8300.c:874
0xb62fb9 h8300_expand_prologue()
../../gcc/gcc/config/h8300/h8300.c:885
0xb6e25a gen_prologue()
../../gcc/gcc/config/h8300/h8300.md:2651
0x6cc4f7 thread_prologue_and_epilogue_insns
../../gcc/gcc/function.c:5678
0x6cc4f7 rest_of_handle_thread_prologue_and_epilogue
../../gcc/gcc/function.c:6248
0x6cc4f7 execute
../../gcc/gcc/function.c:6286
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
configure:: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME GNU C Runtime Library
| #define PACKAGE_TARNAME libgcc
| #define PACKAGE_VERSION 1.0
| #define PACKAGE_STRING GNU C Runtime Library 1.0
| #define PACKAGE_BUGREPORT
| #define PACKAGE_URL http://www.gnu.org/software/libgcc/;
| #define SIZEOF_DOUBLE 4
| #define SIZEOF_LONG_DOUBLE 4
| #define HAVE_GETIPINFO 1
| /* end confdefs.h. */
|
| void bar ();
| void clean (int *);
| void foo ()
| {
| int i __attribute__ ((cleanup (clean)));
| bar();
| }
|
configure:4262: result: unknown
configure:4278: error: unable to detect exception model
jjjkz
[Bug target/63754] h8300 ICE in as_a, at is-a.h:192 during libgcc autoconf probe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63754 Joel Sherrill joel at gcc dot gnu.org changed: What|Removed |Added Target||h8300-rtems Known to work||4.8.3 --- Comment #1 from Joel Sherrill joel at gcc dot gnu.org --- This is with xgcc (GCC) 5.0.0 20141104 (experimental)
[Bug libstdc++/63698] [5 Regression] std::set leaks nodes on assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63698 --- Comment #8 from François Dumont fdumont at gcc dot gnu.org --- Author: fdumont Date: Wed Nov 5 19:16:13 2014 New Revision: 217154 URL: https://gcc.gnu.org/viewcvs?rev=217154root=gccview=rev Log: 2014-11-04 François Dumont fdum...@gcc.gnu.org Jonathan Wakely jwak...@redhat.com PR libstdc++/63698 * include/bits/stl_tree.h (_Reuse_or_alloc_node): Simplify constructor. Always move to the left node if there is one. * testsuite/23_containers/set/allocator/move_assign.cc (test04): New. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_tree.h trunk/libstdc++-v3/testsuite/23_containers/set/allocator/move_assign.cc
[Bug libstdc++/63698] [5 Regression] std::set leaks nodes on assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63698 François Dumont fdumont at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from François Dumont fdumont at gcc dot gnu.org --- Now fixed on trunk
[Bug target/63755] New: m32c invalid asm generated in libgcc autoconf probe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63755
Bug ID: 63755
Summary: m32c invalid asm generated in libgcc autoconf probe
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: joel at gcc dot gnu.org
Created attachment 33899
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33899action=edit
autoconf libgcc probe generating ICE
xgcc (GCC) 5.0.0 20141104 (experimental)
configure:: /users/joel/test-gcc/b-m32c-rtems4.11-gcc/./gcc/xgcc
-B/users/joel/test-gcc/b-m32c-rtems4.11-gcc/./gcc/ -nostdinc
-B/users/joel/test-gcc/b-m32c-rtems4.11-gcc/m32c-rtems4.11/m32cm/newlib/
-isystem
/users/joel/test-gcc/b-m32c-rtems4.11-gcc/m32c-rtems4.11/m32cm/newlib/targ-include
-isystem /users/joel/test-gcc/gcc/newlib/libc/include
-B/users/joel/test-gcc/install-head/m32c-rtems4.11/bin/
-B/users/joel/test-gcc/install-head/m32c-rtems4.11/lib/ -isystem
/users/joel/test-gcc/install-head/m32c-rtems4.11/include -isystem
/users/joel/test-gcc/install-head/m32c-rtems4.11/sys-include -mcpu=m32cm -c
--save-temps -fexceptions conftest.c 5
conftest.c: In function 'foo':
conftest.c:19:1: error: insn does not satisfy its constraints:
}
^
(insn 50 38 23 (set (reg:SI 2 r1 [29])
(reg:SI 4 a0)) 99 {movsi_24}
(nil))
conftest.c:19:1: internal compiler error: in final_scan_insn, at final.c:2946
0x87e623 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/gcc/rtl-error.c:110
0x87e64f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/gcc/rtl-error.c:121
0x659ba9 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../gcc/gcc/final.c:2946
0x659c76 final(rtx_insn*, _IO_FILE*, int)
../../gcc/gcc/final.c:2076
0x65a61e rest_of_handle_final
../../gcc/gcc/final.c:4484
0x65a61e execute
../../gcc/gcc/final.c:4559
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
configure:: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME GNU C Runtime Library
| #define PACKAGE_TARNAME libgcc
| #define PACKAGE_VERSION 1.0
| #define PACKAGE_STRING GNU C Runtime Library 1.0
| #define PACKAGE_BUGREPORT
| #define PACKAGE_URL http://www.gnu.org/software/libgcc/;
| #define SIZEOF_DOUBLE 8
| #define SIZEOF_LONG_DOUBLE 8
| #define HAVE_GETIPINFO 1
| /* end confdefs.h. */
|
| void bar ();
| void clean (int *);
| void foo ()
| {
| int i __attribute__ ((cleanup (clean)));
| bar();
| }
|
configure:4262: result: unknown
configure:4278: error: unable to detect exception model
[Bug other/63694] [5.0 Regression] Build error compiling asan.c: strtoull undeclared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63694 --- Comment #7 from dave.anglin at bell dot net --- This bug is easily fixed by adding declaration checks for the new libiberty functions to configure.ac (both libiberty and gcc), and rebuilding configure and config.in. Sorry, I haven't had time to prepare a patch yet. Dave
[Bug target/63538] [X86_64] With -mcmodel=medium .lrodata accesses do not use 64-bit addresses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63538 --- Comment #2 from uros at gcc dot gnu.org --- Author: uros Date: Wed Nov 5 21:00:07 2014 New Revision: 217156 URL: https://gcc.gnu.org/viewcvs?rev=217156root=gccview=rev Log: PR target/63538 * config/i386/i386.c (in_large_data_p): Reject automatic variables. (ix86_encode_section_info): Do not check for non-automatic varibles when setting SYMBOL_FLAG_FAR_ADDR flag. (x86_64_elf_select_section): Do not check ix86_cmodel here. (x86_64_elf_unique_section): Ditto. (x86_elf_aligned_common): Emit tab before .largecomm. testsuite/ChangeLog: PR target/63538 * gcc.target/i386/pr63538.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr63538.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug bootstrap/63622] [5.0 Regression] Bootstrap fails on x86_64-apple-darwin1[34] after revision r216305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63622 --- Comment #9 from howarth at bromo dot med.uc.edu --- The darwin linker developer's analysis of this failing linkage is as follows... That link line contains “-undefined dynamic_lookup” which is almost always a bad idea. Removing it shows the problem. The symbol __ZTCSt9strstream16_So is not defined in an object file. So that option means “assume it will be in some dylib (DSO) at runtime). But the function __ZNSt9strstreamC1Ev contains: __ZNSt9strstreamC1Ev: ... 1f75leaq__ZTCSt9strstream16_So+24(%rip), %rax … That code gen requires the target vtable to be in the same linkage unit, but is is in DSO. The only way to possible make it work is to have a text relocation which adjusts the LEA at launch time. But darwin x86_64 does not support text relocations. You should remove the “-undefined dynamic_lookup” from the link line and fix the build to have all required symbols defined.
[Bug libstdc++/63753] std::transform does not change size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63753 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org --- It isn't supposed to be updated.
[Bug bootstrap/63622] [5.0 Regression] Bootstrap fails on x86_64-apple-darwin1[34] after revision r216305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63622 --- Comment #10 from howarth at bromo dot med.uc.edu --- Note that removal of the -undefined dynamic_lookup produces... Undefined symbols for architecture x86_64: __ZNKSt11logic_error4whatEv, referenced from: __ZTVSt11logic_error in libc++98convenience.a(stdexcept.o) __ZTVSt12domain_error in libc++98convenience.a(stdexcept.o) __ZTVSt16invalid_argument in libc++98convenience.a(stdexcept.o) __ZTVSt12length_error in libc++98convenience.a(stdexcept.o) __ZTVSt12out_of_range in libc++98convenience.a(stdexcept.o) __ZNKSt7codecvtIcc11__mbstate_tE10do_unshiftERS0_PcS3_RS3_, referenced from: __ZTVSt7codecvtIcc11__mbstate_tE in libc++98convenience.a(codecvt.o) __ZTVSt14codecvt_bynameIcc11__mbstate_tE in libc++98convenience.a(locale-inst.o) __ZNKSt7codecvtIcc11__mbstate_tE11do_encodingEv, referenced from: __ZTVSt7codecvtIcc11__mbstate_tE in libc++98convenience.a(codecvt.o) __ZTVSt14codecvt_bynameIcc11__mbstate_tE in libc++98convenience.a(locale-inst.o) __ZNKSt7codecvtIcc11__mbstate_tE6do_outERS0_PKcS4_RS4_PcS6_RS6_, referenced from: __ZTVSt7codecvtIcc11__mbstate_tE in libc++98convenience.a(codecvt.o) __ZTVSt14codecvt_bynameIcc11__mbstate_tE in libc++98convenience.a(locale-inst.o) __ZNKSt9type_info14__is_pointer_pEv, referenced from: __ZTVN10__cxxabiv117__array_type_infoE in libsupc++convenience.a(array_type_info.o) __ZTVN10__cxxabiv117__class_type_infoE in libsupc++convenience.a(class_type_info.o) __ZTVN10__cxxabiv116__enum_type_infoE in libsupc++convenience.a(enum_type_info.o) __ZTVN10__cxxabiv120__function_type_infoE in libsupc++convenience.a(function_type_info.o) __ZTVN10__cxxabiv123__fundamental_type_infoE in libsupc++convenience.a(fundamental_type_info.o) __ZTVN10__cxxabiv117__pbase_type_infoE in libsupc++convenience.a(pbase_type_info.o) __ZTVN10__cxxabiv129__pointer_to_member_type_infoE in libsupc++convenience.a(pmem_type_info.o) ... __ZNSbIwSt11char_traitsIwESaIwEE12_S_constructIPwEES4_T_S5_RKS1_St20forward_iterator_tag.part.36, referenced from: __ZNSbIwSt11char_traitsIwESaIwEE12_S_constructIPwEES4_T_S5_RKS1_St20forward_iterator_tag in libc++11convenience.a(wstring-inst.o) __ZNSs12_S_constructIPcEES0_T_S1_RKSaIcESt20forward_iterator_tag.part.34, referenced from: __ZNSs12_S_constructIPcEES0_T_S1_RKSaIcESt20forward_iterator_tag in libc++11convenience.a(string-inst.o) __ZNSt15basic_streambufIcSt11char_traitsIcEE4syncEv, referenced from: __ZTVSt12strstreambuf in libc++98convenience.a(strstream.o) __ZTVSt15basic_stringbufIcSt11char_traitsIcESaIcEE in libc++11convenience.a(sstream-inst.o) __ZTVSt15basic_streambufIcSt11char_traitsIcEE in libc++11convenience.a(streambuf-inst.o) __ZNSt15basic_streambufIcSt11char_traitsIcEE5imbueERKSt6locale, referenced from: __ZTVSt12strstreambuf in libc++98convenience.a(strstream.o) __ZTVN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEEE in libc++11convenience.a(ext11-inst.o) __ZTVSt15basic_stringbufIcSt11char_traitsIcESaIcEE in libc++11convenience.a(sstream-inst.o) __ZTVSt15basic_streambufIcSt11char_traitsIcEE in libc++11convenience.a(streambuf-inst.o) __ZNSt15basic_streambufIcSt11char_traitsIcEE6setbufEPcl, referenced from: __ZTVN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEEE in libc++11convenience.a(ext11-inst.o) __ZTVSt15basic_streambufIcSt11char_traitsIcEE in libc++11convenience.a(streambuf-inst.o) __ZNSt15basic_streambufIcSt11char_traitsIcEE7seekoffExSt12_Ios_SeekdirSt13_Ios_Openmode, referenced from: __ZTVSt15basic_streambufIcSt11char_traitsIcEE in libc++11convenience.a(streambuf-inst.o) __ZNSt15basic_streambufIcSt11char_traitsIcEE7seekposESt4fposI11__mbstate_tESt13_Ios_Openmode, referenced from: __ZTVSt15basic_streambufIcSt11char_traitsIcEE in libc++11convenience.a(streambuf-inst.o) __ZNSt15basic_streambufIcSt11char_traitsIcEE8overflowEi, referenced from: __ZTVSt15basic_streambufIcSt11char_traitsIcEE in libc++11convenience.a(streambuf-inst.o) __ZNSt15basic_streambufIcSt11char_traitsIcEE9pbackfailEi, referenced from: __ZTVSt15basic_streambufIcSt11char_traitsIcEE in libc++11convenience.a(streambuf-inst.o) __ZNSt15basic_streambufIcSt11char_traitsIcEE9showmanycEv, referenced from: __ZTVSt12strstreambuf in libc++98convenience.a(strstream.o) __ZTVN9__gnu_cxx18stdio_sync_filebufIcSt11char_traitsIcEEE in libc++11convenience.a(ext11-inst.o) __ZTVSt15basic_streambufIcSt11char_traitsIcEE in libc++11convenience.a(streambuf-inst.o) __ZNSt15basic_streambufIcSt11char_traitsIcEE9underflowEv, referenced from: __ZTVSt15basic_streambufIcSt11char_traitsIcEE in libc++11convenience.a(streambuf-inst.o) __ZNSt15basic_streambufIwSt11char_traitsIwEE9pbackfailEi, referenced from: __ZTVSt15basic_streambufIwSt11char_traitsIwEE in libc++11convenience.a(streambuf-inst.o)
[Bug target/63538] [X86_64] With -mcmodel=medium .lrodata accesses do not use 64-bit addresses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63538 --- Comment #3 from uros at gcc dot gnu.org --- Author: uros Date: Wed Nov 5 22:23:05 2014 New Revision: 217160 URL: https://gcc.gnu.org/viewcvs?rev=217160root=gccview=rev Log: PR target/63538 * config/i386/i386.c (in_large_data_p): Reject automatic variables. (ix86_encode_section_info): Do not check for non-automatic varibles when setting SYMBOL_FLAG_FAR_ADDR flag. (x86_64_elf_select_section): Do not check ix86_cmodel here. (x86_64_elf_unique_section): Ditto. (x86_elf_aligned_common): Emit tab before .largecomm. testsuite/ChangeLog: PR target/63538 * gcc.target/i386/pr63538.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/pr63538.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/i386/i386.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug driver/36312] should refuse to overwrite input file with output file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36312 --- Comment #11 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Author: manu Date: Wed Nov 5 22:17:22 2014 New Revision: 217159 URL: https://gcc.gnu.org/viewcvs?rev=217159root=gccview=rev Log: Revert revision 217149 because it breaks Ada: gcc/testsuite/ChangeLog: 2014-11-05 Anthony Brandon anthony.bran...@gmail.com PR driver/36312 * gcc.misc-tests/output.exp: New test case for identical input and output files. include/ChangeLog: 2014-11-05 Anthony Brandon anthony.bran...@gmail.com PR driver/36312 * filenames.h: Add prototype for canonical_filename_eq. gcc/ChangeLog: 2014-11-05 Anthony Brandon anthony.bran...@gmail.com PR driver/36312 * diagnostic-core.h: Add prototype for fatal_error. * diagnostic.c (fatal_error): New function fatal_error. * gcc.c (store_arg): Remove have_o_argbuf_index. (process_command): Check if input and output files are the same. * toplev.c (init_asm_output): Check if input and output files are the same. libiberty/ChangeLog: 2014-11-05 Anthony Brandon anthony.bran...@gmail.com PR driver/36312 * filename_cmp.c (canonical_filename_eq): New function to check if file names are the same. * functions.texi: Updated with documentation for new function. Removed: trunk/gcc/testsuite/gcc.misc-tests/output.exp Modified: trunk/gcc/ChangeLog trunk/gcc/diagnostic-core.h trunk/gcc/diagnostic.c trunk/gcc/gcc.c trunk/gcc/testsuite/ChangeLog trunk/gcc/toplev.c trunk/include/ChangeLog trunk/include/filenames.h trunk/libiberty/ChangeLog trunk/libiberty/filename_cmp.c trunk/libiberty/functions.texi
[Bug target/63538] [X86_64] With -mcmodel=medium .lrodata accesses do not use 64-bit addresses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63538 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.3 --- Comment #4 from Uroš Bizjak ubizjak at gmail dot com --- Fixed for 4.9.3+.
[Bug c++/63198] decltype in template function declaration yields spurious error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63198 Thomas Bernard thomas at famillebernardgouriou dot fr changed: What|Removed |Added CC||thomas@famillebernardgourio ||u.fr --- Comment #3 from Thomas Bernard thomas at famillebernardgouriou dot fr --- I tried investigating this and it seems that decltype( v1 = v2 )::t1 should be handled as a dependent type, but isn't. I modified the test case like this template typename T void f1(typename decltype(v1 = v2)::t1); and the problem seems to be solved.
[Bug c/63756] New: _mm_cvtepi16_epi32 with a memory operand produces either broken or slow asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63756 Bug ID: 63756 Summary: _mm_cvtepi16_epi32 with a memory operand produces either broken or slow asm Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tterribe at xiph dot org Created attachment 33900 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33900action=edit Reduced testcase With optimizations enabled, the call _mm_cvtepi16_epi32(*(__m128i *)x) for some pointer x produces the asm pmovsxwd (%rax), %xmm0 which is all well and good, and what was intended. However, with optimizations disabled, the same code produces movdqa (%rax), %xmm0 movaps %xmm0, -48(%rbp) movdqa -48(%rbp), %xmm0 pmovsxwd %xmm0, %xmm0 The problem here is that the initial movdqa has added a 16-byte alignment requirement and reads 8 bytes past where the original pmovsxwd instruction would have read in the optimized version. This is very much not equivalent, and causes crashes in code that runs just fine in the optimized version. _mm_cvtepi16_epi32() takes an __m128i argument, and the dereference happens before the function call. Even though the asm instruction it's standing in for can do it all together, we don't have a single intrinsic which specifies exactly that. None of the semantics here are very well documented anywhere, but I can understand why the compiler might think it has the right to do what it did. So I try the following code: _mm_cvtepi16_epi32(_mm_loadl_epi64((__m128i *)x) With optimizations disabled, this produces the slightly long-winded, but at least correct asm of: movq (%rax), %rax movl $0, %edx movq %rdx, -128(%rbp) movq %rax, -120(%rbp) movq -120(%rbp), %rax movq -128(%rbp), %rdx movq %rdx, -112(%rbp) movq %rax, -104(%rbp) movq -112(%rbp), %rax movq -104(%rbp), %xmm0 pinsrq $1, %rax, $xmm0 movaps %xmm0, -64(%rbp) movdqa -64(%rbp), %xmm0 pmovsxwd %xmm0, %xmm0 So that's all good. movq has the same semantics as a memory operand in pmovsxwd, so we haven't added any extra alignment requirements or read any extra data. Turning optimizations back on, one might reasonably expect the optimizer to collapse the two intrinsics into the same single instruction it had before, since they should, in fact, be equivalent to what that instruction did. However, the asm one gets instead is pxor %xmm0, %xmm0 pinsrq $0, (%rax), %xmm0 pmovsxwd %xmm0, %xmm0 So this is 3 instructions, 4 uops, and a 4-cycle latency (minimum) for what should have been 1 instruction, 1 fused-domain uop, and a 2-cycle latency (minimum). It makes a noticeable difference. The current code I am using in my project is to wrap these in a macro that says #ifdef __OPTIMIZE__, leave out the _mm_loadl_epi64(), but otherwise put it in. However, that seems moderately terrible, and like something the compiler could choose to break at any time.
[Bug target/63756] _mm_cvtepi16_epi32 with a memory operand produces either broken or slow asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63756 --- Comment #1 from Timothy B. Terriberry tterribe at xiph dot org --- Created attachment 33901 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33901action=edit Preprocessed file for no-opt version (gcc pmovsxwd.c -msse4.1 -save-temps -o pmovsxwd)
[Bug target/63756] _mm_cvtepi16_epi32 with a memory operand produces either broken or slow asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63756 --- Comment #2 from Timothy B. Terriberry tterribe at xiph dot org --- Created attachment 33902 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33902action=edit Preprocessed file for opt version (gcc pmovsxwd.c -msse4.1 -O2 -save-temps -o pmovsxwd)
[Bug target/63756] _mm_cvtepi16_epi32 with a memory operand produces either broken or slow asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63756 --- Comment #3 from Timothy B. Terriberry tterribe at xiph dot org --- GCC version: Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.9.1/work/gcc-4.9.1/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.1 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.1/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.1 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.1/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.1/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.1/include/g++-v4 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.9.1/python --enable-languages=c,c++,java,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.9.1 p1.0, pie-0.6.0' --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --enable-libgomp --disable-libmudflap --disable-libssp --enable-lto --with-cloog --disable-isl-version-check Thread model: posix gcc version 4.9.1 (Gentoo 4.9.1 p1.0, pie-0.6.0)
[Bug bootstrap/63622] [5.0 Regression] Bootstrap fails on x86_64-apple-darwin1[34] after revision r216305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63622 --- Comment #11 from howarth at bromo dot med.uc.edu --- It looks like we aren't compiling some object files in libstdc++-v3/src/c++98 for gcc trunk which are are on gcc 4.9.2. In particular, we are missing... ctype.o ctype_configure_char.o ctype_members.o ios-inst.o ios.o iostream-inst.o istream-inst.o ostream-inst.o sstream-inst.o streambuf-inst.o
[Bug bootstrap/57125] Build not SMP safe; fails to build bconfig.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57125 dev at codyps dot com changed: What|Removed |Added CC||dev at codyps dot com --- Comment #7 from dev at codyps dot com --- I'm seeing this with gentoo's gcc-4.9.2
[Bug bootstrap/63622] [5.0 Regression] Bootstrap fails on x86_64-apple-darwin1[34] after revision r216305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63622 --- Comment #12 from howarth at bromo dot med.uc.edu --- This looks like fallout from... https://gcc.gnu.org/ml/libstdc++-cvs/2014-q4/msg00080.html https://gcc.gnu.org/ml/libstdc++-cvs/2014-q3/msg00181.html where the files moved to c++11 in gcc trunk from c++98 in gcc 4.9.2 now have undefined symbols... [MacPro:libstdc++-v3/src/c++11] howarth% nm streambuf-inst.o | grep ZNSt15basic_streambufIcSt11char_traitsIcEE9underflowEv U __ZNSt15basic_streambufIcSt11char_traitsIcEE9underflowEv compared to gcc 4.9.2 [MacPro:libstdc++-v3/src/c++98] howarth% nm streambuf-inst.o | grep ZNSt15basic_streambufIcSt11char_traitsIcEE9underflowEv 0040 T __ZNSt15basic_streambufIcSt11char_traitsIcEE9underflowEv Were these checkins made after darwin stopped bootstrapping?
[Bug c++/63757] New: nullptr conversion sequence fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63757
Bug ID: 63757
Summary: nullptr conversion sequence fails to compile
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: R.HL at gmx dot net
This code
#include cstddef
void bar(void*) {}
struct foo
{
operator std::nullptr_t()
{
return nullptr;
}
};
int main()
{
bar(foo());
}
Does not compile with GCC 4.9.1 (neither -std=c++11 nor =c++14). However, it
should; There is one user defined conversion sequence inherent, consisting of
one standard conversion sequence converting nullptr to nullptr_t (which is a
pointer conversion, specifically a null pointer conversion), one user defined
conversion through the conversion operator function and a second standard
conversion sequence converting nullptr_t to void* (Which is also a pointer
conversion).
[Bug c++/63757] nullptr conversion sequence fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63757 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-05 Ever confirmed|0 |1
[Bug driver/36312] should refuse to overwrite input file with output file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36312 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #12 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Unfortunately, the patch broke Ada: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00368.html so I have reverted it.
[Bug c/63751] ICE in tree_to_uhwi, at tree.h:3668
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63751 --- Comment #2 from Matthias Klose doko at gcc dot gnu.org --- and it needed r211910, found after a first build.
[Bug other/63758] New: liblto_plugin.so has undefined reference to _environ on OSX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63758 Bug ID: 63758 Summary: liblto_plugin.so has undefined reference to _environ on OSX Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: roland at gnu dot org Host: x86_64-apple-darwin Build: x86_64-apple-darwin11.4.2 Failure mode: .../bin/../lib/gcc/.../4.9.2/../../../../.../bin/ld: .../bin/../libexec/gcc/.../4.9.2/liblto_plugin.so: error loading plugin: dlopen(.../bin/../libexec/gcc/.../4.9.2/liblto_plugin.so, 2): Symbol not found: _environ Referenced from: .../bin/../libexec/gcc/.../4.9.2/liblto_plugin.so Expected in: flat namespace in .../bin/../libexec/gcc/.../4.9.2/liblto_plugin.so collect2:error: ld returned 1 exit status The references come from libiberty code (xmalloc.c and pex-unix.c). Using environ in a main program is fine, but it's documented on OSX that you cannot use it from a shared library. Instead, you must call the _NSGetEnviron function to return its address (which also works just as well in a main program). I have a working fix which I'll attach shortly.
[Bug other/63758] liblto_plugin.so has undefined reference to _environ on OSX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63758 --- Comment #1 from roland at gnu dot org --- Created attachment 33903 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33903action=edit proposed patch This patch fixes it on OSX. I haven't verified it on a wide variety of configurations.
[Bug bootstrap/63622] [5.0 Regression] Bootstrap fails on x86_64-apple-darwin1[34] after revision r216305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63622 --- Comment #13 from howarth at bromo dot med.uc.edu --- Created attachment 33904 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33904action=edit preprocessed source for libstdc++-v3/src/c++11/streambuf-inst.cc
[Bug bootstrap/63622] [5.0 Regression] Bootstrap fails on x86_64-apple-darwin1[34] after revision r216305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63622 --- Comment #14 from howarth at bromo dot med.uc.edu --- The attached preprocessed source was produced from gcc trunk with... # /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./gcc/xgcc -shared-libgcc -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./gcc -nostdinc++ -L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin14.0.0/libstdc++-v3/src -L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin14.0.0/libstdc++-v3/src/.libs -L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin14.0.0/libstdc++-v3/libsupc++/.libs -B/sw/lib/gcc5.0/x86_64-apple-darwin14.0.0/bin/ -B/sw/lib/gcc5.0/x86_64-apple-darwin14.0.0/lib/ -isystem /sw/lib/gcc5.0/x86_64-apple-darwin14.0.0/include -isystem /sw/lib/gcc5.0/x86_64-apple-darwin14.0.0/sys-include -I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141105/libstdc++-v3/../libgcc -I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin14.0.0/libstdc++-v3/include/x86_64-apple-darwin14.0.0 -I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin14.0.0/libstdc++-v3/include -I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141105/libstdc++-v3/libsupc++ -I/sw/include -std=gnu++11 -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -fvisibility-inlines-hidden -ffunction-sections -fdata-sections -frandom-seed=streambuf-inst.lo -g -O2 -c ../../../../../gcc-5.0-20141105/libstdc++-v3/src/c++11/streambuf-inst.cc -fno-common -DPIC -D_GLIBCXX_SHARED -o streambuf-inst.o --save-temps which produces as set of warnings that don't appear in the build of libstdc++-v3/src/c++98/streambuf-inst.cc. These are... ./../../../../gcc-5.0-20141105/libstdc++-v3/src/c++11/streambuf-inst.cc:63:1: warning: alias definitions not supported in Mach-O; ignored } // namespace ^ ../../../../../gcc-5.0-20141105/libstdc++-v3/src/c++11/streambuf-inst.cc:63:1: warning: alias definitions not supported in Mach-O; ignored ../../../../../gcc-5.0-20141105/libstdc++-v3/src/c++11/streambuf-inst.cc:63:1: warning: alias definitions not supported in Mach-O; ignored ../../../../../gcc-5.0-20141105/libstdc++-v3/src/c++11/streambuf-inst.cc:63:1: warning: alias definitions not supported in Mach-O; ignored ../../../../../gcc-5.0-20141105/libstdc++-v3/src/c++11/streambuf-inst.cc:63:1: warning: alias definitions not supported in Mach-O; ignored ../../../../../gcc-5.0-20141105/libstdc++-v3/src/c++11/streambuf-inst.cc:63:1: warning: alias definitions not supported in Mach-O; ignored ../../../../../gcc-5.0-20141105/libstdc++-v3/src/c++11/streambuf-inst.cc:63:1: warning: alias definitions not supported in Mach-O; ignored ../../../../../gcc-5.0-20141105/libstdc++-v3/src/c++11/streambuf-inst.cc:63:1: warning: alias definitions not supported in Mach-O; ignored ../../../../../gcc-5.0-20141105/libstdc++-v3/src/c++11/streambuf-inst.cc:63:1: warning: alias definitions not supported in Mach-O; ignored ../../../../../gcc-5.0-20141105/libstdc++-v3/src/c++11/streambuf-inst.cc:63:1: warning: alias definitions not supported in Mach-O; ignored
[Bug c++/63759] New: did not use DW_TAG_template_alias for template alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63759 Bug ID: 63759 Summary: did not use DW_TAG_template_alias for template alias Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: chihin.ko at oracle dot com Created attachment 33905 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33905action=edit test case For attached test case t.cc, g++ did not generate appropriate debug info for template alias, instead it used DW_TAG_typedef : /net/dv104/export/tools/gcc/4.9.0/$VARIANT1/bin/g++ -m64 -std=c++11 -Xlinker -R/net/dv104/export/tools/gcc/4.9.0/$VARIANT1/lib/amd64 t.cc 00x000b DW_TAG_compile_unit DW_AT_producer GNU C++ 4.9.0 -m64 -mtune=generic -march=x86-64 -g -std=c++11 DW_AT_language DW_LANG_C_plus_plus DW_AT_name t.cc ... ... 10x4a55DW_TAG_typedef DW_AT_name PrintStr DW_AT_decl_file 0x0001 .../gnu/intel-Linux/t.cc DW_AT_decl_line 0x0010 DW_AT_type 0x44b8 Here is the DWARF4 doc for DW_TAG_template_alias http://www.dwarfstd.org/ShowIssue.php?issue=090112.1
[Bug tree-optimization/63747] [5 regression] icf mis-compares switch gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63747
--- Comment #2 from Joey Ye joey.ye at arm dot com ---
/* { dg-options -O2 } */
/* { dg-do run } */
static int __attribute__((noinline))
foo(int i)
{
switch (i)
{
case 0:
case 1:
case 2:
case 3:
return 0;
default:
return 1;
}
}
static int __attribute__((noinline))
bar(int i)
{
switch (i)
{
case 4:
case 5:
case 6:
case 7:
return 0;
default:
return 1;
}
}
int main()
{
return foo(0) + bar(4);
}
[Bug tree-optimization/63747] [5 regression] icf mis-compares switch gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63747 --- Comment #3 from Joey Ye joey.ye at arm dot com --- Created attachment 33906 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33906action=edit /home/joeye01/patches/icf-switch-testcase-141105.patch Test case patch
[Bug tree-optimization/63747] [5 regression] icf mis-compares switch gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63747 --- Comment #4 from Joey Ye joey.ye at arm dot com --- It actually fails on all targets.
