[Bug rtl-optimization/64477] New: x86 sse unnecessary GPR spill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64477
Bug ID: 64477
Summary: x86 sse unnecessary GPR spill
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zoltan at hidvegi dot com
typedef signed char v16si __attribute__ ((vector_size (16)));
v16si ary(signed char a)
{
return v16si{a,a,a,a,a,a,a,a,a,a,a,a,a,a,a,a};
}
Compiled with g++-4.9 -m64 -O2 -fomit-frame-pointer -Wall -I$HOME/dev/common
-mssse3 -std=gnu++11 -S xmm_test.C
I get
pxor%xmm1, %xmm1
movd%edi, %xmm0
movl%edi, -12(%rsp)
pshufb %xmm1, %xmm0
ret
Note the unnecessary spill of edi, with gcc-4.8 this does not happen, so you
may consider this a regression. I think this may happen because it first tries
to move from gpr to xmm via the stack, but later optimizes to a direct gpr to
xmm move, but the stack spill stays.
When using -march=corei7-avx and 4x4 int vector, gcc-4.9 uses store to stack
and vbroadcastss instead of movd and pshufd $0, %xmm1, %xmm0 used by gcc-4.8,
again gcc-4.8 seems better to me. But even gcc-4.8 goes through the stack in
that case with -mtune=generic
[Bug fortran/63552] [OOP] Type-bound procedures rejected as actual argument to dummy procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63552 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org --- Comment #5 from janus at gcc dot gnu.org --- (In reply to janus from comment #3) This draft patch gets rid of the error and regtests cleanly: Unfortunately this patch is far from complete. What needs to be done is to use the PPC component of the vtab in the actual-argument expression. There are two cases to be handled: Polymorphic and non-polymorphic variables. Here is a test case without CO_REDUCE, which covers both cases: module m type t contains procedure, nopass :: tbp = f end type contains pure integer function f(a,b) integer, intent(in) :: a,b f = a+b end function end module use m integer :: a class(t), allocatable :: x type(t) :: y call sub(x%tbp) call sub(y%tbp) contains subroutine sub(arg) procedure(f) :: arg print *,f(1,2) end subroutine end I'm working on a patch.
[Bug libstdc++/64476] New: std::uninitialized_copy tests assignability the wrong way, resulting in performance pessimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64476 Bug ID: 64476 Summary: std::uninitialized_copy tests assignability the wrong way, resulting in performance pessimization Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: gcc-bugzilla at contacts dot eelis.net It does: typedef typename iterator_traits_InputIterator::reference _RefType; const bool __assignable = is_assignable_ValueType1, _RefType::value; but should do: typedef typename iterator_traits_ForwardIterator::reference _RefType; const bool __assignable = is_assignable_RefType, _ValueType1::value;
[Bug target/64461] bad assembly generated for Coldfire targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64461 --- Comment #5 from Joel Sherrill joel at gcc dot gnu.org --- (In reply to Andreas Schwab from comment #4) The easiest fix is to disable the three trunc patterns for the coldfire. This isn't my area of expertise. That's why I focused in on doing the git bisect. Hoped it would help someone else. If you provide a patch, I am more than happy to test it.
[Bug target/51192] h8300 ICE building libgcov.c in int_mode_for_mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51192 Joel Sherrill joel at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Joel Sherrill joel at gcc dot gnu.org --- Given a patch claiming to fix this was committed and this doesn't seem to be happening anymore, I am closing this.
[Bug target/54747] config/bfin/bfin.c:2721: possible missing break ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54747 Joel Sherrill joel at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Joel Sherrill joel at gcc dot gnu.org --- Closing. Bernd was OK with the code and I don't see anyway to check this again.
[Bug libffi/14554] libffi: ASM error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14554 Joel Sherrill joel at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||joel at gcc dot gnu.org Resolution|--- |WORKSFORME --- Comment #1 from Joel Sherrill joel at gcc dot gnu.org --- Ancient PR. Can't reproduce now. Closing.
[Bug middle-end/36828] 4.3.1 when optimising for size generates much larger code than 4.0.x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36828 --- Comment #4 from Joel Sherrill joel at gcc dot gnu.org --- Based on the last comment, should this PR be closed. It has been five years.
[Bug ada/14538] *-rtems broken for gnat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14538 Bug 14538 depends on bug 14436, which changed state. Bug 14436 Summary: ICE building libgcc.a https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14436 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX
[Bug target/63949] Aarch64 instruction combiner does not optimize subsi_sxth function as expected (gcc.target/aarch64/extend.c fails)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63949
--- Comment #7 from vekumar at gcc dot gnu.org ---
I ran GCC tests against the patch found one failure.
int
adds_shift_ext ( long long a, int b, int c)
{
long long d = (a + ((long long)b 3));
if (d == 0)
return a + c;
else
return b + d + c;
}
The test expects adds generation and before my fix it is generated .
adds_shift_ext:
addsx3, x0, x1, sxtw 3 // 11 *adds_extvdi_multp2 [length
= 4]
beq .L5 // 12 *condjump [length = 4]
But now I am generating sign extends with shifts instead of sign extends with
mul in my patch.
adds_shift_ext:
add x3, x0, x1, sxtw 3 // 10 *add_extendsi_shft_di [length
= 4]
cbz x3, .L5 // 12 *cbeqdi1[length = 4]
We don't have *adds_extendsi_shft_di pattern. We have patterns for
adds_extvdi_multp2 that extends an operation over mult.
Adding one will help optimize this case. But my concern is what if other
targets hits the same issue?
[Bug fortran/64474] New: transfer(c_null_ptr, ...) causes an internal error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64474 Bug ID: 64474 Summary: transfer(c_null_ptr, ...) causes an internal error Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: arjen.markus895 at gmail dot com I needed to pass a null pointer from Fortran to C. One attempt to do so was via code like this: module myinterfaces use iso_c_binding implicit none interface subroutine croutine( array ) bind(c,name='croutine') real, dimension(*) :: array end subroutine end interface contains subroutine myroutine real, dimension(1) :: dummy call croutine( transfer(c_null_ptr, dummy) ) end subroutine myroutine end module myinterfaces This causes an internal error: f951: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug target/62084] [avr] ICE: in convert_debug_memory_address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62084 Senthil Kumar Selvaraj senthil_kumar.selvaraj at atmel dot com changed: What|Removed |Added CC||senthil_kumar.selvaraj@atme ||l.com --- Comment #5 from Senthil Kumar Selvaraj senthil_kumar.selvaraj at atmel dot com --- Not reproducible with the latest trunk build (gcc version 5.0.0 20150102)
[Bug web/64468] Incorrect indentation in Doxygen-generated sources of libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64468 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-01-02 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1
[Bug ipa/64472] FAIL: gcc.dg/ipa/inline-7.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64472 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-02 CC||hjl.tools at gmail dot com Ever confirmed|0 |1 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com --- It also happens on x86.
[Bug fortran/60507] Passing function call into procedure argument not caught
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60507 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from janus at gcc dot gnu.org --- Fixed with r219141. Closing. Thanks for the report!
[Bug fortran/58175] [OOP] Incorrect warning message on scalar finalizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58175 patnel97269-gfortran at yahoo dot fr changed: What|Removed |Added CC||patnel97269-gfortran@yahoo. ||fr --- Comment #4 from patnel97269-gfortran at yahoo dot fr --- I still have this bug in 4.9.2 . Why not committing the patch ?
[Bug middle-end/64465] [5 Regression] internal compiler error: verify_flow_info failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64465 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 CC||jakub at gcc dot gnu.org
[Bug libstdc++/64475] New: [5.0 Regression] FAIL: 28_regex/algorithms/regex_match/ecma/char/backref.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64475 Bug ID: 64475 Summary: [5.0 Regression] FAIL: 28_regex/algorithms/regex_match/ecma/char/backref.cc Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: belagod at gcc dot gnu.org backref regresses on AArch64. PASS-FAIL: 28_regex/algorithms/regex_match/ecma/char/backref.cc execution test $ .../builds/fsf-trunk/fsf-trunk.597/workdir/rhe5x86_64/aarch64-none-linux-gnu/obj/gcc4/./gcc/xg++ shared-libgcc -B.../builds/fsf-trunk/fsf-trunk.597/workdir/rhe5x86_64/aarch64-none-linux-gnu/obj/gcc4/./gcc -nostdinc++ -L.../builds/fsf-trunk/fsf-trunk.597/workdir/rhe5x86_64/aarch64-none-linux-gnu/obj/gcc4/aarch64-none-linux-gnu/libstdc+-v3/src -L.../builds/fsf-trunk/fsf-trunk.597/workdir/rhe5x86_64/aarch64-none-linux-gnu/obj/gcc4/aarch64-none-linux-gnu/libstdc-v3/src/.libs -L.../builds/fsf-trunk/fsf-trunk.597/workdir/rhe5x86_64/aarch64-none-linux-gnu/obj/gcc4/aarch64-none-linux-gnu/libstdc-v3/libsupc/.libs -B/aarch64-none-linux-gnu/bin/ -B/aarch64-none-linux-gnu/lib/ -isystem /aarch64-none-linux-gnu/include -isystem /aarch64-none-linux-gnu/sys-include -B.../builds/fsf-trunk/fsf-trunk.597/workdir/rhe5x86_64/aarch64-none-linux-gnu/obj/gcc4/aarch64-none-linux-gnu/./libstdc-v3/src/.libs -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -DLOCALEDIR=. -nostdinc+ -I.../builds/fsf-trunk/fsf-trunk.597/workdir/rhe5x86_64/aarch64-none-linux-gnu/obj/gcc4/aarch64-none-linux-gnu/libstdc+-v3/include/aarch64-none-linux-gnu -I.../builds/fsf-trunk/fsf-trunk.597/workdir/rhe5x86_64/aarch64-none-linux-gnu/obj/gcc4/aarch64-none-linux-gnu/libstdc-v3/include -I.../fsf-trunk/builds/fsf-trunk.597/src/gcc/libstdc-v3/libsupc+ -I.../fsf-trunk/builds/fsf-trunk.597/src/gcc/libstdc+-v3/include/backward -I.../fsf-trunk/builds/fsf-trunk.597/src/gcc/libstdc-v3/testsuite/util .../fsf-trunk/builds/fsf-trunk.597/src/gcc/libstdc-v3/testsuite/28_regex/algorithms/regex_match/ecma/char/backref.cc -std=gnu11 ./libtestc+.a -Wl,-gc-sections -lm -o ./backref.exe^M PASS: 28_regex/algorithms/regex_match/ecma/char/backref.cc (test for excess errors) backref.exe: .../fsf-trunk/builds/fsf-trunk.597/src/gcc/libstdc++-v3/testsuite/28_regex/algorithms/regex_match/ecma/char/backref.cc:43: void test01(): Assertion `m[0].matched' failed.^M FAIL: 28_regex/algorithms/regex_match/ecma/char/backref.cc execution test
[Bug c++/64422] basic_string::erase is unresloved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64422 --- Comment #4 from Bernd Edlinger edlinger at gcc dot gnu.org --- Author: edlinger Date: Fri Jan 2 21:12:54 2015 New Revision: 219149 URL: https://gcc.gnu.org/viewcvs?rev=219149root=gccview=rev Log: 2015-01-02 Bernd Edlinger bernd.edlin...@hotmail.de PR libstdc++/64422 * src/c++98/misc-inst.cc (string::erase): Add missing overloads. (string::insert): Likewise. (string::replace): Likewise. (wstring::erase): Likewise. (wstring::insert): Likewise. (wstring::replace): Likewise. * testsuite/21_strings/basic_string/modifiers/64422.cc: New testcase. Added: trunk/libstdc++-v3/testsuite/21_strings/basic_string/modifiers/64422.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/src/c++98/misc-inst.cc
[Bug target/47540] ARM THUMB crash with complex numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47540 Joel Sherrill joel at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Joel Sherrill joel at gcc dot gnu.org --- Based on Sebastian's last comment, I am marking this as resolved/fixed.
[Bug libstdc++/64475] [5.0 Regression] FAIL: 28_regex/algorithms/regex_match/ecma/char/backref.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64475 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- The fix has already been posted and approved: https://gcc.gnu.org/ml/libstdc++/2015-01/msg1.html
[Bug libstdc++/64475] [5.0 Regression] FAIL: 28_regex/algorithms/regex_match/ecma/char/backref.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64475 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Yes it fails everywhere, but this one is nothing to do with me :)
[Bug c++/64422] basic_string::erase is unresloved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64422 Bernd Edlinger bernd.edlinger at hotmail dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Bernd Edlinger bernd.edlinger at hotmail dot de --- .
[Bug tree-optimization/64454] optimize (x%5)%5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64454 --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org --- Folding (x%y)y (with unsigned) would help as well. VRP already handles the case where y is a constant.
[Bug libstdc++/64475] [5.0 Regression] FAIL: 28_regex/algorithms/regex_match/ecma/char/backref.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64475 --- Comment #1 from Tejas Belagod belagod at gcc dot gnu.org --- Fails on AArch32 too.
[Bug target/64461] bad assembly generated for Coldfire targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64461 --- Comment #1 from Joel Sherrill joel at gcc dot gnu.org --- Doing a git bisect showed this to be the commit that broke things. Clearly not m68k specific but triggered it. commit 91ae0791cbebaac673e42e53c8b7f000241a0ca1 Author: dj dj@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Fri Aug 29 23:19:42 2014 + * expr.c (convert_move): If the target has an explicit converter, use it. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@214747 138bc75d-0d04-0410-961f-82ee72b054a4 The full git bisect log is: # bad: [6c13ec429c328b934e9f67d5cd6f5ab55e17ce73] 2015-01-02 Tobias Burnus bur...@net-b.de # good: [8edc9ee53be8854228d20569eee719a01a4001de] 2014-07-18 Bernd Edlinger bernd.edlin...@hotmail.de git bisect start 'HEAD' '8edc9ee53be8854228d20569eee719a01a4001de' # bad: [2dd9fd37811882a2c5cdcd0880c20e507256e10f] 2014-10-10 Yannick Moy m...@adacore.com git bisect bad 2dd9fd37811882a2c5cdcd0880c20e507256e10f # good: [1d8a14f043cccdaeee0a0782560a398a902e15cf] Daily bump. git bisect good 1d8a14f043cccdaeee0a0782560a398a902e15cf # bad: [e3b7afcb34c7c4d4cd2f876e83fc2c90c2eeaae6] 2014-09-11 Segher Boessenkool seg...@kernel.crashing.org git bisect bad e3b7afcb34c7c4d4cd2f876e83fc2c90c2eeaae6 # bad: [67e0a76ed4c526001119ad5d78f49f2cb2f780a0] Fix typo. git bisect bad 67e0a76ed4c526001119ad5d78f49f2cb2f780a0 # good: [ae799283c5ecc25191575fb5ec2bc16d97674437] Use rtx_expr_list for expr_status.x_forced_labels git bisect good ae799283c5ecc25191575fb5ec2bc16d97674437 # good: [8c409b9147aa9f2c536bffe1db93e30ac740d99c] AVX-512. Support 512-bit/masked interleave. git bisect good 8c409b9147aa9f2c536bffe1db93e30ac740d99c # good: [c1920e9db30af5043bdc942cfdf374b832687ee4] 2014-08-29 Richard Biener rguent...@suse.de git bisect good c1920e9db30af5043bdc942cfdf374b832687ee4 # good: [6843b812545c8f94708624f6332ea3873cc952fc] PR 62215 Reinstate unlinking old module file before renaming. git bisect good 6843b812545c8f94708624f6332ea3873cc952fc # bad: [1c0165c81ccfbe4fbadd96ac8b85c59a0002cab6] * config/pa/pa.c (pa_assemble_integer): Don't add PLABEL relocation prefix to function labels when generating fast indirect calls. git bisect bad 1c0165c81ccfbe4fbadd96ac8b85c59a0002cab6 # bad: [4765975cb2f85d61e801d12562b39da2d1e25f2c] * cppbuiltin.c (define_builtin_macros_for_type_sizes): Round pointer size up to a power of two. * defaults.h (DWARF2_ADDR_SIZE): Round up. (POINTER_SIZE_UNITS): New, rounded up value. * dwarf2asm.c (size_of_encoded_value): Use it. (dw2_output_indirect_constant_1): Likewise. * expmed.c (init_expmed_one_conv): We now know the sizes of partial int modes. * loop-iv.c (iv_number_of_iterations): Use precision, not size. * optabs.c (expand_float): Use precision, not size. (expand_fix): Likewise. * simplify-rtx (simplify_unary_operation_1): Likewise. * tree-dfa.c (get_ref_base_and_extent): Likewise. * varasm.c (assemble_addr_to_section): Round up pointer sizes. (default_assemble_integer) Likewise. (dump_tm_clone_pairs): Likewise. * dwarf2out.c (mem_loc_descriptor): Allow partial-int modes also. * var-tracking.c (adjust_mems): Allow partial-int modes also. (prepare_call_arguments): Likewise. * stor-layout.c (finalize_type_size): Preserve precision. (layout_type): Use precision, not size. git bisect bad 4765975cb2f85d61e801d12562b39da2d1e25f2c # good: [9f30a5e055e777cdb28fd391c34ec8f3cd80a4d6] * lib/target-supports.exp (check_effective_target_size32plus): Increase size to avoid false positives on 24-bit address spaces. * gcc.c-torture/compile/limits-stringlit.c: Skip if msp430. * gcc.dg/lto/pr54709_1.c: Fix memcpy prototype. * gcc.dg/torture/pta-ptrarith-3.c: Use __SIZE_TYPE__ instead of int. * gcc.dg/torture/pr36373-10.c: Use __SIZE_TYPE__ if present. * gcc.dg/torture/pr57864.c: Use __SIZE_TYPE__. * gcc.dg/torture/pr26763-2.c: Use __SIZE_TYPE__ instead of int. * gcc.dg/tree-ssa/isolate-3.c: Use __SIZE_TYPE__ instead of long unsigned int. * gcc.dg/pr52549.c: Use __SIZE_TYPE__ if present. git bisect good 9f30a5e055e777cdb28fd391c34ec8f3cd80a4d6 # bad: [91ae0791cbebaac673e42e53c8b7f000241a0ca1] * expr.c (convert_move): If the target has an explicit converter, use it. git bisect bad 91ae0791cbebaac673e42e53c8b7f000241a0ca1 # first bad commit: [91ae0791cbebaac673e42e53c8b7f000241a0ca1] * expr.c (convert_move): If the target has an explicit converter, use it.
[Bug fortran/64474] [4.8 Regression] transfer(c_null_ptr, ...) causes an internal error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64474 --- Comment #2 from Arjen Markus arjen.markus895 at gmail dot com --- Hi Janus, thanks for looking into this. Personally, I have no problem moving to version 4.9. It's just that I ran into the problem. Regards, Arjen 2015-01-02 16:28 GMT+01:00 janus at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64474 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-02 CC||janus at gcc dot gnu.org Summary|transfer(c_null_ptr, ...) |[4.8 Regression] |causes an internal error|transfer(c_null_ptr, ...) ||causes an internal error Ever confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org --- I see the ICE with 4.7.4 and 4.8.3, but it is gone with 4.9.1 and trunk. Also there is no ICE in 4.6.4, which technically makes it a regression. If we can identify the commit which fixed this in 4.9, it could be backported to 4.8. Btw, 4.7 and earlier show the warning: subroutine croutine( array ) bind(c,name='croutine') 1 Warning: Variable 'array' at (1) is a parameter to the BIND(C) procedure 'croutine' but may not be C interoperable -- You are receiving this mail because: You reported the bug.
[Bug fortran/63552] [OOP] Type-bound procedures rejected as actual argument to dummy procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63552 --- Comment #4 from janus at gcc dot gnu.org --- (In reply to janus from comment #3) For the commented-out line I get: call co_reduce(a,x%ppc) 1 2 Fehler: A argument at (1) has type INTEGER(4) but the function passed as OPERATOR at (2) returns REAL(4) (which I guess is diagnosed correctly?) Thus the test case is invalid. Here is a corrected version: module m type t procedure(f), pointer, nopass :: ppc contains procedure, nopass :: tbp = f end type contains pure integer function f(a,b) integer, intent(in) :: a,b f = 0 end function end module use m integer :: a type(t) :: x ! call co_reduce(a,f) ! call co_reduce(a,x%ppc) call co_reduce(a,x%tbp) end
[Bug libstdc++/64475] [5.0 Regression] FAIL: 28_regex/algorithms/regex_match/ecma/char/backref.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64475 --- Comment #4 from Tim Shen timshen at gcc dot gnu.org --- Author: timshen Date: Fri Jan 2 22:33:04 2015 New Revision: 219151 URL: https://gcc.gnu.org/viewcvs?rev=219151root=gccview=rev Log: PR libstdc++/64475 * include/bits/regex_executor.tcc (_Executor::_M_dfs): Copy the iterator, since the original one shouldn't be mutated. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/regex_executor.tcc
[Bug target/64461] bad assembly generated for Coldfire targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64461 --- Comment #2 from Joel Sherrill joel at gcc dot gnu.org --- Multiple BSPs trigger this on various files which is not a surprise seeing as it is generating an illegal memory to memory move. But in case it helps, this is the list of CPU CFLAGS of BSPs which trigger it. I really believe this is a breakage for all Coldfire variants though. -mcpu=5206 -mcpu=5235 -mcpu=5272 -mcpu=528x -mcpu=52235 -mcpu=5307 -mcfv4e -Wa,-memac
[Bug target/46586] Can't compile libiberty for bfin-elf target.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46586 Joel Sherrill joel at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #2 from Joel Sherrill joel at gcc dot gnu.org --- bfin-rtems and bfin-elf have not had this issue in ages. Closing for lack of feedback.
[Bug target/53314] m32r-rtems does not provide crtinit.o and crtfini.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53314 Joel Sherrill joel at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Joel Sherrill joel at gcc dot gnu.org --- I committed a fix for this in 2012 but this PR didn't get closed.
[Bug target/14436] ICE building libgcc.a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14436 Joel Sherrill joel at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||joel at gcc dot gnu.org Resolution|--- |WONTFIX Known to fail|| --- Comment #14 from Joel Sherrill joel at gcc dot gnu.org --- CPU long dead. Target removed from GCC long ago. Closing as won't fix.
[Bug target/64461] bad assembly generated for Coldfire targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64461 --- Comment #3 from Andreas Schwab sch...@linux-m68k.org --- It is using truncsiqi2, but that pattern hasn't been adjusted for coldfire.
[Bug target/64461] bad assembly generated for Coldfire targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64461 --- Comment #4 from Andreas Schwab sch...@linux-m68k.org --- The easiest fix is to disable the three trunc patterns for the coldfire.
[Bug ada/64478] Ada Exception handlers call signal-unsafe malloc/free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478 --- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Bernd Edlinger from comment #5) but I cant see why a potential deadlock in an exception handler is not a bug? Actually here is what glibc says about malloc: Function: void * malloc (size_t size) Preliminary: | MT-Safe | AS-Unsafe lock | AC-Unsafe lock fd mem | See POSIX Safety Concepts. But this is a non-Async-Signal here we are talking about so this is safe and a bug in tsan for not realizing that.
[Bug c++/61135] It seems to be not able to call virtual method of literal object in lambda expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61135 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #5 from Kai Tietz ktietz at gcc dot gnu.org --- No, I can still reproduce the ICE in make_decl_rtl, at varasm.c:1297 #2 0x007ae6e2 in make_decl_rtl (decl=decl@entry=0xffe80160) at ../../gcc/gcc/varasm.c:1293 #3 0x007fa975 in expand_expr_real_1 (exp=0xffe80160, target=optimized out, tmode=DImode, modifier=EXPAND_CONST_ADDRESS, alt_rtl=0x0, inner_reference_p=false) at ../../gcc/gcc/expr.c:9563 #4 0x008065d5 in expand_expr (modifier=optimized out, mode=DImode, target=0xfff670a0, exp=0xffe80160) at ../../gcc/gcc/expr.h:299 #5 expand_expr_addr_expr_1 (exp=exp@entry=0xffe80160, target=target@entry=0xfff670a0, tmode=tmode@entry=DImode, modifier=modifier@entry=EXPAND_NORMAL, as=as@entry=0 '\000') at ../../gcc/gcc/expr.c:7704 #6 0x008067f5 in expand_expr_addr_expr_1 (exp=optimized out, target=target@entry=0xfff670a0, tmode=tmode@entry=DImode, modifier=modifier@entry=EXPAND_NORMAL, as=as@entry=0 '\000') at ../../gcc/gcc/expr.c:7756 #7 0x007f7222 in expand_expr_addr_expr (modifier=EXPAND_NORMAL, tmode=DImode, target=0xfff670a0, exp=0xffe3fd20) at ../../gcc/gcc/expr.c:7832 #8 expand_expr_real_1 (exp=0xffe3fd20, target=optimized out, tmode=DImode, modifier=EXPAND_NORMAL, alt_rtl=0xdeca688, inner_reference_p=false) at ../../gcc/gcc/expr.c:10706 #9 0x00807334 in store_expr_with_bounds (exp=exp@entry=0xffe3fd20, target=target@entry=0xfff670a0, call_param_p=call_param_p@entry=0, nontemporal=nontemporal@entry=false, btarget=btarget@entry=0xffe45ca8) at ../../gcc/gcc/expr.c:5368 #10 0x008101f6 in expand_assignment (to=to@entry=0xffe45ca8, from=from@entry=0xffe3fd20, nontemporal=false) at ../../gcc/gcc/expr.c:5137 #11 0x00ddab15 in expand_gimple_stmt_1 (stmt=0xffdd09f0) at ../../gcc/gcc/cfgexpand.c:3351 #12 expand_gimple_stmt (stmt=stmt@entry=0xffdd09f0) at ../../gcc/gcc/cfgexpand.c:3447 #13 0x00ddcb6c in expand_gimple_basic_block (bb=0xfff81080, disable_tail_calls=disable_tail_calls@entry=false) at ../../gcc/gcc/cfgexpand.c:5280 #14 0x00ddeaad in (anonymous namespace)::pass_expand::execute ( this=0x80056948, fun=0xfff303a8) at ../../gcc/gcc/cfgexpand.c:5889 #15 0x0090d285 in execute_one_pass (pass=pass@entry=0x80056948) at ../../gcc/gcc/passes.c:2311 #16 0x0090d714 in execute_pass_list_1 (pass=0x80056948, pass@entry=0x80054848) ...
[Bug c/64470] New: “floating constant exceeds range” warning for constants that should fit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64470 Bug ID: 64470 Summary: “floating constant exceeds range” warning for constants that should fit Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tg at mirbsd dot org From what I understand, 0x1.0p1024 (and 1E1024 which also warns) should fit into a “double” if __DBL_MAX_EXP__ is 1024. This is a reduced testcase; the original problem used 0x1.0p1024L but __LDBL_MAX_EXP__ on ARM is also 1024. (sid-amd64)tglase@tglase:~ $ cat x.c double foo = 0x1.0p1024; (sid-amd64)tglase@tglase:~ $ /usr/lib/gcc-snapshot/bin/gcc -Woverflow -c x.c x.c:1:1: warning: floating constant exceeds range of 'double' [-Woverflow] double foo = 0x1.0p1024; ^ (sid-amd64)tglase@tglase:~ $ /usr/lib/gcc-snapshot/bin/gcc --version gcc (Debian 20141218-1) 5.0.0 20141218 (experimental) [trunk revision 218861] Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. (sid-amd64)tglase@tglase:~ $ :| /usr/lib/gcc-snapshot/bin/gcc -E -dD - | fgrep DBL_MAX_EXP #define __DBL_MAX_EXP__ 1024 #define __LDBL_MAX_EXP__ 16384 This warning is spewn in libc/stdio/_fpmaxtostr.c in µClibc-ng, which we’re trying to get to build warning-free at the moment.
[Bug fortran/57562] [OOP] ICE due to extended derived type with PARAMETER attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57562
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org
--- Comment #7 from janus at gcc dot gnu.org ---
The patch in comment 5 is far from complete. Here is a new version, which
should be much better. It regtests cleanly and works with all three variants of
the test case in this PR.
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c(Revision 219140)
+++ gcc/fortran/expr.c(Arbeitskopie)
@@ -1270,12 +1270,23 @@ depart:
static gfc_constructor *
find_component_ref (gfc_constructor_base base, gfc_ref *ref)
{
- gfc_component *comp;
- gfc_component *pick;
+ gfc_component *pick = ref-u.c.component;
gfc_constructor *c = gfc_constructor_first (base);
- comp = ref-u.c.sym-components;
- pick = ref-u.c.component;
+ gfc_symbol *dt = ref-u.c.sym;
+ int ext = dt-attr.extension;
+
+ /* For extended types, check if the desired component is in one of the
+ * parent types. */
+ while (ext0 gfc_find_component (dt-components-ts.u.derived,
pick-name,
+ true, true))
+{
+ dt = dt-components-ts.u.derived;
+ c = gfc_constructor_first (c-expr-value.constructor);
+ ext--;
+}
+
+ gfc_component *comp = dt-components;
while (comp != pick)
{
comp = comp-next;
[Bug fortran/60507] Passing function call into procedure argument not caught
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60507 --- Comment #7 from janus at gcc dot gnu.org --- Author: janus Date: Fri Jan 2 11:24:32 2015 New Revision: 219141 URL: https://gcc.gnu.org/viewcvs?rev=219141root=gccview=rev Log: 2015-01-02 Janus Weil ja...@gcc.gnu.org PR fortran/60507 * interface.c (is_procptr_result): New function to check if an expression is a procedure-pointer result. (compare_actual_formal): Use it. 2015-01-02 Janus Weil ja...@gcc.gnu.org PR fortran/60507 * gfortran.dg/dummy_procedure_11: New. Added: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/ChangeLog-2014 - copied unchanged from r219140, trunk/gcc/fortran/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/ChangeLog-2014 - copied unchanged from r219140, trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/dummy_procedure_11.f90 Modified: trunk/gcc/fortran/interface.c
[Bug web/64471] New: 403 Forbidden on GCC 5 page
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64471 Bug ID: 64471 Summary: 403 Forbidden on GCC 5 page Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: tg at mirbsd dot org https://gcc.gnu.org/gcc-5/ Forbidden You don't have permission to access /gcc-5/ on this server. Apache Server at gcc.gnu.org Port 443 Since this page is linked from the front page, I’d expect it to work ;-)
[Bug c++/64455] A constexpr variable template can't be used with enable_if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64455
--- Comment #2 from Ville Voutilainen ville.voutilainen at gmail dot com ---
Reduced to avoid using type_traits:
templatetypename Type
constexpr bool IsType = true;
template bool b, class T struct Test
{
};
template class T
struct Testtrue, T
{
typedef T type;
};
templateclass T
struct X {
typedef typename TestIsTypeT,T::type type;
};
int main()
{
Xint::type t;
}
[Bug ipa/64472] New: FAIL: gcc.dg/ipa/inline-7.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64472 Bug ID: 64472 Summary: FAIL: gcc.dg/ipa/inline-7.c Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: belagod at gcc dot gnu.org This new test added by r219108 fails on AArch64. NA-FAIL: gcc.dg/ipa/inline-7.c scan-tree-dump-times einline Inlining a into m 1
[Bug c/64470] “floating constant exceeds range” warning for constants that should fit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64470
Andreas Schwab sch...@linux-m68k.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Andreas Schwab sch...@linux-m68k.org ---
0x1.0p1024 does *not* fit in IEEE double. The maximum finite value is (1 −
b^{−p})b^{e_{max}}.
[Bug ipa/64472] FAIL: gcc.dg/ipa/inline-7.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64472 --- Comment #1 from Tejas Belagod belagod at gcc dot gnu.org --- Only fails for -fPIC.
[Bug libstdc++/64473] New: libstdc++-v3 tests fail to link on AArch64 tiny memory model.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64473 Bug ID: 64473 Summary: libstdc++-v3 tests fail to link on AArch64 tiny memory model. Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: belagod at gcc dot gnu.org NA-UNRESOLVED: 22_locale/money_get/get/char/14.cc compilation failed to produce executable PASS-NA: 22_locale/money_get/get/char/14.cc execution test NA-UNRESOLVED: 22_locale/money_get/get/char/19.cc compilation failed to produce executable PASS-NA: 22_locale/money_get/get/char/19.cc execution test NA-UNRESOLVED: 22_locale/money_get/get/char/22131.cc compilation failed to produce executable PASS-NA: 22_locale/money_get/get/char/22131.cc execution test NA-UNRESOLVED: 22_locale/money_get/get/char/38399.cc compilation failed to produce executable PASS-NA: 22_locale/money_get/get/char/38399.cc execution test NA-UNRESOLVED: 22_locale/money_get/get/char/39168.cc compilation failed to produce executable PASS-NA: 22_locale/money_get/get/char/39168.cc execution test NA-UNRESOLVED: 22_locale/money_get/get/char/5.cc compilation failed to produce executable PASS-NA: 22_locale/money_get/get/char/5.cc execution test NA-UNRESOLVED: 22_locale/money_get/get/char/6.cc compilation failed to produce executable PASS-NA: 22_locale/money_get/get/char/6.cc execution test NA-UNRESOLVED: 22_locale/money_get/get/char/7.cc compilation failed to produce executable PASS-NA: 22_locale/money_get/get/char/7.cc execution test NA-UNRESOLVED: 22_locale/money_get/get/char/8.cc compilation failed to produce executable PASS-NA: 22_locale/money_get/get/char/8.cc execution test NA-UNRESOLVED: 22_locale/money_get/get/char/9.cc compilation failed to produce executable PASS-NA: 22_locale/money_get/get/char/9.cc execution test .../builds/fsf-trunk/fsf-trunk.597/workdir/rhe5x86_64/aarch64-none-elf/obj/gcc2/./gcc/xg++ -shared-libgcc -B.../builds/fsf-trunk/fsf-trunk.597/workdir/rhe5x86_64/aarch64-none-elf/obj/gcc2/./gcc -nostdinc++ -L.../builds/fsf-trunk/fsf-trunk.597/workdir/rhe5x86_64/aarch64-none-elf/obj/gcc2/aarch64-none-elf/libstdc++-v3/src -L.../builds/fsf-trunk/fsf-trunk.597/workdir/rhe5x86_64/aarch64-none-elf/obj/gcc2/aarch64-none-elf/libstdc++-v3/src/.libs -L.../builds/fsf-trunk/fsf-trunk.597/workdir/rhe5x86_64/aarch64-none-elf/obj/gcc2/aarch64-none-elf/libstdc++-v3/libsupc++/.libs -B.../fsf-trunk/builds/fsf-trunk.597/workdir/rhe5x86_64/aarch64-none-elf/install/aarch64-none-elf/bin/ -B.../fsf-trunk/builds/fsf-trunk.597/workdir/rhe5x86_64/aarch64-none-elf/install/aarch64-none-elf/lib/ -isystem .../fsf-trunk/builds/fsf-trunk.597/workdir/rhe5x86_64/aarch64-none-elf/install/aarch64-none-elf/include -isystem .../fsf-trunk/builds/fsf-trunk.597/workdir/rhe5x86_64/aarch64-none-elf/install/aarch64-none-elf/sys-include -B.../builds/fsf-trunk/fsf-trunk.597/workdir/rhe5x86_64/aarch64-none-elf/obj/gcc2/aarch64-none-elf/./libstdc++-v3/src/.libs -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2 -DLOCALEDIR=. -nostdinc++ -I.../builds/fsf-trunk/fsf-trunk.597/workdir/rhe5x86_64/aarch64-none-elf/obj/gcc2/aarch64-none-elf/libstdc++-v3/include/aarch64-none-elf -I.../builds/fsf-trunk/fsf-trunk.597/workdir/rhe5x86_64/aarch64-none-elf/obj/gcc2/aarch64-none-elf/libstdc++-v3/include -I.../fsf-trunk/builds/fsf-trunk.597/src/gcc/libstdc++-v3/libsupc++ -I.../fsf-trunk/builds/fsf-trunk.597/src/gcc/libstdc++-v3/include/backward -I.../fsf-trunk/builds/fsf-trunk.597/src/gcc/libstdc++-v3/testsuite/util .../fsf-trunk/builds/fsf-trunk.597/src/gcc/libstdc++-v3/testsuite/22_locale/num_get/get/char/39802.cc -include bits/stdc++.h ./libtestc++.a -specs=aem-ve.specs -lm -mcmodel=tiny -o ./39802.exe^M /tmp/44693373.0/ccdhamwV.o: In function `_GLOBAL__sub_I__Z6test01v':^M .../builds/fsf-trunk/fsf-trunk.597/workdir/rhe5x86_64/aarch64-none-elf/obj/gcc2/aarch64-none-elf/libstdc++-v3/include/iostream:74:(.text.startup._GLOBAL__sub_I__Z6test01v+0xc): relocation truncated to fit: R_AARCH64_ADR_PREL_LO21 against `.bss._ZStL8__ioinit'^M collect2: error: ld returned 1 exit status^M compiler exited with status 1 output is: /tmp/44693373.0/ccdhamwV.o: In function `_GLOBAL__sub_I__Z6test01v':^M .../builds/fsf-trunk/fsf-trunk.597/workdir/rhe5x86_64/aarch64-none-elf/obj/gcc2/aarch64-none-elf/libstdc++-v3/include/iostream:74:(.text.startup._GLOBAL__sub_I__Z6test01v+0xc): relocation truncated to fit: R_AARCH64_ADR_PREL_LO21 against `.bss._ZStL8__ioinit'^M collect2: error: ld returned 1 exit status^M UNSUPPORTED: ./39802.exe: memory full PASS: 22_locale/num_get/get/char/39802.cc (test for excess errors) UNRESOLVED: 22_locale/num_get/get/char/39802.cc compilation failed to produce executable extra_tool_flags are: -include bits/stdc++.h
[Bug fortran/64474] [4.8 Regression] transfer(c_null_ptr, ...) causes an internal error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64474 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-02 CC||janus at gcc dot gnu.org Summary|transfer(c_null_ptr, ...) |[4.8 Regression] |causes an internal error|transfer(c_null_ptr, ...) ||causes an internal error Ever confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org --- I see the ICE with 4.7.4 and 4.8.3, but it is gone with 4.9.1 and trunk. Also there is no ICE in 4.6.4, which technically makes it a regression. If we can identify the commit which fixed this in 4.9, it could be backported to 4.8. Btw, 4.7 and earlier show the warning: subroutine croutine( array ) bind(c,name='croutine') 1 Warning: Variable 'array' at (1) is a parameter to the BIND(C) procedure 'croutine' but may not be C interoperable
[Bug libstdc++/64438] Removing string-conversion requirement causes libstdc++-v3 fails on AArch64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64438 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Fri Jan 2 16:50:45 2015 New Revision: 219146 URL: https://gcc.gnu.org/viewcvs?rev=219146root=gccview=rev Log: PR libstdc++/64438 * testsuite/21_strings/basic_string/numeric_conversions/char/dr1261.cc: Revert removal of dg-require-string-conversions. * testsuite/21_strings/basic_string/numeric_conversions/char/stod.cc: Likewise. * testsuite/21_strings/basic_string/numeric_conversions/char/stof.cc: Likewise. * testsuite/21_strings/basic_string/numeric_conversions/char/stoi.cc: Likewise. * testsuite/21_strings/basic_string/numeric_conversions/char/stol.cc: Likewise. * testsuite/21_strings/basic_string/numeric_conversions/char/stold.cc: Likewise. * testsuite/21_strings/basic_string/numeric_conversions/char/stoll.cc: Likewise. * testsuite/21_strings/basic_string/numeric_conversions/char/stoul.cc: Likewise. * testsuite/21_strings/basic_string/numeric_conversions/char/ stoull.cc: Likewise. * testsuite/21_strings/basic_string/numeric_conversions/char/ to_string.cc: Likewise. Added: trunk/libstdc++-v3/ChangeLog Modified: trunk/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/dr1261.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stod.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stof.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stoi.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stol.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stold.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stoll.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stoul.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/stoull.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/char/to_string.cc
[Bug fortran/57562] [OOP] ICE due to extended derived type with PARAMETER attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57562 --- Comment #8 from janus at gcc dot gnu.org --- Author: janus Date: Fri Jan 2 16:31:52 2015 New Revision: 219144 URL: https://gcc.gnu.org/viewcvs?rev=219144root=gccview=rev Log: 2015-01-02 Janus Weil ja...@gcc.gnu.org PR fortran/57562 * expr.c (find_component_ref): Deal with extended types. 2015-01-02 Janus Weil ja...@gcc.gnu.org PR fortran/57562 * gfortran.dg/extends_16.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/extends_16.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog
[Bug web/64468] Incorrect indentation in Doxygen-generated sources of libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64468 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Fri Jan 2 16:50:51 2015 New Revision: 219147 URL: https://gcc.gnu.org/viewcvs?rev=219147root=gccview=rev Log: PR libstdc++/64468 * doc/doxygen/user.cfg.in: Set correct TAB_SIZE. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/doc/doxygen/user.cfg.in
[Bug c/64470] “floating constant exceeds range” warning for constants that should fit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64470 --- Comment #2 from joseph at codesourcery dot com joseph at codesourcery dot com --- The definition of DBL_MAX_EXP (and thereby GCC's __DBL_MAX_EXP__) in C11 is maximum integer such that FLT_RADIX raised to one less than that power is a representable finite floating-point number, e_max. Note the one less than.
[Bug libstdc++/64438] Removing string-conversion requirement causes libstdc++-v3 fails on AArch64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64438 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- Should be fixed now - please confirm and set this to RESOLVED-FIXED.
[Bug fortran/57562] [OOP] ICE due to extended derived type with PARAMETER attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57562 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from janus at gcc dot gnu.org --- Fixed on trunk with r219144. Closing. Thanks for the report!
[Bug ipa/64472] FAIL: gcc.dg/ipa/inline-7.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64472 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com --- I think is expected since a may be overridden when compiled with -fPIC. We can either make a static or mark it as hidden.
[Bug web/64468] Incorrect indentation in Doxygen-generated sources of libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64468 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Fixed on trunk so far.
[Bug ada/64478] New: Ada Exception handlers call signal-unsafe malloc/free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478 Bug ID: 64478 Summary: Ada Exception handlers call signal-unsafe malloc/free Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: bernd.edlinger at hotmail dot de for instance c52104x: gdb ./c52104x b s-memory.adb:92 r Starting program: /home/ed/gnu/gcc-test/c52104x ,.,. C52104X ACATS 2.5 15-01-03 04:40:03 C52104X CHECK THAT IN ARRAY ASSIGNMENTS AND IN SLICE ASSIGNMENTS, THE LENGTHS MUST MATCH; ALSO CHECK WHETHER CONSTRAINT_ERROR OR STORAGE_ERROR ARE RAISED FOR LARGE ARRAYS. - C52104X NO CONSTRAINT_ERROR FOR TYPE WITH 'LENGTH = INTEGER'LAST + 3. Program received signal SIGSEGV, Segmentation fault. c52104x () at c52104x.adb:113 113 (IDENT_INT(-2)..IDENT_INT( INTEGER'LAST)); (gdb) c Continuing. Breakpoint 1, __gnat_malloc (size=size@entry=704) at s-memory.adb:92 92 Result := c_malloc (System.CRTL.size_t (Actual_Size)); (gdb) bt #0 __gnat_malloc (size=size@entry=704) at s-memory.adb:92 #1 0x0041ab30 in system.exceptions.machine.new_occurrence () at s-excmac.ads:183 #2 0x00407603 in ada.exceptions.exception_propagation.allocate_occurrence () at a-exexpr.adb:188 #3 0x00408475 in ada.exceptions.create_occurrence_from_signal_handler (e=0x633b60 storage_error, m=(system.address) 0x426710) at a-except.adb:1058 #4 0x004084c2 in ada.exceptions.raise_from_signal_handler (e=optimized out, m=optimized out) at a-except.adb:1093 #5 signal handler called #6 c52104x () at c52104x.adb:113 (gdb)
[Bug ada/64478] Ada Exception handlers call signal-unsafe malloc/free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478 --- Comment #1 from Bernd Edlinger bernd.edlinger at hotmail dot de --- I found this initially with TSAN: RUN c52104x ^M ,.,. C52104X ACATS 2.5 15-01-03 04:12:21^M C52104X CHECK THAT IN ARRAY ASSIGNMENTS AND IN SLICE ASSIGNMENTS,^M THE LENGTHS MUST MATCH; ALSO CHECK WHETHER^M CONSTRAINT_ERROR OR STORAGE_ERROR ARE RAISED FOR LARGE^M ARRAYS.^M - C52104X NO CONSTRAINT_ERROR FOR TYPE WITH 'LENGTH = INTEGER'LAST + ^M 3.^M ==^M ^[[1m^[[31mWARNING: ThreadSanitizer: signal-unsafe call inside of a signal (pid=9681)^M ^[[1m^[[0m#0 malloc ../../../../gcc-trunk/libsanitizer/tsan/tsan_interceptors.cc:491 (libtsan.so.0+0x00025c33)^M #1 __gnat_malloc /home/ed/gnu/gcc-build/gcc/ada/rts/s-memory.adb:92 (c52104x+0x00407070)^M #2 main null (c52104x+0x00402f93)^M ^M SUMMARY: ThreadSanitizer: signal-unsafe call inside of a signal /home/ed/gnu/gcc-build/gcc/ada/rts/s-memory.adb:92 __gnat_malloc^M ==^M - C52104X STORAGE_ERROR RAISED WHEN DECLARING TWO PACKED BOOLEAN^M ARRAYS WITH INTEGER'LAST + 3 COMPONENTS.^M ==^M ^[[1m^[[31mWARNING: ThreadSanitizer: signal-unsafe call inside of a signal (pid=9681)^M ^[[1m^[[0m#0 free ../../../../gcc-trunk/libsanitizer/tsan/tsan_interceptors.cc:538 (libtsan.so.0+0x00025f29)^M #1 __gnat_free /home/ed/gnu/gcc-build/gcc/ada/rts/s-memory.adb:113 (c52104x+0x004070c1)^M #2 main null (c52104x+0x00402f93)^M ^M SUMMARY: ThreadSanitizer: signal-unsafe call inside of a signal /home/ed/gnu/gcc-build/gcc/ada/rts/s-memory.adb:113 __gnat_free^M ==^M C52104X PASSED .^M ThreadSanitizer: reported 2 warnings^M PASS: c52104x
[Bug ada/16212] ICE ada/gcc-interface/trans.c:1626 on legal Ada 83 program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16212 Alexandre Oliva aoliva at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||aoliva at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from Alexandre Oliva aoliva at gcc dot gnu.org --- This is fixed in the trunk. It says: $ ./xgcc -B./ -Iada/rts/ -c -O1 /l/tmp/build/gcc/trunk/obj-x86_64-linux-gnu/gcc/test_251265.adb test_251265.adb:5:12: choice given in case statement is not static test_251265.adb:5:25: warning: value not in range of type Standard.Integer test_251265.adb:5:25: warning: Constraint_Error will be raised at run time test_251265.adb:5:25: expression raises exception, cannot be static (RM 4.9(34)) $ ./xgcc --version xgcc (GCC) 5.0.0 20150102 (experimental) [trunk revision ae61c50:a5fe274:4df12aa29efd9950b5bcbe15c207e61e11c16435]
[Bug ada/64478] Ada Exception handlers call signal-unsafe malloc/free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478 Bernd Edlinger bernd.edlinger at hotmail dot de changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #3 from Bernd Edlinger bernd.edlinger at hotmail dot de --- (In reply to Andrew Pinski from comment #2) I think in this case tsan is incorrect, as the signal handler never returns. This is how C++ exceptions work with non-call signals also. I dont think so. Because the exception could happen also because of stack overflow or simply asynchronos. for instance ga stack overflow in malloc. or a kill -SIGILL while executing malloc. that will deadlock then in the signal handler.
[Bug ada/48918] GNAT Bug Box with Assert_Failure with einfo.adb:2661
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48918 Alexandre Oliva aoliva at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||aoliva at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Alexandre Oliva aoliva at gcc dot gnu.org --- GCC versions from 4.8 on print this error instead: $ ./xgcc -B./ -Iada/rts/ -c -gnat12 /l/tmp/build/gcc/trunk/obj-x86_64-linux-gnu/gcc/buffers.ads buffers.ads:3:09: missing full declaration for private type Buffer
[Bug ada/52120] [Ada] Compiler assertion in iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52120 Alexandre Oliva aoliva at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||aoliva at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Alexandre Oliva aoliva at gcc dot gnu.org --- This problem is fixed in GCC 4.8 and newer. heap_sieve.adb compiles successfully with the given command line in 4.8, 4.9 and trunk, whereas proc.adb compiles successfully in 4.9 and trunk, but it requires explicit -gnat12 in 4.8.
[Bug ada/64478] Ada Exception handlers call signal-unsafe malloc/free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- I think in this case tsan is incorrect, as the signal handler never returns. This is how C++ exceptions work with non-call signals also.
[Bug ada/64478] Ada Exception handlers call signal-unsafe malloc/free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org --- Then all use of exceptions inside signal handling is broken including and not limited to JDK's use of it and GCJ use too.
[Bug ada/64478] Ada Exception handlers call signal-unsafe malloc/free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64478 --- Comment #5 from Bernd Edlinger bernd.edlinger at hotmail dot de --- but I cant see why a potential deadlock in an exception handler is not a bug?
