[Bug libgomp/42519] bootstrap fails on powerpc64-linux because of libgomp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42519 --- Comment #7 from Laurent GUERBY laurent at guerby dot net --- debian etch is an obsolete OS now so feel free to close, I no longer have an etch system around to test anyway :).
[Bug c/41624] RFE: -fno-nested-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41624 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Steven Bosscher from comment #2) Switching on/off individual language dialect features won't happen. (NB: I'd actually encourage anyone to use a strict non-gnu mode, for portability reasons.) That said, perhaps a new flag could be added -Wnested-function so users could do -Werror=nested-function. The flag would be enabled by -Wpedantic, so it will be backwards compatible.
[Bug tree-optimization/59591] [4.9 Regression] ICE in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:156 for -march=core-avx2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59591 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Actually started with r205856 already.
[Bug tree-optimization/59591] [4.9 Regression] ICE in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:156 for -march=core-avx2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59591
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org ---
Slightly reduced fortran testcase for -O3 -mavx2:
subroutine foo (m, n, o, p, q, e, a, b, x, f)
integer, intent (in) :: n, o, p, q, m, f
integer, dimension (n:o) :: e, a, b
integer, dimension (n:o, p:q) :: x
integer :: j, i
do j = 1, m
do i = n, f
if (e(i) .eq. 0) then
a(i) = x(i, b(i))
endif
enddo
enddo
end subroutine foo
and C testcase for -O3 -mavx2 -fopenmp-simd:
int p[256], q[256], r[256], t[256];
void
foo (void)
{
int i;
#pragma omp simd safelen(64)
for (i = 0; i 256; i++)
if (r[i] 32)
t[i] = p[q[i] * 3L + 2L];
}
[Bug ipa/59610] [4.8 Regression] ICE in parm_preserved_before_stmt_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59610 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 CC||jamborm at gcc dot gnu.org Target Milestone|--- |4.8.3
[Bug ipa/59610] New: [4.8 Regression] ICE in parm_preserved_before_stmt_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59610
Bug ID: 59610
Summary: [4.8 Regression] ICE in parm_preserved_before_stmt_p
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
struct A { int a; };
extern void *y;
__attribute__((optimize (0))) void
foo (void *, A x)
{
foo (y, x);
}
ICEs on 4.8 branch at -O2, starting with (likely) r190260 and fixed on the
trunk with r200369. The 4.8 version of that fix didn't fix this, since it
changed only a different function. I see 3 remaining walk_aliased_vdefs calls
not guarded for !optimize in ipa-prop.c, perhaps all of them need fixing?
[Bug sanitizer/59585] Tests failing due to trailing newline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59585 --- Comment #2 from ygribov at gcc dot gnu.org --- Author: ygribov Date: Fri Dec 27 13:56:18 2013 New Revision: 206219 URL: http://gcc.gnu.org/viewcvs?rev=206219root=gccview=rev Log: 2013-12-27 Yury Gribov y.gri...@samsung.com PR target/59585 * c-c++-common/ubsan/div-by-zero-1.c: Fixed pattern. * c-c++-common/ubsan/div-by-zero-2.c: Likewise. * c-c++-common/ubsan/div-by-zero-3.c: Likewise. * c-c++-common/ubsan/load-bool-enum.c: Likewise. * c-c++-common/ubsan/overflow-add-2.c: Likewise. * c-c++-common/ubsan/overflow-mul-2.c: Likewise. * c-c++-common/ubsan/overflow-mul-4.c: Likewise. * c-c++-common/ubsan/overflow-negate-1.c: Likewise. * c-c++-common/ubsan/overflow-sub-2.c: Likewise. * c-c++-common/ubsan/pr59333.c: Likewise. * c-c++-common/ubsan/shift-1.c: Likewise. * c-c++-common/ubsan/shift-2.c: Likewise. * c-c++-common/ubsan/shift-4.c: Likewise. * c-c++-common/ubsan/vla-1.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/ubsan/div-by-zero-1.c trunk/gcc/testsuite/c-c++-common/ubsan/div-by-zero-2.c trunk/gcc/testsuite/c-c++-common/ubsan/div-by-zero-3.c trunk/gcc/testsuite/c-c++-common/ubsan/load-bool-enum.c trunk/gcc/testsuite/c-c++-common/ubsan/overflow-add-2.c trunk/gcc/testsuite/c-c++-common/ubsan/overflow-mul-2.c trunk/gcc/testsuite/c-c++-common/ubsan/overflow-mul-4.c trunk/gcc/testsuite/c-c++-common/ubsan/overflow-negate-1.c trunk/gcc/testsuite/c-c++-common/ubsan/overflow-sub-2.c trunk/gcc/testsuite/c-c++-common/ubsan/pr59333.c trunk/gcc/testsuite/c-c++-common/ubsan/shift-1.c trunk/gcc/testsuite/c-c++-common/ubsan/shift-2.c trunk/gcc/testsuite/c-c++-common/ubsan/shift-4.c trunk/gcc/testsuite/c-c++-common/ubsan/vla-1.c
[Bug libgcc/56276] libgcc_*.dll is installed to wrong directory during build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56276 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktietz at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Kai Tietz ktietz at gcc dot gnu.org --- Due the fact that your target-triplet is different to the build-triplet (and the host one) gcc assumes correctly that you are doing a cross-compilation. Therefore installation-directory of target/lib is intended.
[Bug c++/56066] g++ generates strong symbols conflicting with C99 extern inline code on Windows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56066 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #3 from Kai Tietz ktietz at gcc dot gnu.org --- No reply. So I assume bug was fixed already. Please don't hesitate to reopen this bug (with small testcase for reproducing it) again, if it re-appears.
[Bug libgomp/42519] bootstrap fails on powerpc64-linux because of libgomp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42519 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||steven at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #8 from Steven Bosscher steven at gcc dot gnu.org --- LinuxThreads is obsolete also - WONTFIX.
[Bug c++/55189] enable -Wreturn-type by default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55189 Sylvestre Ledru sylvestre at debian dot org changed: What|Removed |Added CC||sylvestre at debian dot org --- Comment #6 from Sylvestre Ledru sylvestre at debian dot org --- Patch proposed here: http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01781.html
[Bug debug/59575] [4.9 regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2239
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59575 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-27 CC||hubicka at gcc dot gnu.org Summary|ICE in |[4.9 regression] ICE in |maybe_record_trace_start, |maybe_record_trace_start, |at dwarf2cfi.c:2239 |at dwarf2cfi.c:2239 Ever confirmed|0 |1 --- Comment #1 from Jan Hubicka hubicka at gcc dot gnu.org --- Same ICE also breaks bootstrap with -mno-accumulate-outoging-args on 32bit /home/jh/trunk/build4/./gcc/gccgo -B/home/jh/trunk/build4/./gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -minline-all-stringops -O2 -mno-accumulate-outgoing-args -g -m32 -I . -c -fgo-pkgpath=encoding/binary ../../../../libgo/go/encoding/binary/binary.go ../../../../libgo/go/encoding/binary/varint.go -fPIC -o encoding/.libs/binary.o ./libtool: line 1143: warning: setlocale: LC_CTYPE: cannot change locale (cs_CZ.ISO-8859-2) ../../../../libgo/go/encoding/binary/binary.go: In function 'binary.Write': ../../../../libgo/go/encoding/binary/binary.go:334:1: internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2239 } ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug go/59506] net FAILs (timeout) on alpha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59506 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-27 Ever confirmed|0 |1 --- Comment #3 from Ian Lance Taylor ian at airs dot com --- Thanks for the suggestion. https://codereview.appspot.com/39200044
[Bug fortran/59604] Constant comparisons with -fno-range-check and int(z'...')
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59604 --- Comment #1 from Thomas Koenig tkoenig at gcc dot gnu.org --- TRANSFER gets this right.
[Bug libstdc++/59611] New: std::copy performs worse than naive implementation when copying a single known byte
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59611 Bug ID: 59611 Summary: std::copy performs worse than naive implementation when copying a single known byte Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: gcc-bugzilla at contacts dot eelis.net Created attachment 31524 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31524action=edit Testcase The attached testcase shows how using a naive implementation (mycopy) causes gcc to generate better code than using std::copy. (Clang /does/ generate optimal code when using std::copy in this case.)
[Bug libstdc++/59611] std::copy performs worse than naive implementation when copying a single known byte
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59611 --- Comment #1 from Eelis gcc-bugzilla at contacts dot eelis.net --- (With -O3)
[Bug c++/16564] g++ seems to go into an infinite loop after errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564
--- Comment #18 from Volker Reichelt reichelt at gcc dot gnu.org ---
The reduced testcases from comment #3 and #4 compile within split-seconds since
GCC 4 5.0. This is partially due to Manuel's fix for PR 23510.
However, the original testcase still takes a very long time.
This can be demonstrated with the following reduced testcase:
templatetypename struct A
{
AA a;
A() {}
};
Aint a;
The first error message about exceeding the maximum template instantiation
depth appears rather quickly. So maybe we could make the first error message a
fatal one to avoid further processing of potentially bogus nested classes.
[Bug fortran/59604] Constant comparisons with -fno-range-check and int(z'...')
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59604
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #1)
TRANSFER gets this right.
It is unclear what you mean here.
A simplified program that removes the complication of the IO
and ISO C binding is
program test
if (int(z'') /= -1) call abort
end program test
% gfc4x -o z -fno-range-check -fdump-tree-original a.f90
% ./z
Program aborted. Backtrace:
#0 0x4807A01C
#1 0x4807B8CF
#2 0x48134C17
#3 0x8048792 in MAIN__ at a.f90:0
Abort (core dumped)
%cat a.f90.003t.orginal
test ()
{
_gfortran_abort ();
L.1:;
}
main (integer(kind=4) argc, character(kind=1) * * argv)
{
static integer(kind=4) options.0[9] = {68, 1023, 0, 0, 1, 1, 0, 0, 31};
_gfortran_set_args (argc, argv);
_gfortran_set_options (9, options.0[0]);
test ();
return 0;
}
I believe the problem lies in gfc_simplify_int. From what I can
tell, there is never a conversion of a boz to an integer, until we
reach code generation. The call chain is
gfc_simplify_int - simplify-intconv - gfc_convert_constant -
gfc_int2int.
By the time we reach gfc_int2int, the boz should have been converted
to the integer, but isn't. Now, if we compare gfc_simplify_int to
gfc_simplify_real, we see in gfc_simplify_real,
if (convert_boz (e, kind) == gfc_bad_expr)
return gfc_bad_expr;
where convert_boz will do an explicit conversion of a boz to a
real type. There isn't a similar functionality for integer.
[Bug fortran/59604] Constant comparisons with -fno-range-check and int(z'...')
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59604 --- Comment #3 from Steve Kargl sgk at troutmask dot apl.washington.edu --- On Fri, Dec 27, 2013 at 06:10:23PM +, kargl at gcc dot gnu.org wrote: By the time we reach gfc_int2int, the boz should have been converted to the integer, but isn't. Now, if we compare gfc_simplify_int to gfc_simplify_real, we see in gfc_simplify_real, if (convert_boz (e, kind) == gfc_bad_expr) return gfc_bad_expr; where convert_boz will do an explicit conversion of a boz to a real type. There isn't a similar functionality for integer. I forgot to mention that gfortran may be delaying the conversion under the translation to the middle-end, so tit can rely on the middle-end for wrap-around semantics of twos-complement signed integer arithmetic.
[Bug tree-optimization/59591] [4.9 Regression] ICE in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:156 for -march=core-avx2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59591 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 31525 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31525action=edit gcc49-pr59591.patch Untested fix. Still need to turn the testcase into runtime testcase and look at the other gather direction (the patch fixes the modifier = NARROW case, need to look at modifier = WIDEN case).
[Bug fortran/59604] Constant comparisons with -fno-range-check and int(z'...')
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59604 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Blocks||58003 --- Comment #4 from Thomas Koenig tkoenig at gcc dot gnu.org --- (In reply to kargl from comment #2) (In reply to Thomas Koenig from comment #1) TRANSFER gets this right. It is unclear what you mean here. What I mean is that program test if (transfer(z'',1) /= -1) call abort end program test does not call abort. Also setting this as blocking 58003, because an obvious fix to that bug would replace an ICE with a wrong-code bug for some corner cases (not preferable :-)
[Bug c++/16564] g++ seems to go into an infinite loop after errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564 --- Comment #19 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Volker Reichelt from comment #18) The first error message about exceeding the maximum template instantiation depth appears rather quickly. So maybe we could make the first error message a fatal one to avoid further processing of potentially bogus nested classes. It seems to me GCC is doing something strange. See comment #14. But what you suggest seems to be what Clang++ is doing: $ /usr/bin/time clang++ test.cc test.cc:3:8: fatal error: recursive template instantiation exceeded maximum depth of 256 AA a; ^ test.cc:3:8: note: in instantiation of template class '...' requested here AA a; ^ test.cc:3:8: note: in instantiation of template class '...' requested here AA a; ^ test.cc:3:8: note: in instantiation of template class '...' requested here AA a; ^ test.cc:3:8: note: in instantiation of template class '...' requested here AA a; ^ test.cc:3:8: note: in instantiation of template class '...' requested here AA a; ^ test.cc:3:8: note: (skipping 247 contexts in backtrace; use -ftemplate-backtrace-limit=0 to see all) test.cc:3:8: note: in instantiation of template class 'Aint' requested here AA a; ^ test.cc:3:8: note: in instantiation of template class 'int ' requested here AA a; ^ test.cc:3:8: note: in instantiation of template class 'AAAint ' requested here AA a; ^ test.cc:3:8: note: in instantiation of template class 'AAint ' requested here AA a; ^ test.cc:7:8: note: in instantiation of template class 'Aint' requested here Aint a; ^ test.cc:3:8: note: use -ftemplate-depth=N to increase recursive template instantiation depth AA a; ^ 1 error generated. Command exited with non-zero status 1 0.11user 0.02system 0:00.14elapsed 96%CPU (0avgtext+0avgdata 67904maxresident)k 0inputs+0outputs (0major+6524minor)pagefaults 0swaps And GCC's output in recent versions would look better than this because it has automatic recursion detection: test.cc:3:8: error: template instantiation depth exceeds maximum of 900 (use -ftemplate-depth= to increase the maximum) instantiating ‘struct ...’ AA a; ^ test.cc:3:8: recursively required from ‘struct AAint ’ test.cc:3:8: required from ‘struct Aint’ test.cc:7:8: required from here
[Bug c++/16564] g++ seems to go into an infinite loop after errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564 --- Comment #20 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #19) (In reply to Volker Reichelt from comment #18) The first error message about exceeding the maximum template instantiation depth appears rather quickly. So maybe we could make the first error message a fatal one to avoid further processing of potentially bogus nested classes. It seems to me GCC is doing something strange. See comment #14. But what you suggest seems to be what Clang++ is doing: Although GCC is still much slower than Clang for Steven's original testcase, so the above wouldn't be a complete fix. And the long lines are very ugly. Perhaps there is a way to summarize such a recursive template instantiation. Still, making the error: template instantiation depth exceeds maximum a fatal error seems a good idea to me. Jason?
[Bug fortran/59604] Constant comparisons with -fno-range-check and int(z'...')
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59604 --- Comment #5 from Steve Kargl sgk at troutmask dot apl.washington.edu --- On Fri, Dec 27, 2013 at 07:53:00PM +, tkoenig at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59604 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Blocks||58003 --- Comment #4 from Thomas Koenig tkoenig at gcc dot gnu.org --- (In reply to kargl from comment #2) (In reply to Thomas Koenig from comment #1) TRANSFER gets this right. It is unclear what you mean here. What I mean is that program test if (transfer(z'',1) /= -1) call abort end program test does not call abort. I suspect that the above is not portable as transfer() simply copies bits. z'FFF' is an integer(8) (or integer(16)) entity. Transfer() is copying 32-bits from that entity. It is clear from the -fdump-tree-original that middle-end is converting the resulting 32-bit thing into -1. So, you're relying on twos-complement wrap around semantics. Also setting this as blocking 58003, because an obvious fix to that bug would replace an ICE with a wrong-code bug for some corner cases (not preferable :-) This isn't blocking 58003 as the code in 59604 is invalid. As gfortran provides popcnt() as an intrinsics procedure, it follows that popcnt() should follow the Fortran standard (see below quote). Now, if you want to chase a real bug in gfortran, try this little program program test integer(8) :: i = 4294967295_8 integer(8) :: j = z'' ! ! The following two lines should call abort, but don't! In addition, ! these lines do not require -fno-range-check to compile, so gfortran ! violates the quote from the F95 standard (p.228) below. ! if (int(i) /= -1) call abort if (int(j) /= -1) call abort ! ! On a 2-complement system, the next statement is optimized away. ! I haven't decided yet, whether transfer() violates the standard ! because it only copies bits and the 32-bits copied from the boz ! fit into an integer(4). ! if (transfer(z'',1) /= -1) call abort ! ! Both of these require -fno-range-check to compile, and they violate ! !A program is prohibited from invoking an intrinsic procedure !under circumstances where a value to be returned in a subroutine !argument or function result is outside the range of values !representable by objects of the specified type and type parameters. ! ! 4294967295_8 is well outside of the range [-huge()-1:huge()] of a ! twos-complement 32-bit integer(4) ! if (int(z'') /= -1) call abort if (int(4294967295_8) /= -1) call abort end program test
[Bug fortran/59612] New: iso_fortran_env segfaults with -fdump-fortran-original
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59612
Bug ID: 59612
Summary: iso_fortran_env segfaults with -fdump-fortran-original
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
ig25@linux-fd1f:~/Krempel/NoRange cat iso.f90
program main
use iso_fortran_env
end program main
ig25@linux-fd1f:~/Krempel/NoRange gfortran -fdump-fortran-original iso.f90
Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4)
procedure name = main
symtree: 'Lock_type' || symbol: 'lock_type'
type spec : (UNKNOWN 0)
attributes: (DERIVED USE-ASSOC(iso_fortran_env))
symtree: 'atomic_int_kind'|| symbol: 'atomic_int_kind'
type spec : (INTEGER 4)
attributes: (PARAMETER USE-ASSOC(iso_fortran_env))
value: 4
symtree: 'atomic_logical_kind'|| symbol: 'atomic_logical_kind'
type spec : (INTEGER 4)
attributes: (PARAMETER USE-ASSOC(iso_fortran_env))
value: 4
symtree: 'character_kinds'|| symbol: 'character_kinds'
type spec : (INTEGER 4)
attributes: (PARAMETER DIMENSION USE-ASSOC(iso_fortran_env))
value: (/ 1 , 4 /)
Array spec:(1 [0] AS_EXPLICIT 1 2 )
symtree: 'character_storage_size'|| symbol: 'character_storage_size'
type spec : (INTEGER 4)
attributes: (PARAMETER USE-ASSOC(iso_fortran_env))
value: 8
symtree: 'compiler_options'|| symbol: 'compiler_options'
f951: interner Compiler-Fehler: Speicherzugriffsfehler
0x9f9dff crash_signal
../../trunk/gcc/toplev.c:336
0x5635bc show_typespec
../../trunk/gcc/fortran/dump-parse-tree.c:113
0x566a3c show_symbol
../../trunk/gcc/fortran/dump-parse-tree.c:841
0x566a3c show_symtree
../../trunk/gcc/fortran/dump-parse-tree.c:1000
0x5dcdc9 do_traverse_symtree
../../trunk/gcc/fortran/symbol.c:3581
0x566571 show_namespace
../../trunk/gcc/fortran/dump-parse-tree.c:2284
0x5b09ee gfc_parse_file()
../../trunk/gcc/fortran/parse.c:4728
0x5ee895 gfc_be_parse_file
../../trunk/gcc/fortran/f95-lang.c:188
Bitte senden Sie einen vollständigen Fehlerbericht auf Englisch ein;
bearbeiten Sie die Quellen zunächst mit einem Präprozessor, wenn es
dienlich ist.
Please include the complete backtrace with any bug report.
Siehe http://gcc.gnu.org/bugs.html für nähere Anweisungen.
ig25@linux-fd1f:~/Krempel/NoRange gfortran -v
Es werden eingebaute Spezifikationen verwendet.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/ig25/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Ziel: x86_64-unknown-linux-gnu
Konfiguriert mit: ../trunk/configure --prefix=/home/ig25
--enable-languages=c,fortran,c++
Thread-Modell: posix
gcc-Version 4.9.0 20131225 (experimental) (GCC)
valgrind shows:
==13350== Invalid read of size 8
==13350==at 0x5635BC: show_typespec(gfc_typespec*) (dump-parse-tree.c:113)
==13350==by 0x566A3C: show_symtree(gfc_symtree*) (dump-parse-tree.c:841)
==13350==by 0x5DCDC9: do_traverse_symtree(gfc_symtree*, void
(*)(gfc_symtree*), void (*)(gfc_symbol*)) (symbol.c:3581)
==13350==by 0x566571: show_namespace(gfc_namespace*)
(dump-parse-tree.c:2284)
==13350==by 0x5B09EE: gfc_parse_file() (parse.c:4728)
==13350==by 0x5EE895: gfc_be_parse_file() (f95-lang.c:188)
==13350==by 0x9F9E25: compile_file() (toplev.c:547)
==13350==by 0x9FBDF7: toplev_main(int, char**) (toplev.c:1887)
==13350==by 0x5A54BE4: (below main) (in /lib64/libc-2.18.so)
==13350== Address 0x0 is not stack'd, malloc'd or (recently) free'd
gdb shows that the typespec for compiler_options is NULL:
symtree: 'compiler_options'|| symbol: 'compiler_options'
Program received signal SIGSEGV, Segmentation fault.
0x005635bc in show_typespec (ts=0x0) at
../../trunk/gcc/fortran/dump-parse-tree.c:113
113 show_expr (ts-u.cl-length);
(gdb) up
#1 0x00566a3d in show_symbol (sym=0x184ee10) at
../../trunk/gcc/fortran/dump-parse-tree.c:841
841 show_typespec (sym-ts);
(gdb) p sym
$1 = (gfc_symbol *) 0x184ee10
(gdb) p *sym
$2 = {name = 0x76c53738 compiler_options, module = 0x76d33340
iso_fortran_env, declared_at = {nextc = 0x17dcb68, lb = 0x17dcb30}, ts = {
type = BT_CHARACTER, kind = 1, u = {derived = 0x0, cl = 0x0, pad = 0},
interface = 0x0, is_c_interop = 0, is_iso_c = 0, f90_type = BT_UNKNOWN,
deferred = false}, attr = {allocatable = 0, dimension = 0, codimension = 0,
external = 0, intrinsic = 1, optional = 0, pointer = 0, target = 0,
value = 0, volatile_ = 0, temporary = 0, dummy = 0, result = 0, assign = 0,
threadprivate = 0, not_always_present = 0, implied_index = 0,
subref_array_pointer = 0, proc_pointer = 0, asynchronous = 0, contiguous =
0, class_pointer = 0, save = SAVE_NONE, data = 0, is_protected = 0,
use_assoc = 1, use_only = 0, use_rename = 0, imported = 0, host_assoc = 0,
in_namelist = 0, in_common
[Bug go/59506] net FAILs (timeout) on alpha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59506 --- Comment #4 from ian at gcc dot gnu.org ian at gcc dot gnu.org --- Author: ian Date: Fri Dec 27 21:42:26 2013 New Revision: 206224 URL: http://gcc.gnu.org/viewcvs?rev=206224root=gccview=rev Log: PR go/59506 net: use DialTimeout in TestSelfConnect Backported from master repository. This avoids problems with systems that take a long time to find out nothing is listening, while still testing for the self-connect misfeature since a self-connect should be fast. With this we may be able to remove the test for non-Linux systems. Tested (on GNU/Linux) by editing selfConnect in tcpsock_posix.go to always return false and verifying that TestSelfConnect then fails with and without this change. Idea from Uros Bizjak. Modified: trunk/libgo/go/net/dial_test.go
[Bug go/59506] net FAILs (timeout) on alpha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59506 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Ian Lance Taylor ian at airs dot com --- Fixed, I hope.
[Bug c++/59271] [4.9 Regression] a.C:16:21: internal compiler error: in strip_typedefs, at cp/tree.c:1315
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59271 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #5 from Jason Merrill jason at gcc dot gnu.org --- Fixed.
[Bug c++/59349] [4.9 Regression] ICE on invalid: Segmentation fault toplev.c:336
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59349 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- Fixed.
[Bug c++/58954] [4.8/4.9 Regression] accessing a private member function in decltype of a friend class causes access control error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58954 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jason Merrill jason at gcc dot gnu.org --- Fixed for 4.8.3/4.9.
[Bug target/59613] New: Incorrect code generation in MSP430 large model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59613
Bug ID: 59613
Summary: Incorrect code generation in MSP430 large model
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: l.marcantonio at logossrl dot com
Found on 4.9.0 fresh from trunk (svn 206223); it's actually a showstopper for
large model since it miscompiles crtbegin.o (frame_dummy(), for example).
However I found a minimal sample which gives the problem (it's a function
pointer instead of a weak symbol but the problem is the same).
Code generation (or optimization) is broken for MSP430 in large model; given
this simple code:
/*/
extern void (*unk_function)(void);
void do_stuff(void)
{
if (unk_function)
unk_function();
}
/*/
Compiling in standard mode with
msp430-elf-gcc -mmcu=msp430x -Wall -S -O2 test.c
gives the following assembly (which is quite adequate)
.text
.balign 2
.global do_stuff
do_stuff:
; start of function
; framesize_regs: 0
; framesize_locals: 0
; framesize_outgoing: 0
; framesize: 0
; elim ap - fp 2
; elim fp - sp 0
; saved regs:(none)
; start of prologue
; end of prologue
MOV.W unk_function, R12
CMP.W #0, R12 { JEQ .L1
CALLR12
.L1:
; start of epilogue
RET
However in large model (adding -mlarge to the above command line) the result is
.text
.balign 2
.global do_stuff
do_stuff:
; start of function
; framesize_regs: 0
; framesize_locals: 0
; framesize_outgoing: 0
; framesize: 0
; elim ap - fp 4
; elim fp - sp 0
; saved regs:(none)
; start of prologue
; end of prologue
CALLA unk_function
; start of epilogue
RETA
The condition checking is not done, and a crash follows. Using -O0 or -Os
doesn't change the behaviour. Looking in the RTL with -fdump-final-insns shows
a NOTE_INSN_DELETED instead of the condition check but I'm not proficient to
interpretate that...
[Bug c++/56926] Crash (without ICE) while compiling Boost.Math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56926 baltic 1000hz.radiowave at gmail dot com changed: What|Removed |Added CC||1000hz.radiowave at gmail dot com --- Comment #5 from baltic 1000hz.radiowave at gmail dot com --- Experience the same while trying to build a project with massive amounts of Qt headers in a pch. Happens with mingw64 builds for versions 4.8.0 4.8.1 and 4.8.2 Can upload the pch, if needed. worked fine with 4.6
[Bug tree-optimization/59611] std::copy performs worse than naive implementation when copying a single known byte
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59611
Marc Glisse glisse at gcc dot gnu.org changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-12-27
Component|libstdc++ |tree-optimization
Ever confirmed|0 |1
--- Comment #2 from Marc Glisse glisse at gcc dot gnu.org ---
The call to memcpy is folded rather early to:
MEM[(char * {ref-all})p_2(D)] = MEM[(char * {ref-all})a];
and then we don't touch it anymore, maybe because we don't go through an
SSA_NAME. We thus miss that the RHS is a constant.
[Bug other/56653] Warning when verifying checksums from MD5SUMS file in tarballs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56653 --- Comment #1 from Dmitry Gorbachev d.g.gorbachev at gmail dot com --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01926.html.
[Bug c++/59614] New: [4.9 regression] Explostion in compile time of heavily templated code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59614 Bug ID: 59614 Summary: [4.9 regression] Explostion in compile time of heavily templated code Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ivanov.maxim at gmail dot com 4.9 takes forever to compile code, which compiles in 9 seconds by version 4.8.2. gdb shows that g++ spends time in mark_type_abi_tags function, which was introduced in http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=9181c3d9ceed054efd8488eaea91d89353bb8d21 If I read patch correctly, 4.9 visits all template arguments recursively for every template instantiation, but 4.8 didn't, at least not in check_abi_tags. I created following somewhat pathological, but still correct test case, with help of Boost.MPL and Boost.Fusion, to make very deep template with high number of occurrences of same templates in different parts of that template tree, you can find it in this ticket attachment (had to compress it, otherwise it wouldn't fit into bugzilla's 1000K size limit). Version I was testing on is: GNU C++ (SUSE Linux) version 4.9.0 20131210 [trunk revision 205857] (x86_64-suse-linux) compiled by GNU C version 4.9.0 20131210 [trunk revision 205857], GMP version 5.1.2, MPFR version 3.1.2, MPC version 1.0 Thank you for your time.
[Bug c++/59614] [4.9 regression] Explostion in compile time of heavily templated code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59614 --- Comment #1 from Maxim Ivanov ivanov.maxim at gmail dot com --- Created attachment 31526 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31526action=edit example of templated code which takes forever to compile by 4.9
[Bug c++/59614] [4.9 regression] Explostion in compile time of heavily templated code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59614 --- Comment #2 from Maxim Ivanov ivanov.maxim at gmail dot com --- Oh, g++ cmdline arguments are just -std=c++11 -save-temps
[Bug c/59615] New: asm goto output or at least clobbered operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59615 Bug ID: 59615 Summary: asm goto output or at least clobbered operands Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: hpa at zytor dot com There are a number of uses of asm goto which requires at least on dyadic architectures like x86 the ability to clobber an operand. However, the current definition of asm goto doesn't allow any output operands, and the clobber list only works on specific registers (which are generally not allowed to be inputs, anyway.) For example: asm goto(add %1,%0 ; jc %l[t_err] ; cmp %2,%0 ; ja %l[t_err] ; : +r (addr) : g (size), g (limit) : : t_err); return false; t_err: return true; This is part of a proposed implementation of access_ok(), a limit test with a guard for wraparound, used heavily in the Linux kernel. There needs to be a way to communicate to gcc that addr is clobbered by the first instruction.
[Bug c++/59614] [4.9 regression] Explostion in compile time of heavily templated code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59614 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Keywords||compile-time-hog Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-28 CC||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Steven Bosscher steven at gcc dot gnu.org --- Classic case of quadratic behavior. Why do even experienced developers continue to add this kind of obvious bottle-necks?!
