[Bug ada/55704] New: [4.7 Regression] Failures building ada
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55704
Bug #: 55704
Summary: [4.7 Regression] Failures building ada
Classification: Unclassified
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rai...@emrich-ebersheim.de
Since the transition to g++ for stage2 and stage3, ada fails to build in
stage2. There are several failures of the type "error: invalid conversion":
/SCRATCH/tmp.wOrMZOydvQ/gcc-4.7.3/gcc-4.7.3/./prev-gcc/g++
-B/SCRATCH/tmp.wOrMZOydvQ/gcc-4.7.3/gcc-4.7.3/./prev-gcc/
-B/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.3/x86_64-w64-mingw32/bin/
-nostdinc++
-B/SCRATCH/tmp.wOrMZOydvQ/gcc-4.7.3/gcc-4.7.3/prev-x86_64-w64-mingw32/libstdc++-v3/src/.libs
-B/SCRATCH/tmp.wOrMZOydvQ/gcc-4.7.3/gcc-4.7.3/prev-x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs
-I/SCRATCH/tmp.wOrMZOydvQ/gcc-4.7.3/gcc-4.7.3/prev-x86_64-w64-mingw32/libstdc++-v3/include/x86_64-w64-mingw32
-I/SCRATCH/tmp.wOrMZOydvQ/gcc-4.7.3/gcc-4.7.3/prev-x86_64-w64-mingw32/libstdc++-v3/include
-I/SCRATCH/tmp.wOrMZOydvQ/src/gcc-4.7.3/libstdc++-v3/libsupc++
-L/SCRATCH/tmp.wOrMZOydvQ/gcc-4.7.3/gcc-4.7.3/prev-x86_64-w64-mingw32/libstdc++-v3/src/.libs
-L/SCRATCH/tmp.wOrMZOydvQ/gcc-4.7.3/gcc-4.7.3/prev-x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs
-c -g -O2 -D__USE_MINGW_ACCESS -Wno-pedantic-ms-format -gtoggle -DIN_GCC
-fno-exceptions -fno-rtti -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wmissing-format-attribute -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Wno-error -DHAVE_CONFIG_H -I. -Iada
-I../../../src/gcc-4.7.3/gcc -I../../../src/gcc-4.7.3/gcc/ada
-I../../../src/gcc-4.7.3/gcc/../include -I./../intl
-I../../../src/gcc-4.7.3/gcc/../libcpp/include
-I/SCRATCH/tmp.wOrMZOydvQ/install/include
-I/SCRATCH/tmp.wOrMZOydvQ/install/include
-I/SCRATCH/tmp.wOrMZOydvQ/install/include
-I../../../src/gcc-4.7.3/gcc/../libdecnumber
-I../../../src/gcc-4.7.3/gcc/../libdecnumber/bid -I../libdecnumber
-I/SCRATCH/tmp.wOrMZOydvQ/install/include
-I/SCRATCH/tmp.wOrMZOydvQ/install/include
../../../src/gcc-4.7.3/gcc/ada/adaint.c -o ada/adaint.o
../../../src/gcc-4.7.3/gcc/ada/adaint.c: In function 'int
__gnat_check_OWNER_ACL(TCHAR*, DWORD, GENERIC_MAPPING)':
../../../src/gcc-4.7.3/gcc/ada/adaint.c:1986:53: error: invalid conversion from
'PSECURITY_DESCRIPTOR {aka void*}' to 'SECURITY_DESCRIPTOR* {aka
_SECURITY_DESCRIPTOR*}' [-fpermissive]
../../../src/gcc-4.7.3/gcc/ada/adaint.c: In function 'void
__gnat_set_OWNER_ACL(TCHAR*, DWORD, DWORD)':
../../../src/gcc-4.7.3/gcc/ada/adaint.c:2062:66: error: invalid conversion from
'DWORD {aka long unsigned int}' to 'ACCESS_MODE {aka _ACCESS_MODE}'
[-fpermissive]
In file included from ../../../src/gcc-4.7.3/gcc/ada/adaint.c:231:0:
D:/x86_64-w64-trunk/mingw/include/aclapi.h:67:25: error: initializing
argument 4 of 'void BuildExplicitAccessWithNameW(PEXPLICIT_ACCESS_W, LPWSTR,
DWORD, ACCESS_MODE, DWORD)' [-fpermissive]
../../../src/gcc-4.7.3/gcc/ada/adaint.c: In function 'int
__gnat_portable_spawn(char**)':
../../../src/gcc-4.7.3/gcc/ada/adaint.c:2387:61: error: invalid conversion from
'const char* const*' to 'char* const*' [-fpermissive]
In file included from D:/x86_64-w64-trunk/mingw/include/unistd.h:11:0,
from ../../../src/gcc-4.7.3/gcc/system.h:253,
from ../../../src/gcc-4.7.3/gcc/ada/adaint.c:107:
D:/x86_64-w64-trunk/mingw/include/process.h:177:20: error: initializing
argument 3 of 'intptr_t spawnvp(int, const char*, char* const*)' [-fpermissive]
../../../src/gcc-4.7.3/gcc/ada/adaint.c: In function 'void add_handle(HANDLE,
int)':
../../../src/gcc-4.7.3/gcc/ada/adaint.c:2547:67: error: invalid conversion from
'void*' to 'void**' [-fpermissive]
../../../src/gcc-4.7.3/gcc/ada/adaint.c:2549:60: error: invalid conversion from
'void*' to 'int*' [-fpermissive]
../../../src/gcc-4.7.3/gcc/ada/adaint.c: In function 'char*
__gnat_locate_exec_on_path(char*)':
../../../src/gcc-4.7.3/gcc/ada/adaint.c:2938:16: error: invalid conversion from
'void*' to 'TCHAR* {aka wchar_t*}' [-fpermissive]
../../../src/gcc-4.7.3/gcc/ada/adaint.c:2948:15: error: invalid conversion from
'void*' to 'char*' [-fpermissive]
make[3]: *** [ada/adaint.o] Error 1
/SCRATCH/tmp.wOrMZOydvQ/gcc-4.7.3/gcc-4.7.3/./prev-gcc/g++
-B/SCRATCH/tmp.wOrMZOydvQ/gcc-4.7.3/gcc-4.7.3/./prev-gcc/
-B/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.3/x86_64-w64-mingw32/bin/
-nostdinc++
-B/SCRATCH/tmp.wOrMZOydvQ/gcc-4.7.3/gcc-4.7.3/prev-x86_64-w64-mingw32/libstdc++-v3/src/.libs
-B/SCRATCH/tmp.wOrMZOydvQ/gcc-4.7.3/gcc-4.7.3/prev-x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs
-I/SCRATCH/tmp.wOrMZOydvQ/gcc-4.7.3/gcc-4.7.3/prev-x86_64-w64-mingw32/libstdc++-v3/include/x86_64-w64-ming
[Bug ada/55704] [4.7 Regression] Failures building ada
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55704
--- Comment #1 from Rainer Emrich 2012-12-15
10:14:47 UTC ---
The same for 4.8.0 in stage 1:
g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables
-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wno-error
-DHAVE_CONFIG_H -I. -Iada -I../../../src/gcc-4.8.0/gcc
-I../../../src/gcc-4.8.0/gcc/ada -I../../../src/gcc-4.8.0/gcc/../include
-I./../intl -I../../../src/gcc-4.8.0/gcc/../libcpp/include
-I/SCRATCH/tmp.sTvWvLQnyU/install/include
-I/SCRATCH/tmp.sTvWvLQnyU/install/include
-I/SCRATCH/tmp.sTvWvLQnyU/install/include
-I../../../src/gcc-4.8.0/gcc/../libdecnumber
-I../../../src/gcc-4.8.0/gcc/../libdecnumber/bid -I../libdecnumber
-I../../../src/gcc-4.8.0/gcc/../libbacktrace -DCLOOG_INT_GMP
-I/SCRATCH/tmp.sTvWvLQnyU/install/include
-I/SCRATCH/tmp.sTvWvLQnyU/install/include
../../../src/gcc-4.8.0/gcc/ada/adaint.c -o ada/adaint.o
../../../src/gcc-4.8.0/gcc/ada/adaint.c: In function 'int
__gnat_check_OWNER_ACL(TCHAR*, DWORD, GENERIC_MAPPING)':
../../../src/gcc-4.8.0/gcc/ada/adaint.c:1986:53: error: invalid conversion from
'PSECURITY_DESCRIPTOR {aka void*}' to 'SECURITY_DESCRIPTOR* {aka
_SECURITY_DESCRIPTOR*}' [-fpermissive]
../../../src/gcc-4.8.0/gcc/ada/adaint.c: In function 'void
__gnat_set_OWNER_ACL(TCHAR*, DWORD, DWORD)':
../../../src/gcc-4.8.0/gcc/ada/adaint.c:2062:66: error: invalid conversion from
'DWORD {aka long unsigned int}' to 'ACCESS_MODE {aka _ACCESS_MODE}'
[-fpermissive]
In file included from ../../../src/gcc-4.8.0/gcc/ada/adaint.c:230:0:
D:/x86_64-w64-trunk/mingw/include/aclapi.h:67:25: error: initializing
argument 4 of 'void BuildExplicitAccessWithNameW(PEXPLICIT_ACCESS_W, LPWSTR,
DWORD, ACCESS_MODE, DWORD)' [-fpermissive]
../../../src/gcc-4.8.0/gcc/ada/adaint.c: In function 'int
__gnat_portable_spawn(char**)':
../../../src/gcc-4.8.0/gcc/ada/adaint.c:2387:61: error: invalid conversion from
'const char* const*' to 'char* const*' [-fpermissive]
In file included from D:/x86_64-w64-trunk/mingw/include/unistd.h:11:0,
from ../../../src/gcc-4.8.0/gcc/system.h:256,
from ../../../src/gcc-4.8.0/gcc/ada/adaint.c:106:
D:/x86_64-w64-trunk/mingw/include/process.h:177:20: error: initializing
argument 3 of 'intptr_t spawnvp(int, const char*, char* const*)' [-fpermissive]
../../../src/gcc-4.8.0/gcc/ada/adaint.c: In function 'void add_handle(HANDLE,
int)':
../../../src/gcc-4.8.0/gcc/ada/adaint.c:2543:67: error: invalid conversion from
'void*' to 'void**' [-fpermissive]
../../../src/gcc-4.8.0/gcc/ada/adaint.c:2545:60: error: invalid conversion from
'void*' to 'int*' [-fpermissive]
../../../src/gcc-4.8.0/gcc/ada/adaint.c: In function 'char*
__gnat_locate_exec_on_path(char*)':
../../../src/gcc-4.8.0/gcc/ada/adaint.c:2934:16: error: invalid conversion from
'void*' to 'TCHAR* {aka wchar_t*}' [-fpermissive]
../../../src/gcc-4.8.0/gcc/ada/adaint.c:2944:15: error: invalid conversion from
'void*' to 'char*' [-fpermissive]
make[3]: *** [ada/adaint.o] Error 1
g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables
-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H
-I. -Iada -I../../../src/gcc-4.8.0/gcc -I../../../src/gcc-4.8.0/gcc/ada
-I../../../src/gcc-4.8.0/gcc/../include -I./../intl
-I../../../src/gcc-4.8.0/gcc/../libcpp/include
-I/SCRATCH/tmp.sTvWvLQnyU/install/include
-I/SCRATCH/tmp.sTvWvLQnyU/install/include
-I/SCRATCH/tmp.sTvWvLQnyU/install/include
-I../../../src/gcc-4.8.0/gcc/../libdecnumber
-I../../../src/gcc-4.8.0/gcc/../libdecnumber/bid -I../libdecnumber
-I../../../src/gcc-4.8.0/gcc/../libbacktrace -DCLOOG_INT_GMP
-I/SCRATCH/tmp.sTvWvLQnyU/install/include
-I/SCRATCH/tmp.sTvWvLQnyU/install/include
../../../src/gcc-4.8.0/gcc/ada/initialize.c -o ada/initialize.o
../../../src/gcc-4.8.0/gcc/ada/initialize.c: In function 'void append_arg(int*,
LPWSTR, LPWSTR, char***, int*, int)':
../../../src/gcc-4.8.0/gcc/ada/initialize.c:91:56: error: invalid conversion
from 'void*' to 'LPWSTR {aka wchar_t*}' [-fpermissive]
../../../src/gcc-4.8.0/gcc/ada/initialize.c:98:65: error: invalid conversion
from 'void*' to 'LPWSTR {aka wchar_t*}' [-fpermissive]
../../../src/gcc-4.8.0/gcc/ada/initialize.c: In function 'void
__gnat_initialize(void*)':
../../../src/gcc-4.8.0/gcc/ada/initialize.c:206:44: error: invalid conversion
from 'void*' to 'LPWSTR {aka wchar_t*}' [-fpermissive]
make[3]: *** [ada/initialize.o] Error 1
g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables
-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H
-I. -Iada -I../../../src/gcc-4.8.0/gcc -I../../../src/gcc-4.8.0/gcc/ada
-I
[Bug libfortran/55705] New: [4.7 Regression] error: 'CLOCK_REALTIME' undeclared in libgfortran/intrinsics/system_clock.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55705 Bug #: 55705 Summary: [4.7 Regression] error: 'CLOCK_REALTIME' undeclared in libgfortran/intrinsics/system_clock.c Classification: Unclassified Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: rai...@emrich-ebersheim.de /bin/sh ./libtool --tag=CC --mode=compile /SCRATCH/tmp.wOrMZOydvQ/gcc-4.7.3/gcc-4.7.3/./gcc/xgcc -B/SCRATCH/tmp.wOrMZOydvQ/gcc-4.7.3/gcc-4.7.3/./gcc/ -L/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.3/x86_64-w64-mingw32/lib -L/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.3/mingw/lib -isystem /opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.3/x86_64-w64-mingw32/include -isystem /opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.3/mingw/include -B/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.3/x86_64-w64-mingw32/bin/ -B/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.3/x86_64-w64-mingw32/lib/ -isystem /opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.3/x86_64-w64-mingw32/include -isystem /opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.3/x86_64-w64-mingw32/sys-include -DHAVE_CONFIG_H -I. -I../../../../src/gcc-4.7.3/libgfortran -iquote../../../../src/gcc-4.7.3/libgfortran/io -I../../../../src/gcc-4.7.3/libgfortran/../gcc -I../../../../src/gcc-4.7.3/libgfortran/../gcc/config -I../../../../src/gcc-4.7.3/libgfortran/../libquadmath -I../.././gcc -I../../../../src/gcc-4.7.3/libgfortran/../libgcc -I../libgcc -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -ffunction-sections -fdata-sections -g -O2 -MT system_clock.lo -MD -MP -MF .deps/system_clock.Tpo -c -o system_clock.lo `test -f 'intrinsics/system_clock.c' || echo '../../../../src/gcc-4.7.3/libgfortran/'`intrinsics/system_clock.c true DO=all multi-do # make libtool: compile: /SCRATCH/tmp.wOrMZOydvQ/gcc-4.7.3/gcc-4.7.3/./gcc/xgcc -B/SCRATCH/tmp.wOrMZOydvQ/gcc-4.7.3/gcc-4.7.3/./gcc/ -L/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.3/x86_64-w64-mingw32/lib -L/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.3/mingw/lib -isystem /opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.3/x86_64-w64-mingw32/include -isystem /opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.3/mingw/include -B/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.3/x86_64-w64-mingw32/bin/ -B/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.3/x86_64-w64-mingw32/lib/ -isystem /opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.3/x86_64-w64-mingw32/include -isystem /opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-4.7.3/x86_64-w64-mingw32/sys-include -DHAVE_CONFIG_H -I. -I../../../../src/gcc-4.7.3/libgfortran -iquote../../../../src/gcc-4.7.3/libgfortran/io -I../../../../src/gcc-4.7.3/libgfortran/../gcc -I../../../../src/gcc-4.7.3/libgfortran/../gcc/config -I../../../../src/gcc-4.7.3/libgfortran/../libquadmath -I../.././gcc -I../../../../src/gcc-4.7.3/libgfortran/../libgcc -I../libgcc -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -ffunction-sections -fdata-sections -g -O2 -MT system_clock.lo -MD -MP -MF .deps/system_clock.Tpo -c ../../../../src/gcc-4.7.3/libgfortran/intrinsics/system_clock.c -DDLL_EXPORT -DPIC -o .libs/system_clock.o ../../../../src/gcc-4.7.3/libgfortran/intrinsics/system_clock.c: In function 'gf_gettime_mono': ../../../../src/gcc-4.7.3/libgfortran/intrinsics/system_clock.c:84:3: warning: implicit declaration of function 'clock_gettime' [-Wimplicit-function-declaration] ../../../../src/gcc-4.7.3/libgfortran/intrinsics/system_clock.c:84:24: error: 'CLOCK_REALTIME' undeclared (first use in this function) ../../../../src/gcc-4.7.3/libgfortran/intrinsics/system_clock.c:84:24: note: each undeclared identifier is reported only once for each function it appears in make[3]: *** [system_clock.lo] Error 1
[Bug libmudflap/53952] [4.8 Regression] FAIL: libmudflap.c++/pass55-frag.cxx ( -O[123]) execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53952 --- Comment #5 from Alexandre Oliva 2012-12-15 10:25:24 UTC --- Author: aoliva Date: Sat Dec 15 10:25:15 2012 New Revision: 194519 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194519 Log: PR libmudflap/53952 * expr.c (mem_ref_refers_to_non_mem_p): Factor out implementation into... (addr_expr_of_non_mem_decl_p_1): ... this new function. (addr_expr_of_non_mem_decl_p): New. * tree.h (addr_expr_of_non_mem_decl_p): Declare. * tree-mudflap.c (mf_xform_derefs_1): Don't change MEM_REFs and TARGET_MEM_REFs that have an ADDR_EXPR of a non-mem DECL as base operand. Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/tree-mudflap.c trunk/gcc/tree.h
[Bug tree-optimization/55684] [4.8 Regression] ICE in remove_redundant_iv_tests, at tree-ssa-loop-ivcanon.c:559
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55684 Andrew Pinski changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #9 from Andrew Pinski 2012-12-15 10:29:21 UTC --- *** Bug 55697 has been marked as a duplicate of this bug. ***
[Bug c/55697] Another ice in remove_redundant_iv_tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55697 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #3 from Andrew Pinski 2012-12-15 10:29:21 UTC --- dup. *** This bug has been marked as a duplicate of bug 55684 ***
[Bug libmudflap/53952] [4.8 Regression] FAIL: libmudflap.c++/pass55-frag.cxx ( -O[123]) execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53952 Alexandre Oliva changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Alexandre Oliva 2012-12-15 10:30:04 UTC --- Fixed
[Bug bootstrap/55706] New: [4.8 Regression] failue to build libstdc++ in stage 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55706
Bug #: 55706
Summary: [4.8 Regression] failue to build libstdc++ in stage 1
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rai...@emrich-ebersheim.de
Created attachment 28976
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28976
error log
There are a lot of failures, huge error log attached.
For me it looks like the root cause is the following:
libstdc++-v3/include/bits/basic_string.h:2971:22: note: mismatched types
'std::size_t {aka long long unsigned int}' and 'const wchar_t*'
That causes for example
error: no matching function for call to '__to_xstring(int (*)(wchar_t*, const
wchar_t*, char*), long long unsigned int, const wchar_t [3], unsigned int&)'
an leads to template argument deduction/substitution failed.
[Bug fortran/55072] [4.6/4.7/4.8 Regression] Missing internal_pack leads to wrong code with derived type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55072 --- Comment #8 from janus at gcc dot gnu.org 2012-12-15 10:56:26 UTC --- (In reply to comment #7) > The following patch (which amounts to a partial revert of r156749) fixes the > behavior of comment #2 for me: Note: The patch in comment #7 actually fixes both test cases (comment #0 and #2), and is in that sense superior over the patch in comment #1. However, it yields the following testsuite failures: FAIL: gfortran.dg/assumed_type_2.f90 -O0 scan-tree-dump-times original "sub_array_assumed \\(D" 2 FAIL: gfortran.dg/assumed_type_2.f90 -O0 scan-tree-dump-times original "\\.data = \\(void .\\) &array_t1.0.;" 1 FAIL: gfortran.dg/assumed_type_2.f90 -O0 scan-tree-dump-times original "sub_array_assumed \\(\\(struct t1.0:. .\\) parm" 1 FAIL: gfortran.dg/assumed_type_2.f90 -O0 scan-tree-dump-times original "sub_array_assumed \\(\\(struct t3.0:. .\\) array_t3_ptr.data\\);" 1 FAIL: gfortran.dg/internal_pack_10.f90 -O0 execution test
[Bug bootstrap/55707] New: [4.7 Regression] bootstrap fails in gcc/graphite-dependences.c error cast loses precision
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55707
Bug #: 55707
Summary: [4.7 Regression] bootstrap fails in
gcc/graphite-dependences.c error cast loses precision
Classification: Unclassified
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rai...@emrich-ebersheim.de
Issue on LLP64 systems. Simple proposed patch:
Index: graphite-dependences.c
===
--- graphite-dependences.c (Revision 194496)
+++ graphite-dependences.c (Arbeitskopie)
@@ -56,7 +56,7 @@ hash_poly_ddr_p (const void *pddr)
{
const struct poly_ddr *p = (const struct poly_ddr *) pddr;
- return (hashval_t) ((long) PDDR_SOURCE (p) + (long) PDDR_SINK (p));
+ return (hashval_t) ((intptr_t) PDDR_SOURCE (p) + (intptr_t) PDDR_SINK (p));
}
/* Returns true when PDDR has no dependence. */
[Bug fortran/55072] [4.6/4.7/4.8 Regression] Missing internal_pack leads to wrong code with derived type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55072
--- Comment #9 from janus at gcc dot gnu.org 2012-12-15 11:00:09 UTC ---
(In reply to comment #7)
> The following patch (which amounts to a partial revert of r156749) fixes the
> behavior of comment #2 for me:
Ugh. Apparently it was much too late last night, when I accidentally re-posted
the patch of comment #1 instead of the one I actually wanted to post:
Index: gcc/fortran/trans-array.c
===
--- gcc/fortran/trans-array.c(revision 194387)
+++ gcc/fortran/trans-array.c(working copy)
@@ -7002,13 +7002,6 @@ gfc_conv_array_parameter (gfc_se * se, gfc_expr *
if (sym->ts.type == BT_CHARACTER)
se->string_length = sym->ts.u.cl->backend_decl;
- if (sym->ts.type == BT_DERIVED || sym->ts.type == BT_CLASS)
-{
- gfc_conv_expr_descriptor (se, expr);
- se->expr = gfc_conv_array_data (se->expr);
- return;
-}
-
if (!sym->attr.pointer
&& sym->as
&& sym->as->type != AS_ASSUMED_SHAPE
This is the patch that both comment 7 and comment 8 refer to.
[Bug libfortran/30162] [4.7/4.8 Regression] I/O with named pipes does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162 Thomas Koenig changed: What|Removed |Added Status|REOPENED|ASSIGNED AssignedTo|unassigned at gcc dot |tkoenig at gcc dot gnu.org |gnu.org |
[Bug ada/51555] Thinks System.Address is 64 bits wide when compiling with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51555 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot ||gnu.org Resolution||WORKSFORME --- Comment #1 from Eric Botcazou 2012-12-15 11:04:22 UTC --- You need to pass --RTS=... to the compiler.
[Bug ada/51898] Assertion failure in sinfo.adb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51898 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-12-15 CC||ebotcazou at gcc dot ||gnu.org Summary|gcc assertion |Assertion failure in ||sinfo.adb Ever Confirmed|0 |1 --- Comment #1 from Eric Botcazou 2012-12-15 11:04:53 UTC --- 4.4.x is no longer maintainer. Please try with newer versions.
[Bug ada/54549] Assertion failure in sinfo.adb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54549 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot ||gnu.org Summary|Compilation Error : |Assertion failure in |Assertion Failure |sinfo.adb Severity|blocker |normal
[Bug ada/52123] [4.7/4.8 Regression] gcc bootstrap with ada fails on mingw target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52123 Eric Botcazou changed: What|Removed |Added CC||rai...@emrich-ebersheim.de --- Comment #3 from Eric Botcazou 2012-12-15 11:07:07 UTC --- *** Bug 55704 has been marked as a duplicate of this bug. ***
[Bug ada/55704] [4.7/4.8 Regression] Failures building ada
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55704 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot ||gnu.org Resolution||DUPLICATE --- Comment #2 from Eric Botcazou 2012-12-15 11:07:07 UTC --- . *** This bug has been marked as a duplicate of bug 52123 ***
[Bug ada/55088] ada tarball missing COPYING file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55088 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot ||gnu.org Resolution||WONTFIX --- Comment #2 from Eric Botcazou 2012-12-15 11:07:54 UTC --- .
[Bug ada/53996] format string issue in gcc-interface/utils.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53996 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-15 CC||ebotcazou at gcc dot ||gnu.org Version|unknown |4.8.0 Summary|[PATCH] fixed format string |format string issue in |issue in|gcc-interface/utils.c |/gcc/gcc/ada/gcc-interface/ | |utils.c | Ever Confirmed|0 |1 --- Comment #1 from Eric Botcazou 2012-12-15 12:01:08 UTC --- Confirmed, will apply.
[Bug bootstrap/55706] [4.8 Regression] failue to build libstdc++ in stage 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55706 --- Comment #1 from Jonathan Wakely 2012-12-15 12:43:15 UTC --- This implies the type of std::vswprintf is wrong on that platform.
[Bug bootstrap/55706] [4.8 Regression] failue to build libstdc++ in stage 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55706 --- Comment #2 from Jonathan Wakely 2012-12-15 12:47:13 UTC --- Ah of course, this is the fix for PR 52015 You need to use at least r5437 from the Mingw-w64 trunk for 4.8, I will update the release notes today
[Bug c++/55708] New: g++ crashes: constexpr function with reference parameters.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55708
Bug #: 55708
Summary: g++ crashes: constexpr function with reference
parameters.
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lundb...@gmail.com
The following code crashes g++ 4.8-20121209 (and gcc 4.7.2). The issue occurs
with some uses of the result of a constexpr function with reference parameters
(&& or &).
Both the normal template do_y() and user defoned literal _y() shows exactly the
same problem, via the assert at cp/pt.c:14334.
Perhaps related: bug 49514, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49514
Full example:
template
struct AA { static constexpr int val = N; };
template
//constexpr unsigned long long mymax(A a,B b){ // <-- compiles
constexpr unsigned long long mymax(A && a,const B& b){
return a
constexpr long long operator"" _y() noexcept
{
return AA<1, mymax(1,2)>::val; // <-- crashes gcc
// return mymax(1,2); // <-- compiles
// return AA<1,2>::val; // <-- compiles
}
template
constexpr unsigned long long do_y() noexcept
{
return AA<1, mymax(1,2)>::val; <-- crashes gcc
}
int main(){
return 1_y + do_y() ;
}
I compiled with g++ -Wall -Wextra file.cpp -std=c++11
Here's the full g++ printout:
In function ‘constexpr long long int operator"" _y()’:
internal compiler error: in tsubst_copy_and_build, at cp/pt.c:14334
return AA<1, mymax(1,2)>::val;
^
0x81a4dc9 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../.././gcc/cp/pt.c:14334
0x81ed922 tsubst_non_call_postfix_expression
../.././gcc/cp/pt.c:13229
0x81a0422 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../.././gcc/cp/pt.c:13452
0x81a0a99 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../.././gcc/cp/pt.c:13352
0x81a1439 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../.././gcc/cp/pt.c:13760
0x81a5c3a fold_non_dependent_expr_sfinae(tree_node*, int)
../.././gcc/cp/pt.c:5081
0x81c48bd convert_nontype_argument
../.././gcc/cp/pt.c:5493
0x81c48bd convert_template_argument
../.././gcc/cp/pt.c:6383
0x81ca30b coerce_template_parms
../.././gcc/cp/pt.c:6722
0x81cc506 lookup_template_class_1
../.././gcc/cp/pt.c:7226
0x81cc506 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../.././gcc/cp/pt.c:7523
0x82dbc87 finish_template_type(tree_node*, tree_node*, int)
../.././gcc/cp/semantics.c:2791
0x8267f40 cp_parser_template_id
../.././gcc/cp/parser.c:12707
0x826834a cp_parser_class_name
../.././gcc/cp/parser.c:18105
0x825cf49 cp_parser_qualifying_entity
../.././gcc/cp/parser.c:5276
0x825cf49 cp_parser_nested_name_specifier_opt
../.././gcc/cp/parser.c:5007
0x8275975 cp_parser_simple_type_specifier
../.././gcc/cp/parser.c:13882
0x825be2a cp_parser_postfix_expression
../.././gcc/cp/parser.c:5551
0x825e5ab cp_parser_unary_expression
../.././gcc/cp/parser.c:6686
0x825f185 cp_parser_binary_expression
../.././gcc/cp/parser.c:7360
[Bug fortran/55072] [4.6/4.7/4.8 Regression] Missing internal_pack leads to wrong code with derived type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55072 --- Comment #10 from janus at gcc dot gnu.org 2012-12-15 13:06:37 UTC --- Here is a reduced version of internal_pack_10.f90, which is the only runtime-failure in the testsuite for the patch in comment #9: module mo_obs_rules type t_set integer :: use = 0 end type type t_rules character(len=10) :: comment type(t_set) :: c (1) end type contains subroutine set_set_v (src) type(t_set), intent(in):: src(1) if (any (src%use .ne. 99)) call abort end subroutine end module program test use mo_obs_rules type (t_rules) :: ru (1) ru(1)%c(:)%use = 99 call set_set_v (ru(1)%c) end program The problem is that, without the patch, an array descriptor is generated for the argument to 'set_set_v': parm.3.data = (void *) &ru[0].c[0]; parm.3.offset = -1; set_set_v ((struct t_set[0:] *) parm.3.data); which is not the case with the patch: set_set_v (&ru);
[Bug bootstrap/55706] [4.8 Regression] failue to build libstdc++ in stage 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55706 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Jonathan Wakely 2012-12-15 13:08:13 UTC --- This is now documented http://gcc.gnu.org/gcc-4.8/changes.html#targets
[Bug fortran/55072] [4.6/4.7/4.8 Regression] Missing internal_pack leads to wrong code with derived type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55072
--- Comment #11 from janus at gcc dot gnu.org 2012-12-15 13:46:26 UTC ---
Ok, revised version of the patch from comment 9, which fixes the runtime
failure on internal_pack_10.f90:
Index: gcc/fortran/trans-array.c
===
--- gcc/fortran/trans-array.c(revision 194517)
+++ gcc/fortran/trans-array.c(working copy)
@@ -6995,20 +6995,14 @@ gfc_conv_array_parameter (gfc_se * se, gfc_expr *
this_array_result = false;
/* Passing address of the array if it is not pointer or assumed-shape. */
- if (full_array_var && g77 && !this_array_result)
+ if (full_array_var && g77 && !this_array_result
+ && sym->ts.type != BT_DERIVED && sym->ts.type != BT_CLASS)
{
tmp = gfc_get_symbol_decl (sym);
if (sym->ts.type == BT_CHARACTER)
se->string_length = sym->ts.u.cl->backend_decl;
- if (sym->ts.type == BT_DERIVED || sym->ts.type == BT_CLASS)
-{
- gfc_conv_expr_descriptor (se, expr);
- se->expr = gfc_conv_array_data (se->expr);
- return;
-}
-
if (!sym->attr.pointer
&& sym->as
&& sym->as->type != AS_ASSUMED_SHAPE
Note: This still shows scan-tree-dump failures on assumed_type_2.f90, but now
only 2 of them at -O0 (instead of 4):
FAIL: gfortran.dg/assumed_type_2.f90 -O0 scan-tree-dump-times original
"sub_array_assumed \\(D" 2
FAIL: gfortran.dg/assumed_type_2.f90 -O0 scan-tree-dump-times original
"sub_array_assumed \\(\\(struct t3.0:. .\\) array_t3_ptr.data\\);" 1
Will do another full regtest ...
[Bug c/52444] gcc.dg/tree-prof/pr44777.c execution, -fprofile-generate -D_PROFILE_GENERATE fails at -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52444 --- Comment #1 from Jack Howarth 2012-12-15 14:02:23 UTC --- This issue doesn't occur under darwin10 but when object files, created under darwin10, are linked under darwin12 this runtime failure occurs. I opened radar://12875171 in case this was a darwin linker bug. The darwin linker developer looked at this crash and had the following comments... This is a (gcc) compiler bug. The crash is because register EBX is wrong in function x() after returning from the call to function y(). Function y() has some fancy jumps to labels. After recursing 1000 times, it returns but does so via messing with the stack frame: LM6: movl%ecx, %eax lealL5-L001$pb(%ebx), %edx movl(%eax), %ebp movl4(%eax), %esp jmp *%edx This code does not restore EBX. On runtimes in which EBX is the same for all functions (e.g pointer to GOT), not restoring EBX will work. But on Mac OS X, EBX is different in every function. Once it is trashed upon returning to x(), x stores some memory values via EBX. It is doing the stores to the wrong location, causing a later crash. It worked with the SL linker by luck. The smashers happened to be written to non-critical areas (__gcov_var).
[Bug c/52444] gcc.dg/tree-prof/pr44777.c execution, -fprofile-generate -D_PROFILE_GENERATE fails at -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52444 --- Comment #2 from Jack Howarth 2012-12-15 14:15:20 UTC --- Created attachment 28977 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28977 assembly file for gcc.dg/tree-prof/pr44777.c -fprofile-generate -D_PROFILE_GENERATE on x86_64-apple-darwin12 Generated with... /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/ /sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121214/gcc/testsuite/gcc.dg/tree-prof/pr44777.c -fno-diagnostics-show-caret -O0 -fprofile-generate -D_PROFILE_GENERATE -lm -m32 -o /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/gcc/pr44777.x01 --save-temps
[Bug c/52444] gcc.dg/tree-prof/pr44777.c execution, -fprofile-generate -D_PROFILE_GENERATE fails at -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52444 --- Comment #3 from Jack Howarth 2012-12-15 14:17:18 UTC --- One interesting thing is that slightly different assembly is generated each time you recompile this test case... # diff -u pr44777.s pr44777.s.PROFILE_GENERATE --- pr44777.s2012-12-15 09:10:30.0 -0500 +++ pr44777.s.PROFILE_GENERATE2012-12-15 09:08:44.0 -0500 @@ -262,7 +262,7 @@ LPBX0: .long875575397 .long0 -.long-1629035081 +.long-1629140997 .longLC0 .long___gcov_merge_add .long0 --- pr44777.s2012-12-15 09:11:23.0 -0500+++ pr44777.s.PROFILE_GENERATE2012-12-15 09:08:44.0 -0500 @@ -262,7 +262,7 @@ LPBX0: .long875575397 .long0 -.long-1628981943 +.long-1629140997 .longLC0 .long___gcov_merge_add .long0
[Bug c/52444] gcc.dg/tree-prof/pr44777.c execution, -fprofile-generate -D_PROFILE_GENERATE fails at -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52444 --- Comment #4 from Jack Howarth 2012-12-15 14:23:17 UTC --- I see the same behavior on x86_64 Fedora linux... /home/howarth/work-gcc/gcc/xgcc -B/home/howarth/work-gcc/gcc/ /home/howarth/gcc/gcc/testsuite/gcc.dg/tree-prof/pr44777.c -fno-diagnostics-show-caret -O0 -fprofile-generate -D_PROFILE_GENERATE -lm -m32 -o /home/howarth/work-gcc/gcc/testsuite/gcc/pr44777.x01 --save-temps with slightly different assembly generated in each compilation... --- pr44777.s.orig2012-12-15 09:40:32.507293659 -0500 +++ pr44777.s2012-12-15 09:40:45.323922586 -0500 @@ -250,7 +250,7 @@ .LPBX0: .long875575397 .long0 -.long-1627233075 +.long-1627220258 .long.LC0 .long__gcov_merge_add .long0
[Bug lto/55703] [4.8 Regression] ICE: in lto_fixup_prevailing_decls, at lto/lto.c:2732 in gcc.c-torture/execute/920721-4.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55703 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-12-15 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #1 from Richard Biener 2012-12-15 15:07:27 UTC --- Mine.
[Bug libfortran/55705] [4.7 Regression] error: 'CLOCK_REALTIME' undeclared in libgfortran/intrinsics/system_clock.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55705 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-12-15 Target Milestone|--- |4.7.3 Ever Confirmed|0 |1 --- Comment #1 from Richard Biener 2012-12-15 15:08:14 UTC --- Please fill in known-to-work and known-to-fail versions.
[Bug bootstrap/55707] [4.7 Regression] bootstrap fails in gcc/graphite-dependences.c error cast loses precision
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55707 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-15 Target Milestone|--- |4.7.3 Ever Confirmed|0 |1 --- Comment #1 from Richard Biener 2012-12-15 15:09:14 UTC --- Confirmed.
[Bug fortran/55072] [4.6/4.7/4.8 Regression] Missing internal_pack leads to wrong code with derived type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55072 --- Comment #12 from janus at gcc dot gnu.org 2012-12-15 16:05:36 UTC --- (In reply to comment #11) > Note: This still shows scan-tree-dump failures on assumed_type_2.f90, but now > only 2 of them at -O0 (instead of 4): > > FAIL: gfortran.dg/assumed_type_2.f90 -O0 scan-tree-dump-times original > "sub_array_assumed \\(D" 2 > FAIL: gfortran.dg/assumed_type_2.f90 -O0 scan-tree-dump-times original > "sub_array_assumed \\(\\(struct t3.0:. .\\) array_t3_ptr.data\\);" 1 > > Will do another full regtest ... Ok, I have verified that those two are indeed the only testsuite failures of the patch in comment #11.
[Bug fortran/55072] [4.6/4.7/4.8 Regression] Missing internal_pack leads to wrong code with derived type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55072
--- Comment #13 from Mikael Morin 2012-12-15
16:16:57 UTC ---
(In reply to comment #10)
> Here is a reduced version of internal_pack_10.f90, which is the only
> runtime-failure in the testsuite for the patch in comment #9:
>
[...]
> call set_set_v (ru(1)%c)
> end program
>
>
> The problem is that, without the patch, an array descriptor is generated for
> the argument to 'set_set_v':
>
> parm.3.data = (void *) &ru[0].c[0];
> parm.3.offset = -1;
> set_set_v ((struct t_set[0:] *) parm.3.data);
>
> which is not the case with the patch:
>
> set_set_v (&ru);
Well, it seems that an array descriptor isn't even necessary. But the
non-descriptor case should look like:
set_set_v (&(ru[0].c[0]));
(In reply to comment #11)
> Ok, revised version of the patch from comment 9, which fixes the runtime
> failure on internal_pack_10.f90:
>
>
> Index: gcc/fortran/trans-array.c
> ===
> --- gcc/fortran/trans-array.c(revision 194517)
> +++ gcc/fortran/trans-array.c(working copy)
> @@ -6995,20 +6995,14 @@ gfc_conv_array_parameter (gfc_se * se, gfc_expr *
> this_array_result = false;
>
>/* Passing address of the array if it is not pointer or assumed-shape. */
> - if (full_array_var && g77 && !this_array_result)
> + if (full_array_var && g77 && !this_array_result
> + && sym->ts.type != BT_DERIVED && sym->ts.type != BT_CLASS)
> {
>tmp = gfc_get_symbol_decl (sym);
>
It feels like a hack (that what there before) to blindly disable derived types
here. The real problem is that the code under the if condition supports only
bare variables without subreferences.
On the other hand it looks like a correct hack WRT the existing behaviour.
[Bug fortran/53876] [4.8 Regression] [OOP] ICE with class array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53876 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org AssignedTo|unassigned at gcc dot |pault at gcc dot gnu.org |gnu.org | --- Comment #4 from Paul Thomas 2012-12-15 16:27:12 UTC --- Tobias, Your analysis is completely correct. > > /* Set the data. */ > ctree = gfc_class_data_get (var); Inserting parmse->expr = fold_convert (TREE_TYPE (ctree), parmse->expr); before this line fixes the problem. > gfc_add_modify (&parmse->pre, ctree, parmse->expr); > > snip... > The problem is that the LHS and the RHS have a different type. Both are > pointers to a record_type, which contains "genes" (type "array1_real(kind=4)") > as component. > > However, the decl for both the record type and the "genes" type is different > (only their respective canonical type is the same). which is why the above works. > I wonder whether it has something to do with restricted and not. (See also PR > 45586). Though, as marking all variables as TARGET doesn't help, I might also > be off track. I will try to understand why the regression occurred. However, the above fix is perfectly OK. The testcase of comment 2 works with the above. The original needs a call to the constructor before the assignment in the main program to avoid the runtime fault. After I have got the unlimited polymorphic patch out of the way, I will submit this fix (my tree is too poluted right no :-) ) Cheers Paul
[Bug middle-end/55709] New: [4.8 Regression] Infinite loop in pointer_set_insert compiling cp/pt.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55709 Bug #: 55709 Summary: [4.8 Regression] Infinite loop in pointer_set_insert compiling cp/pt.c Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org CC: ja...@gcc.gnu.org, ste...@gcc.gnu.org Host: hppa-unknown-linux-gnu Target: hppa-unknown-linux-gnu Build: hppa-unknown-linux-gnu Created attachment 28978 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28978 Compressed preprocessed sourcce Hang occurs in stage2 here: /home/dave/gnu/gcc/objdir/./prev-gcc/xg++ -B/home/dave/gnu/gcc/objdir/./prev-gcc/ -B/home/dave/opt/gnu/gcc/gcc-4.8/hppa-linux-gnu/bin/ -nostdinc++ -B/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/src/.libs -B/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs -I/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/include/hppa-linux-gnu -I/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/include -I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++ -L/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/src/.libs -L/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs -c -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -Icp -I../../gcc/gcc -I../../gcc/gcc/cp -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/gcc/../libbacktrace../../gcc/gcc/cp/pt.c -o cp/pt.o (gdb) bt #0 0x006a88a4 in insert_aux (log_slots=1, n_slots=4096, slots=0x15659c0, p=0x3b579) at ../../gcc/gcc/pointer-set.c:123 #1 pointer_set_insert (pset=0xe06f20, p=0x4309cf80) at ../../gcc/gcc/pointer-set.c:153 #2 0x009d3dcc in assemble_external (decl=0x4309cf80) at ../../gcc/gcc/varasm.c:2199 #3 0x004e0608 in output_addr_const (file=0xe05a20, x=0x4421d090) at ../../gcc/gcc/final.c:3701 #4 0x009eb3ac in pa_assemble_integer (x=0x4421d090, size=, aligned_p=1) at ../../gcc/gcc/config/pa/pa.c:3221 #5 0x009d476c in assemble_integer (x=0x4421d090, size=4, align=32, force=1) at ../../gcc/gcc/varasm.c:2496 #6 0x009eb208 in output_deferred_plabels () at ../../gcc/gcc/config/pa/pa.c:5611 #7 0x0076b588 in compile_file () at ../../gcc/gcc/toplev.c:670 #8 0x0076d4ec in do_compile () at ../../gcc/gcc/toplev.c:1878 #9 toplev_main (argc=73, argv=0xfc1c002c) at ../../gcc/gcc/toplev.c:1954 #10 0x00b32bdc in main (argc=, argv=) at ../../gcc/gcc/main.c:36 This was introduced by: 2012-12-12 Steven Bosscher Jakub Jelinek PR middle-end/52640 * varasm.c (pending_assemble_externals_set): New pointer set. (process_pending_assemble_externals): Destroy the pointer set. (assemble_external): See if decl is in pending_assemble_externals_set, and add it to pending_assemble_externals if necessary. (init_varasm_once): Allocate pending_assemble_externals_set. Think pending_assemble_externals_set has been destroyed when this happens. This came up before which was why the above change wasn't installed on trunk. See PR middle-end/52894. Thought Steven was going to try to come up with something better for trunk. cc1plus options: -fpreprocessed pt.ii -quiet -dumpbase pt.c -auxbase-strip cp/pt.o -g -O2 -Wextra -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wsuggest-attribute=format -Wpedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -version -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -fno-common -o pt.s
[Bug fortran/55539] [4.8 Regression] -fno-sign-zero may generate output with the wrong sign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55539 Janne Blomqvist changed: What|Removed |Added AssignedTo|unassigned at gcc dot |jb at gcc dot gnu.org |gnu.org | --- Comment #5 from Janne Blomqvist 2012-12-15 16:36:08 UTC --- Patch: http://gcc.gnu.org/ml/gcc-patches/2012-12/msg01011.html Although Harald's patch fixed the issue for me as well, I opted for a slightly different approach. The regression crept in because in the old code we had removed the decimal point, whereas in the current code it may be included in the string we're investigating.
[Bug middle-end/55709] [4.8 Regression] Infinite loop in pointer_set_insert compiling cp/pt.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55709 --- Comment #1 from Jakub Jelinek 2012-12-15 16:40:10 UTC --- So just test the same patch as in PR52894 for trunk and submit it?
[Bug c++/55680] [C++11] Member specialization with lambda is rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55680
--- Comment #1 from Daniel Krügler
2012-12-15 16:44:08 UTC ---
The same problem exists for gcc 4.8.0 20121209 (experimental). The code looks
valid to me. I tried to deduce the root of the compiler problem here. For
example trying to rewrite it as
typedef void (*code_t) ();
template <>
code_t X::code = [](){};
but the error still exists.
[Bug fortran/55539] [4.8 Regression] -fno-sign-zero may generate output with the wrong sign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55539
--- Comment #6 from Janne Blomqvist 2012-12-15 16:47:44
UTC ---
(In reply to comment #4)
> (In reply to comment #3)
> > Strangely enough I needed to add some epsilon to 0.5 so that
> > the second test passes, because the exact value 0.5 appears
> > to get rounded down to 0 in formatted output.
>
> That should depend on the rounding mode; you have the choice between
> RD (round down), RC (compatible), RN (nearest), RP (processor dependent), RU
> (round up), RZ (round towards zero).
>
> The default ("RD") in gfortran is NEAREST, which has to match IEEE 754-1985
> (alias IEC 60559:1989), namely (cf. Note 10.14 in Fortran 2008):
Actually, for processor dependent or unspecified (default) rounding,
libgfortran does not do any rounding itself, but rather uses the snprintf()
generated digits directly; A large part of the r185433 patch was figuring out
the correct number of digits so that we could skip the libgfortran rounding
step.
That being said, a snprintf() which claims conformance to IEEE 754 should by
default provide round to nearest, ties to even rounding behavior.
> "On processors that support IEEE rounding on conversions, the I/O rounding
> modes COMPATIBLE and NEAREST will produce the same results except when the
> datum is halfway between the two representable values. In that case, NEAREST
> will pick the even value, but COMPATIBLE will pick the value away from zero.
> The I/O rounding modes UP, DOWN, and ZERO have the same e ect as those speci
> ed
> in IEC 60559:1989 for round toward +oo, round toward -oo, and round toward 0,
> respectively."
>
> And 0.5 rounded to even rounds down to "0" and not up to "1". (Seemingly,
> decimal "0.5" is exactly representable in binary FP while decimal "0.1"
> isn't.)
[Bug c++/55710] New: [C++11] Linkage errors with lambdas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55710
Bug #: 55710
Summary: [C++11] Linkage errors with lambdas
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
The following program compiled with gcc 4.8.0 20121209 (experimental) and
compiled with flags
-Wall -std=c++11 -pedantic
//
template
struct X {
static void (*code) ();
};
template
void (*X::code) () = []{}; // Line 7
struct Y {
void (*code) () = []{} ; // Line 10
void operator()() { code(); }
};
int main () {
X::code();
Y()();
}
//
gives two linkage errors:
"|In function `Y::code::{lambda()#1}::operator void (*)()() const':|
10|undefined reference to `Y::code::{lambda()#1}::_FUN()'|
|In function `X::code::{lambda()#1}::operator void (*)()() const':|
7|undefined reference to `X::code::{lambda()#1}::_FUN()'|
"
for the functions that should be defined for the corresponding uncaptured
lambda expressions.
It should be noted, that
struct Z {
static void (*code) ();
};
void (*Z::code) () = []{};
int main () {
Z::code();
}
doesn't cause a similar linkage error, though.
[Bug ada/53996] format string issue in gcc-interface/utils.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53996 --- Comment #2 from Eric Botcazou 2012-12-15 17:50:55 UTC --- Author: ebotcazou Date: Sat Dec 15 17:50:49 2012 New Revision: 194520 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194520 Log: PR ada/53996 * gcc-interface/utils.c (gnat_type_for_size): Use %u in lieu of %d. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/utils.c
[Bug ada/53996] format string issue in gcc-interface/utils.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53996 Eric Botcazou changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #3 from Eric Botcazou 2012-12-15 17:53:31 UTC --- Thanks for reporting the issue.
[Bug ada/53766] ICE in build_binary_op on Max_Size_In_Storage_Elements with -gnatp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53766 --- Comment #2 from Eric Botcazou 2012-12-15 18:11:43 UTC --- Author: ebotcazou Date: Sat Dec 15 18:11:38 2012 New Revision: 194521 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194521 Log: PR ada/53766 * gnat.dg/controlled7.ad[sb]: New test. Added: trunk/gcc/testsuite/gnat.dg/controlled7.adb trunk/gcc/testsuite/gnat.dg/controlled7.ads Modified: trunk/gcc/testsuite/ChangeLog
[Bug ada/53766] [4.7/4.8 regression] ICE in build_binary_op on Max_Size_In_Storage_Elements with -gnatp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53766 Eric Botcazou changed: What|Removed |Added Target Milestone|--- |4.7.3 Summary|ICE in build_binary_op on |[4.7/4.8 regression] ICE in |Max_Size_In_Storage_Element |build_binary_op on |s with -gnatp |Max_Size_In_Storage_Element ||s with -gnatp
[Bug target/52444] non-local gotos are broken on x86 darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52444 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |target Resolution||DUPLICATE Summary|gcc.dg/tree-prof/pr44777.c |non-local gotos are broken |execution, |on x86 darwin |-fprofile-generate | |-D_PROFILE_GENERATE fails | |at -m32 | --- Comment #5 from Andrew Pinski 2012-12-15 18:15:24 UTC --- Actually this was already filed as bug 51784 which has all the right information about what is going on. Again this is non-local gotos are broken for x86 darwin. *** This bug has been marked as a duplicate of bug 51784 ***
[Bug target/51784] PIC register not correctly preserved in nested funcs / with non-local goto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784 Andrew Pinski changed: What|Removed |Added CC||howarth at nitro dot ||med.uc.edu --- Comment #41 from Andrew Pinski 2012-12-15 18:15:24 UTC --- *** Bug 52444 has been marked as a duplicate of this bug. ***
[Bug ada/53766] [4.7/4.8 regression] ICE in build_binary_op on Max_Size_In_Storage_Elements with -gnatp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53766 --- Comment #3 from Eric Botcazou 2012-12-15 18:16:33 UTC --- Author: ebotcazou Date: Sat Dec 15 18:16:28 2012 New Revision: 194522 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194522 Log: PR ada/53766 Backport from mainline 2012-07-17 Hristian Kirtchev * exp_attr.adb (Expand_N_Attribute_Reference): Add local variables Attr and Conversion_Added. Add local constant Typ. Retrieve the original attribute after the arithmetic check machinery has modified the node. Add a conversion to the target type when the prefix of attribute Max_Size_In_Storage_Elements is a controlled type. Added: branches/gcc-4_7-branch/gcc/testsuite/gnat.dg/controlled7.adb - copied unchanged from r194521, trunk/gcc/testsuite/gnat.dg/controlled7.adb branches/gcc-4_7-branch/gcc/testsuite/gnat.dg/controlled7.ads - copied unchanged from r194521, trunk/gcc/testsuite/gnat.dg/controlled7.ads Modified: branches/gcc-4_7-branch/gcc/ada/ChangeLog branches/gcc-4_7-branch/gcc/ada/exp_attr.adb branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug ada/53766] [4.7/4.8 regression] ICE in build_binary_op on Max_Size_In_Storage_Elements with -gnatp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53766 Eric Botcazou changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Eric Botcazou 2012-12-15 18:17:30 UTC --- Thanks for reporting the problem.
[Bug c++/55710] [C++11] Linkage errors with lambdas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55710 --- Comment #1 from Andrew Pinski 2012-12-15 18:29:33 UTC --- Related to PR 55015.
[Bug target/53359] [4.8 regression] undefined reference to `__gnu_cxx::__numeric_traits_integer::__min'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53359 Alexandre Oliva changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-15 Ever Confirmed|0 |1 --- Comment #7 from Alexandre Oliva 2012-12-15 18:40:39 UTC --- Thanks. It's not the same issue, after all. These decls are recorded in deferred_static_decls, and mudflap_finish_file emits calls to mf_register for them, so they end up referenced in the toc. I suppose mudflap_finish_file needs tweaking to tell that GCC decided not to emit the symbol after all.
[Bug ada/52735] Compiler crash with gnat_to_gnu_entity, at ada/gcc-interface/decl.c:4156
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52735 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-15 CC||ebotcazou at gcc dot ||gnu.org Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #1 from Eric Botcazou 2012-12-15 18:41:12 UTC --- Confirmed in the 4.6.x and 4.7.x series.
[Bug ada/52735] Compiler crash with gnat_to_gnu_entity, at ada/gcc-interface/decl.c:4156
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52735 --- Comment #2 from Eric Botcazou 2012-12-15 18:47:57 UTC --- Author: ebotcazou Date: Sat Dec 15 18:47:53 2012 New Revision: 194523 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194523 Log: PR ada/52735 * gnat.dg/nested_generic1.adb: New test. * gnat.dg/nested_generic1_pkg.ad[sb]: New helper. Added: trunk/gcc/testsuite/gnat.dg/nested_generic1.adb trunk/gcc/testsuite/gnat.dg/nested_generic1_pkg.adb trunk/gcc/testsuite/gnat.dg/nested_generic1_pkg.ads Modified: trunk/gcc/testsuite/ChangeLog
[Bug ada/52735] ICE in gnat_to_gnu_entity at gcc-interface/decl.c:4156
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52735 Eric Botcazou changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Summary|Compiler crash with |ICE in gnat_to_gnu_entity |gnat_to_gnu_entity, at |at |ada/gcc-interface/decl.c:41 |gcc-interface/decl.c:4156 |56 | --- Comment #3 from Eric Botcazou 2012-12-15 18:49:24 UTC --- This will be fixed in the upcoming 4.8.x series.
[Bug c++/55710] [C++11] Linkage errors with lambdas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55710 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-15 Ever Confirmed|0 |1 --- Comment #2 from Paolo Carlini 2012-12-15 18:51:58 UTC --- As-is, at variance with PR 55015, this can't be a regression in mainline and 4.7.x, because 4.6.x didn't have non-static data member initializers. If Daniel can figure out something similar not-using NSDMI which worked in 4.6.x, it's much more likely to be fixed for 4.8.0.
[Bug ada/52420] ada build failure with -gdwarf-4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52420 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot ||gnu.org Resolution||WONTFIX --- Comment #1 from Eric Botcazou 2012-12-15 18:53:00 UTC --- Do not add random options to the compiler build.
[Bug c++/55710] [C++11] Linkage errors with lambdas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55710 --- Comment #3 from Daniel Krügler 2012-12-15 18:57:37 UTC --- (In reply to comment #2) Note that my first example is not related to NSDMIs, it occurs in a static data member initializer. The actual reason for understanding the possible reasons for such an error is because we stumbled across it in an - unfortunately very complex - production code. Backed with the reference to bug 55015 I try to check that with our actual code on Monday.
[Bug c++/55710] [C++11] Linkage errors with lambdas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55710 --- Comment #4 from Paolo Carlini 2012-12-15 19:03:10 UTC --- Oops, 4.6.x says that NSDMIs are needed for line 10 and rejects it, that misled me. Then, what can I say, probably the issue isn't a regression and it's only superficially similar to PR 55015 (which is already fixed)
[Bug libmudflap/53359] [4.8 regression] undefined reference to `__gnu_cxx::__numeric_traits_integer::__min'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53359
Alexandre Oliva changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |aoliva at gcc dot gnu.org
|gnu.org |
--- Comment #8 from Alexandre Oliva 2012-12-15
19:04:00 UTC ---
Jan, does a change like this seem reasonable?
--- a/gcc/tree-mudflap.c
+++ b/gcc/tree-mudflap.c
@@ -1335,6 +1335,10 @@ mudflap_finish_file (void)
if (! TREE_PUBLIC (obj) && ! TREE_ADDRESSABLE (obj))
continue;
+ /* If we're not emitting the symbol, don't register it. */
+ if (!symtab_get_node (obj))
+continue;
+
if (! COMPLETE_TYPE_P (TREE_TYPE (obj)))
{
warning (OPT_Wmudflap,
[Bug c++/55710] [C++11] Linkage errors with lambdas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55710 --- Comment #5 from Paolo Carlini 2012-12-15 19:07:34 UTC --- To repeat: in order to, so to speak, raise the priority of this issue, we need a testcase which was accepted by 4.6.x (or 4.7.x): the testcase we have got isn't Ok for that, because 4.6.x rejects it immediately, that is at compile-time, line #10.
[Bug ada/54799] Missing ";" gives "GNAT BUG DETECTED" box
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54799 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot ||gnu.org Resolution||INVALID Summary|Missing ";" gives "GNAT BUG |Missing ";" gives "GNAT BUG |DETECTED" box with GPL |DETECTED" box |2012, GPL 2010, AUX 4.7.1, | |and AUX 4.6.3 | --- Comment #2 from Eric Botcazou 2012-12-15 19:23:16 UTC --- Issues with GNAT GPL should be reported to AdaCore.
[Bug fortran/55072] [4.6/4.7/4.8 Regression] Missing internal_pack leads to wrong code with derived type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55072 --- Comment #14 from janus at gcc dot gnu.org 2012-12-15 19:46:37 UTC --- (In reply to comment #13) > (In reply to comment #11) > > Ok, revised version of the patch from comment 9, which fixes the runtime > > failure on internal_pack_10.f90: > > > > [...] > > > It feels like a hack (that what there before) to blindly disable derived types > here. The real problem is that the code under the if condition supports only > bare variables without subreferences. > On the other hand it looks like a correct hack WRT the existing behaviour. Well, yeah. My primary concern right now is really to get the regression fixed ASAP (this sort of wrong-code regression is pretty much the worst thing which can happen in terms of compiler bugs, I guess). But of course you're right about the underlying problem. If you are willing to fix this, it would be greatly appreciated. (I currently do not have the capacities to take care of it, unfortunately.)
[Bug c++/55710] [C++11] Linkage errors with lambdas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55710
--- Comment #6 from Daniel Krügler
2012-12-15 19:55:56 UTC ---
(In reply to comment #5)
So will the following do that:
//
template
struct X {
static void (*code) ();
};
template
void (*X::code) () = []{}; // Line 7
int main () {
X::code();
}
//
giving me
"In function `X::code::{lambda()#1}::operator void (*)()() const':|
|7|undefined reference to `X::code::{lambda()#1}::_FUN()'|
"
?
[Bug ada/53766] [4.7/4.8 regression] ICE in build_binary_op on Max_Size_In_Storage_Elements with -gnatp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53766 --- Comment #5 from Duncan Sands 2012-12-15 20:04:16 UTC --- Thanks for fixing the problem!
[Bug fortran/55072] [4.6/4.7/4.8 Regression] Missing internal_pack leads to wrong code with derived type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55072
--- Comment #15 from janus at gcc dot gnu.org 2012-12-15 20:47:00 UTC ---
(In reply to comment #11)
> FAIL: gfortran.dg/assumed_type_2.f90 -O0 scan-tree-dump-times original
> "sub_array_assumed \\(D" 2
> FAIL: gfortran.dg/assumed_type_2.f90 -O0 scan-tree-dump-times original
> "sub_array_assumed \\(\\(struct t3.0:. .\\) array_t3_ptr.data\\);" 1
Here is a reduced test case for these two failure (which are apparently due to
a single underlying problem):
! { dg-do compile }
! { dg-options "-fdump-tree-original" }
implicit none
type :: t3
integer :: c
end type t3
type(t3), pointer :: array_t3_ptr(:,:)
call sub_array_assumed (array_t3_ptr)
contains
subroutine sub_array_assumed (arg3)
type(*), target :: arg3(*)
end subroutine
end
! { dg-final { scan-tree-dump-times "sub_array_assumed \\(D" 0 "original" } }
! { dg-final { scan-tree-dump-times "sub_array_assumed \\(\\(struct t3.0:. .\\)
array_t3_ptr.data\\);" 1 "original" } }
! { dg-final { cleanup-tree-dump "original" } }
The point is this: Without the patch, the subroutine call is translated to:
sub_array_assumed ((struct t3[0:] *) array_t3_ptr.data);
while, with the patch, it becomes:
D.1892 = _gfortran_internal_pack (&array_t3_ptr);
sub_array_assumed (D.1892);
i.e., the argument is packed.
Question is: Is the packing needed here? I would guess that it isn't. And if
not, how do we best avoid it?
[Bug c/55711] New: Internal compiler error while compiling openssl1.0.1c/crypto/asn1/a_strex.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55711 Bug #: 55711 Summary: Internal compiler error while compiling openssl1.0.1c/crypto/asn1/a_strex.c Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: delorme.hug...@fougsys.fr Created attachment 28979 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28979 The preprocessed file that triggers the bug gcc -v Using built-in specs. COLLECT_GCC=/opt/bin/mingw-w64/bin/x86_64-w64-mingw32-gcc COLLECT_LTO_WRAPPER=/opt/bin/mingw-w64/bin/../libexec/gcc/x86_64-w64-mingw32/4.8.0/lto-wrapper Target: x86_64-w64-mingw32 Configured with: ../../../build/gcc/src/configure --target=x86_64-w64-mingw32 --prefix=/home/mingw-w64/slave-root/linux-x86_64-x86_64/build/build/root --with-sysroot=/home/mingw-w64/slave-root/linux-x86_64-x86_64/build/build/root --with-gnu-ld --with-gnu-as --enable-fully-dynamic-string --disable-multilib Thread model: win32 gcc version 4.8.0 20121031 (experimental) (GCC) Host system : kubuntu 12.04 Complete command line (from openssl-1.0.1c/crypto/asn1) : x86_64-w64-mingw32-gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -D_WINDLL -DOPENSSL_PIC -DOPENSSL_THREADS -D_MT -DDSO_WIN32 -DL_ENDIAN -O3 -Wall -DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -c -o a_strex.o a_strex.c Compiler output : a_strex.c:574:1: internal compiler error: in inline_call, at ipa-inline-transform.c:269 } ^ 0xd1670b inline_call(cgraph_edge*, bool, vec_t**, int*, bool) ../../../../build/gcc/src/gcc/ipa-inline-transform.c:265 0xd1503b inline_small_functions ../../../../build/gcc/src/gcc/ipa-inline.c:1553 0xd1503b ipa_inline ../../../../build/gcc/src/gcc/ipa-inline.c:1735
[Bug fortran/55072] [4.6/4.7/4.8 Regression] Missing internal_pack leads to wrong code with derived type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55072 --- Comment #16 from janus at gcc dot gnu.org 2012-12-15 21:06:11 UTC --- (In reply to comment #15) > > type(t3), pointer :: array_t3_ptr(:,:) > > call sub_array_assumed (array_t3_ptr) > > contains > > subroutine sub_array_assumed (arg3) > type(*), target :: arg3(*) > end subroutine > > end > > [...] > > Question is: Is the packing needed here? I would guess that it isn't. Of course I might be wrong here. After all, array_t3_ptr is a pointer, so it's not guaranteed to be contiguous, right? If the packing is indeed required in this place, we just need to fix the test case (assumed_type_2.f90) ...
[Bug fortran/55072] [4.6/4.7/4.8 Regression] Missing internal_pack leads to wrong code with derived type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55072
--- Comment #17 from janus at gcc dot gnu.org 2012-12-15 21:26:32 UTC ---
(In reply to comment #16)
> > Question is: Is the packing needed here? I would guess that it isn't.
>
> Of course I might be wrong here. After all, array_t3_ptr is a pointer, so it's
> not guaranteed to be contiguous, right?
To answer that myself, I think the packing is indeed needed here. At least it
is also done for similar cases in the same test case, such as this one:
character, pointer :: array_char_ptr(:,:)
call sub_array_assumed (array_char_ptr)
> If the packing is indeed required in this place, we just need to fix the test
> case (assumed_type_2.f90) ...
... like this:
Index: gcc/testsuite/gfortran.dg/assumed_type_2.f90
===
--- gcc/testsuite/gfortran.dg/assumed_type_2.f90(revision 194517)
+++ gcc/testsuite/gfortran.dg/assumed_type_2.f90(working copy)
@@ -157,7 +157,7 @@ end
! { dg-final { scan-tree-dump-times "sub_scalar .\\(struct t1 .\\)
array_class_t1_alloc._data.data" 1 "original" } }
! { dg-final { scan-tree-dump-times "sub_scalar .\\(struct t1 .\\)
array_class_t1_ptr._data.dat" 1 "original" } }a
-! { dg-final { scan-tree-dump-times "sub_array_assumed \\(D" 2 "original" } }
+! { dg-final { scan-tree-dump-times "sub_array_assumed \\(D" 3 "original" } }
! { dg-final { scan-tree-dump-times " = _gfortran_internal_pack \\(&parm" 1
"original" } }
! { dg-final { scan-tree-dump-times "sub_array_assumed \\(&array_int\\)" 1
"original" } }
! { dg-final { scan-tree-dump-times "sub_array_assumed
\\(\\(real\\(kind=4\\).0:. . restrict\\) array_real_alloc.data" 1 "original" }
}
@@ -165,7 +165,6 @@ end
! { dg-final { scan-tree-dump-times "\\.data = \\(void .\\) &array_t1.0.;" 1
"original" } }
! { dg-final { scan-tree-dump-times "sub_array_assumed \\(\\(struct t1.0:.
.\\) parm" 1 "original" } }
! { dg-final { scan-tree-dump-times "sub_array_assumed \\(\\(struct t2.0:. .
restrict\\) array_t2_alloc.data\\);" 1 "original" } }
-! { dg-final { scan-tree-dump-times "sub_array_assumed \\(\\(struct t3.0:.
.\\) array_t3_ptr.data\\);" 1 "original" } }
! { dg-final { scan-tree-dump-times "sub_array_assumed \\(\\(struct t1.0:. .
restrict\\) array_class_t1_alloc._data.data\\);" 1 "original" } }
! { dg-final { scan-tree-dump-times "sub_array_assumed \\(\\(struct t1.0:.
.\\) array_class_t1_ptr._data.data\\);" 1 "original" } }
[Bug c/55695] Miscompilation of pow() & sqrt() using musl libc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55695 ojab changed: What|Removed |Added CC||joseph at codesourcery dot ||com --- Comment #4 from ojab 2012-12-15 22:18:28 UTC --- Bisection told me that a75b1c712f1eaddc69919461ead67f4ac21663fe is the first bad commit commit a75b1c712f1eaddc69919461ead67f4ac21663fe Author: jsm28 Date: Sun Mar 29 18:13:43 2009 + PR c/456 PR c/5675 PR c/19976 PR c/29116 PR c/31871 PR c/35198 … git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@145254 138bc75d-0d04-0410-961f-82ee72b054a4 Adding author to CC.
[Bug fortran/55638] Wrongly accepts INTENT + VALUE - and wrongly requires it for PURE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55638 --- Comment #2 from Tobias Burnus 2012-12-15 23:25:41 UTC --- Author: burnus Date: Sat Dec 15 23:25:36 2012 New Revision: 194525 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194525 Log: 2012-12-16 Tobias Burnus PR fortran/55638 * resolve.c (resolve_formal_arglist): Allow VALUE without INTENT for ELEMENTAL procedures. 2012-12-16 Tobias Burnus PR fortran/55638 * gfortran.dg/elemental_args_check_3.f90: Update dg-error. * gfortran.dg/elemental_args_check_7.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/elemental_args_check_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/elemental_args_check_3.f90
[Bug fortran/55072] [4.6/4.7/4.8 Regression] Missing internal_pack leads to wrong code with derived type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55072 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org |gnu.org | --- Comment #18 from janus at gcc dot gnu.org 2012-12-15 23:40:43 UTC --- (In reply to comment #17) > (In reply to comment #16) > > > Question is: Is the packing needed here? I would guess that it isn't. > > > > Of course I might be wrong here. After all, array_t3_ptr is a pointer, so > > it's > > not guaranteed to be contiguous, right? > > To answer that myself, I think the packing is indeed needed here. In fact this is exactly the case of comment 0. So, yes, we definitely need the packing!
[Bug target/55711] Internal compiler error while compiling openssl1.0.1c/crypto/asn1/a_strex.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55711 Andrew Pinski changed: What|Removed |Added Severity|critical|normal
