[Bug c++/56951] New: Poor diagnostics for error: invalid abstract return type 'XXX'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56951
Bug #: 56951
Summary: Poor diagnostics for error: invalid abstract return
type 'XXX'
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
Consider the following test case:
#include vector
using std::vector;
using std::iterator_traits;
template typename struct remove_pointer;
template typename T struct remove_pointerT * { typedef T type; };
template typename It
class iterator_ptr {
typedef typename remove_pointer
typename iterator_traitsIt::value_type::type value_type;
value_type Get();
};
class Table;
class F {
typedef iterator_ptrvectorTable *::iterator iterator;
iterator tables_begin() {}
};
class Table {
virtual void Fn() = 0;
};
This code is accepted by gcc-4.7.x, rejected by current trunk with:
g++ -c tt.cc
tt.cc:13:14: error: invalid abstract return type ‘Table’
value_type Get();
^
tt.cc:23:7: note: because the following virtual functions are pure within
‘Table’:
class Table {
^
tt.cc:24:16: note: virtual void Table::Fn()
virtual void Fn() = 0;
^
I believe the code is in fact invalid.
Note that the error tells me the template line (13), but doesn't tell
what parameters this template was instantiated with, nor what triggered
the instantiation.
Compare to much better error produced when I move 'class Table'
definition ahead of F:
#include vector
using std::vector;
using std::iterator_traits;
template typename struct remove_pointer;
template typename T struct remove_pointerT * { typedef T type; };
template typename It
class iterator_ptr {
typedef typename remove_pointer
typename iterator_traitsIt::value_type::type value_type;
value_type Get();
};
class Table {
virtual void Fn() = 0;
};
class F {
typedef iterator_ptrvectorTable *::iterator iterator;
iterator tables_begin() {}
};
g++ -c tt2.cc
tt2.cc: In instantiation of ‘class
iterator_ptr__gnu_cxx::__normal_iteratorTable**, std::vectorTable* ’:
tt2.cc:22:27: required from here
tt2.cc:13:14: error: invalid abstract return type ‘Table’
value_type Get();
^
tt2.cc:16:7: note: because the following virtual functions are pure within
‘Table’:
class Table {
^
tt2.cc:17:16: note: virtual void Table::Fn()
virtual void Fn() = 0;
^
[Bug ada/56909] [4.8 regression] s-atopri.adb:multiple undefined references on mingw32 --with-arch=i486
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56909 --- Comment #9 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-04-14 06:45:18 UTC --- On MinGW, GCC 4.7.x Ada built successfully with default (no -with-arch or -with-tune) configure. GCC 4.8.0 s-atopri.* changes breaks same configure: 1. with default (no -with-arch or -with-tune): failed with five undefined reference (as the top of this ticket) OK, I missed that, then configure with --build=i686-pc-mingw32.
[Bug other/56881] Miscompilation (optimisation failure?) causing NULL dereference and segfault at runtime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56881
Mikael Pettersson mikpe at it dot uu.se changed:
What|Removed |Added
CC|mikpe at it dot uu.se |
--- Comment #8 from Mikael Pettersson mikpe at it dot uu.se 2013-04-14
08:56:47 UTC ---
The error is in the test case. It overrides the libc memmove() with its own
implementation, but that implementation fails to follow the specification. In
particular, it returns NULL rather than memmove()'s first parameter.
GCC now optimizes based on this aspect of the specification, so things go wrong
at runtime.
Correcting the test case as follows allows it to work with gcc 4.8 and 4.9:
--- unix.c.~1~ 2013-03-06 23:17:26.0 +0100
+++ unix.c 2013-04-14 10:45:24.651407693 +0200
@@ -110,7 +110,7 @@ memmove(void *dp, const void *sp, size_t
unsigned char *cdp, *csp;
if (n=0)
- return 0;
+ return dp;
cdp = dp;
csp = (unsigned char *)sp;
if (cdp csp) {
@@ -124,6 +124,6 @@ memmove(void *dp, const void *sp, size_t
*--cdp = *--csp;
} while (--n);
}
- return 0;
+ return dp;
}
#endif
Not a bug in GCC. Please close as INVALID.
[Bug rtl-optimization/56952] New: [4.9 regression] ICE in recog.c:2150
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56952 Bug #: 56952 Summary: [4.9 regression] ICE in recog.c:2150 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: jojel...@gmail.com $ /tmp/gcc/host-i686-pc-cygwin/gcc/xgcc -B/tmp/gcc/host-i686-pc-cygwin/gcc/ -B/usr/i686-pc-cygwin/bin/ -B/usr/i686-pc-cygwin/lib/ -isystem /usr/i686-pc-cygwin/include -isystem /usr/i686-pc-cygwin/sys-include-O2 -O2 -I../.././libgcc/../winsup/w32api/include -I../.././libgcc/../winsup/include -I../.././libgcc/../winsup/cygwin/include -DIN_GCC -g -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -I. -I. -I../../host-i686-pc-cygwin/gcc -I../.././libgcc -I../.././libgcc/. -I../.././libgcc/../gcc -I../.././libgcc/../include -I../.././libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_EMUTLS -o gthr-win32.o -MT gthr-win32.o -MD -MP -MF gthr-win32.dep -c ../.././libgcc/config/i386/gthr-win32.c -v -save-temps Reading specs from /tmp/gcc/host-i686-pc-cygwin/gcc/specs COLLECT_GCC=/tmp/gcc/host-i686-pc-cygwin/gcc/xgcc Target: i686-pc-cygwin Configured with: ./configure --config-cache --prefix=/usr --disable-win32-registry --enable-threads=win32 --enable-languages=c,c++,lto,fortran --with-win32-nlsapi=unicode --enable-tls --disable-bootstrap --enable-shared --disable-sjlj-exceptions --enable-gomp --enable-cloog-backend=isl LTLDFLAGS=-no-undefined lt_cv_deplibs_check_method=pass_all : (reconfigured) ./configure --config-cache --prefix=/usr --disable-win32-registry --enable-threads=win32 --enable-languages=c,c++,lto,fortran --with-win32-nlsapi=unicode --enable-tls --disable-bootstrap --enable-shared --disable-sjlj-exceptions --enable-gomp --enable-cloog-backend=isl LTLDFLAGS=-no-undefined lt_cv_deplibs_check_method=pass_all Thread model: win32 gcc version 4.9.0 20130414 (experimental) (GCC) COLLECT_GCC_OPTIONS='-B' '/tmp/gcc/host-i686-pc-cygwin/gcc/' '-B' '/usr/i686-pc-cygwin/bin/' '-B' '/usr/i686-pc-cygwin/lib/' '-isystem' '/usr/i686-pc-cygwin/include' '-isystem' '/usr/i686-pc-cygwin/sys-include' '-O2' '-O2' '-I' '../.././libgcc/../winsup/w32api/include' '-I' '../.././libgcc/../winsup/include' '-I' '../.././libgcc/../winsup/cygwin/include' '-D' 'IN_GCC' '-g' '-Wextra' '-Wall' '-Wno-narrowing' '-Wwrite-strings' '-Wcast-qual' '-Wstrict-prototypes' '-Wmissing-prototypes' '-Wold-style-definition' '-isystem' './include' '-g' '-g' '-D' 'IN_LIBGCC2' '-fbuilding-libgcc' '-fno-stack-protector' '-I' '.' '-I' '.' '-I' '../../host-i686-pc-cygwin/gcc' '-I' '../.././libgcc' '-I' '../.././libgcc/.' '-I' '../.././libgcc/../gcc' '-I' '../.././libgcc/../include' '-I' '../.././libgcc/config/libbid' '-D' 'ENABLE_DECIMAL_BID_FORMAT' '-D' 'HAVE_CC_TLS' '-D' 'USE_EMUTLS' '-o' 'gthr-win32.o' '-MT' 'gthr-win32.o' '-MD' '-MP' '-MF' 'gthr-win32.dep' '-c' '-v' '-save-temps' '-mtune=generic' '-march=pentiumpro' /tmp/gcc/host-i686-pc-cygwin/gcc/cc1.exe -E -quiet -v -I ../.././libgcc/../winsup/w32api/include -I ../.././libgcc/../winsup/include -I ../.././libgcc/../winsup/cygwin/include -I . -I . -I ../../host-i686-pc-cygwin/gcc -I ../.././libgcc -I ../.././libgcc/. -I ../.././libgcc/../gcc -I ../.././libgcc/../include -I ../.././libgcc/config/libbid -iprefix /tmp/gcc/host-i686-pc-cygwin/gcc/../lib/gcc/i686-pc-cygwin/4.9.0/ -isystem /tmp/gcc/host-i686-pc-cygwin/gcc/include -isystem /tmp/gcc/host-i686-pc-cygwin/gcc/include-fixed -MD gthr-win32.d -MF gthr-win32.dep -MP -MT gthr-win32.o -Dunix -idirafter /usr/lib/../include/w32api -idirafter /usr/i686-pc-cygwin/bin/../../include/w32api -D IN_GCC -D IN_LIBGCC2 -D ENABLE_DECIMAL_BID_FORMAT -D HAVE_CC_TLS -D USE_EMUTLS -isystem /usr/i686-pc-cygwin/include -isystem /usr/i686-pc-cygwin/sys-include -isystem ./include ../.././libgcc/config/i386/gthr-win32.c -mtune=generic -march=pentiumpro -Wextra -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -fbuilding-libgcc -fno-stack-protector -g -g -g -fworking-directory -O2 -O2 -fpch-preprocess -o gthr-win32.i ignoring nonexistent directory /usr/i686-pc-cygwin/include ignoring nonexistent directory /usr/i686-pc-cygwin/sys-include ignoring nonexistent directory ./include ignoring nonexistent directory /tmp/gcc/host-i686-pc-cygwin/gcc/../lib/gcc/i686-pc-cygwin/4.9.0/include ignoring nonexistent directory /tmp/gcc/host-i686-pc-cygwin/gcc/../lib/gcc/i686-pc-cygwin/4.9.0/include-fixed ignoring nonexistent directory /tmp/gcc/host-i686-pc-cygwin/gcc/../lib/gcc/i686-pc-cygwin/4.9.0/../../../../i686-pc-cygwin/include ignoring nonexistent directory /tmp/gcc/host-i686-pc-cygwin/gcc/../lib/gcc/../../lib/gcc/i686-pc-cygwin/4.9.0
[Bug target/56890] invalid fdtox instruction in 64-bit mode with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56890 --- Comment #7 from Rainer Jung rainer.jung at kippdata dot de 2013-04-14 09:05:54 UTC --- I can confirm, that the test cases behave unchanged with 4.7.3. There's no problem with 4.8.0.
[Bug rtl-optimization/56952] [4.9 regression] ICE in recog.c:2150
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56952 --- Comment #1 from gee jojelino at gmail dot com 2013-04-14 09:06:38 UTC --- Created attachment 29870 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29870 preprocessed source
[Bug rtl-optimization/56952] [4.9 regression] ICE in recog.c:2150
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56952 --- Comment #2 from gee jojelino at gmail dot com 2013-04-14 09:11:40 UTC --- $ gdb --args /tmp/gcc/host-i686-pc-cygwin/gcc/cc1.exe -fpreprocessed gthr-win32.i -quiet -dumpbase gthr-win32.c -mtune=generic -march=pentiumpro -auxbase-strip gthr-win32.o -g -g -g -O2 -O2 -Wextra -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version -fbuilding-libgcc -fno-stack-protector -o gthr-win32.s GNU gdb (GDB) 7.6.50.20130408-cvs (cygwin-special) Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i686-cygwin. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... warning: the current range check setting does not match the language. Whether backtraces should continue past the entry point of a program is off. Reading symbols from /tmp/gcc/host-i686-pc-cygwin/gcc/cc1.exe...r done. (gdb) r Starting program: /tmp/gcc/host-i686-pc-cygwin/gcc/cc1.exe -fpreprocessed gthr-win32.i -quiet -dumpbase gthr-win32.c -mtune=generic -march=pentiumpro -auxbase-strip gthr-win32.o -g -g -g -O2 -O2 -Wextra -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version -fbuilding-libgcc -fno-stack-protector -o gthr-win32.s [New Thread 12136.0x2900] [New Thread 12136.0x18d8] GNU C (GCC) version 4.9.0 20130414 (experimental) (i686-pc-cygwin) compiled by GNU C version 4.9.0 20130331 (experimental), GMP version 5.0.2, MPFR version 3.2.0-dev, MPC version 0.9 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C (GCC) version 4.9.0 20130414 (experimental) (i686-pc-cygwin) compiled by GNU C version 4.9.0 20130331 (experimental), GMP version 5.0.2, MPFR version 3.2.0-dev, MPC version 0.9 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 02065f7f4784d3d4fe06ce1367165da5 ../.././libgcc/config/i386/gthr-win32.c: In function ‘__gthr_win32_once’: ../.././libgcc/config/i386/gthr-win32.c:94:1: error: unrecognizable insn: } ^ (insn 52 51 53 12 (set (reg:SI 76) (symbol_ref:SI (Sleep@4) [flags 0x441] function_decl 0x7fa54300 Sleep)) ../.././libgcc/config/i386/gthr-win32.c:90 -1 (nil)) ../.././libgcc/config/i386/gthr-win32.c:94:1: internal compiler error: in extract_insn, at recog.c:2150 Program received signal SIGABRT, Aborted. 0x05e0da30 in ?? () (gdb) bt #0 0x05e0da30 in ?? () #1 0x7c821ca5 in WaitForSingleObject () from /cygdrive/c/WINDOWS/system32/kernel32.dll #2 0x610dd578 in sig_send (p=optimized out, si=..., tls=0x5e0a050) at /netrel/src/cygwin-snapshot-20130409-1/winsup/cygwin/sigproc.cc:682 #3 0x610da7e3 in _pinfo::kill (this=0x60fd, si=...) at /netrel/src/cygwin-snapshot-20130409-1/winsup/cygwin/signal.cc:248 #4 0x610dace8 in kill0 (si=..., pid=0x2f68) at /netrel/src/cygwin-snapshot-20130409-1/winsup/cygwin/signal.cc:299 #5 kill (pid=0x2f68, sig=0x6) at /netrel/src/cygwin-snapshot-20130409-1/winsup/cygwin/signal.cc:308 #6 0x610dae7c in raise (sig=0x6) at /netrel/src/cygwin-snapshot-20130409-1/winsup/cygwin/signal.cc:284 #7 0x610db0f3 in abort () at /netrel/src/cygwin-snapshot-20130409-1/winsup/cygwin/signal.cc:371 #8 0x00fa1994 in uw_init_context_1 (context=context@entry=0x5e0a470, outer_cfa=outer_cfa@entry=0x5e0a5d0, outer_ra=0xf7b23a backtrace_full+74) at ../.././libgcc/unwind-dw2.c:1502 #9 0x00fa2062 in _Unwind_Backtrace (trace=0xf7b170 unwind, trace_argument=0x5e0a5e8) at ../.././libgcc/unwind.inc:283 #10 0x00f7b23a in backtrace_full () #11 0x00f3245b in diagnostic_action_after_output ( context=0x15655a0 global_diagnostic_context, diagnostic=0x5e0a6c4) ---Type return to continue, or q return to quit--- at ../.././gcc/diagnostic.c:463 #12 0x00f332b6 in diagnostic_report_diagnostic ( context=0x15655a0 global_diagnostic_context, diagnostic=0x5e0a6c4) at ../.././gcc/diagnostic.c:791 #13 0x00f33a07 in internal_error ( gmsgid=0x127143f init_param_values(int*)::__FUNCTION__+1507 in %s, at %s:%d) at ../.././gcc/diagnostic.c:1123 #14 0x00f33af3 in fancy_abort ( file=0x10d3433 peephole2_1(rtx_def*, rtx_def*, int*)::__FUNCTION__+82 ../.././gcc/recog.c, line=0x866, function=0x10d39c7 extract_insn(rtx_def*)::__FUNCTION__ extract_insn) at ../.././gcc/diagnostic.c:1177 #15 0x00b317b1 in _fatal_insn ( msgid=0x112f97f cse_condition_code_reg()::__FUNCTION__+26 unrecognizable insn:, insn=0x7e7b5a50, file=0x10d3433 peephole2_1(rtx_def*, rtx_def*, int*)::__FUNCTION__+82 ../.././gcc/recog.c, line=0x866, function=0x10d39c7 extract_insn(rtx_def*)::__FUNCTION__ extract_insn) at ../.././gcc
[Bug rtl-optimization/56952] [4.9 regression] ICE in recog.c:2150
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56952 gee jojelino at gmail dot com changed: What|Removed |Added Severity|normal |blocker
[Bug target/56944] Better isfinite in some cases?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56944 --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org 2013-04-14 10:21:53 UTC --- Maybe in C terms: isnan(x) - x!=x isinf(x) - fabs(x)DBL_MAX isfinite(x) - fabs(x)=DBL_MAX what I am suggesting (with -fno-trapping-math, and maybe -Os) is: isfinite(x) - !isnan(x-x) but even without that, something like: isfinite(x) - x mask1 != mask1 (or ) where mask1 is +inf Since fabs(x) is implemented as x mask2, this saves one constant, and it has the nice advantage of forcing denormals to zero before the comparison, so the running time of the function is the same for denormals instead of being 100 times longer. Note that writing a C program that convinces gcc to generate exactly this code is very hard (even using intrinsics or inline asm, I basically have to write the whole function in asm).
[Bug c++/56953] New: [4.9]Inheriting constructors triggers instantiation of parameters at point of declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56953 Bug #: 56953 Summary: [4.9]Inheriting constructors triggers instantiation of parameters at point of declaration Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: lucdan...@free.fr Created attachment 29871 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29871 Testcase I am using: g++-snapshot (Debian 20130330-1) 4.9.0 20130330 (experimental) [trunk revision 197260] According to the diagnostic GCC gives, in some cases a using declaration that bring constructors into scope also triggers the instantiation of their parameters. The attachment is an example where a parameter takes the form `requires_completecompleted_later`, where specializations of `requires_complete` are only valid when the template argument is complete. When inheriting a constructor taking such a parameter, GCC complains about an ill-formed specialization and points to the using declaration as having triggered the instantiation. This is regardless of the program using that constructor or not. I believe the equivalent program which doesn't use inheriting constructors is correct, as the instantiation takes place at the point of use and not the point of declaration, where the argument `completed_later` is completed. At the very least it is accepted by GCC (changing the define at the top of the file controls that). Do note that if `requires_complete` is itself left incomplete and not defined until later in the program, then GCC accepts the program. Presumably those parameters that are not themselves complete are not instantiated. The same happens using a snapshot of pre-release 4.8.
[Bug bootstrap/56954] New: Bootstrap failure: ./auto-host.h:1994:16: error: declaration does not declare anything [-fpermissive]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56954 Bug #: 56954 Summary: Bootstrap failure: ./auto-host.h:1994:16: error: declaration does not declare anything [-fpermissive] Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: e1398...@rmqkr.net I am trying to bootstrap a cross compiler from an amd64 GNU/Linux host to x86_64-unknown-linux-gnu. First error: /tmp/build/./prev-gcc/xg++ -B/tmp/build/./prev-gcc/ -B/usr/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/tmp/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/tmp/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/tmp/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/tmp/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/tmp/src/libstdc++-v3/libsupc++ -L/tmp/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/tmp/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -c -g -O2 -gtoggle -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 -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/tmp/src/gcc -I/tmp/src/gcc/build -I/tmp/src/gcc/../include -I/tmp/src/gcc/../libcpp/include -I/tmp/src/gcc/../libdecnumber -I/tmp/src/gcc/../libdecnumber/bid -I../libdecnumber -I/tmp/src/gcc/../libbacktrace\ -o build/genchecksum.o /tmp/src/gcc/genchecksum.c In file included from ./bconfig.h:3:0, from /tmp/src/gcc/gengenrtl.c:21: ./auto-host.h:1994:16: error: declaration does not declare anything [-fpermissive] #define rlim_t long ^ /tmp/build/./prev-gcc/xg++ -v Using built-in specs. COLLECT_GCC=/tmp/build/./prev-gcc/xg++ Target: x86_64-unknown-linux-gnu Configured with: /tmp/src/configure --target=x86_64-unknown-linux-gnu --prefix=/usr --enable-languages=c,c++ --with-sysroot=/tmp/sysroot Thread model: posix gcc version 4.8.0 (GCC) make[3]: Entering directory `/tmp/build/gcc' TARGET_CPU_DEFAULT= \ HEADERS=auto-host.h ansidecl.h DEFINES= \ /bin/sh /tmp/src/gcc/mkconfig.sh config.h TARGET_CPU_DEFAULT= \ HEADERS=options.h insn-constants.h config/vxworks-dummy.h config/i386/biarch64.h config/i386/i386.h config/linux-android.h config/i386/unix.h config/i386/att.h config/dbxelf.h config/elfos.h config/gnu-user.h config/glibc-stdint.h config/i386/x86-64.h config/i386/gnu-user-common.h config/i386/gnu-user64.h config/linux.h config/i386/linux-common.h config/i386/linux64.h config/initfini-array.h defaults.h DEFINES=LIBC_GLIBC=1 LIBC_UCLIBC=2 LIBC_BIONIC=3 DEFAULT_LIBC=LIBC_GLIBC ANDROID_DEFAULT=0 \ /bin/sh /tmp/src/gcc/mkconfig.sh tm.h gawk -f /tmp/src/gcc/opt-gather.awk /tmp/src/gcc/ada/gcc-interface/lang.opt /tmp/src/gcc/fortran/lang.opt /tmp/src/gcc/go/lang.opt /tmp/src/gcc/java/lang.opt /tmp/src/gcc/lto/lang.opt /tmp/src/gcc/c-family/c.opt /tmp/src/gcc/common.opt /tmp/src/gcc/config/fused-madd.opt /tmp/src/gcc/config/i386/i386.opt /tmp/src/gcc/config/gnu-user.opt /tmp/src/gcc/config/linux.opt /tmp/src/gcc/config/linux-android.opt tmp-optionlist TARGET_CPU_DEFAULT= \ HEADERS=auto-host.h ansidecl.h DEFINES= \ /bin/sh /tmp/src/gcc/mkconfig.sh bconfig.h /tmp/build/./prev-gcc/xg++ -B/tmp/build/./prev-gcc/ -B/usr/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/tmp/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/tmp/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/tmp/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/tmp/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/tmp/src/libstdc++-v3/libsupc++ -L/tmp/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/tmp/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -c -g -O2 -gtoggle -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 -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/tmp/src/gcc -I/tmp/src/gcc/build -I/tmp/src/gcc/../include -I/tmp/src/gcc/../libcpp/include -I/tmp/src/gcc/../libdecnumber -I/tmp/src/gcc/../libdecnumber/bid -I../libdecnumber -I/tmp/src/gcc/../libbacktrace\ -DBASEVER=\4.8.0\ -DDATESTAMP=\\ \ -DREVISION=\\ \ -DDEVPHASE=\\ -DPKGVERSION=\(GCC) \ \ -DBUGURL=\http://gcc.gnu.org/bugs.html\ -o build/version.o /tmp/src/gcc/version.c /bin/sh /tmp/src/gcc/../move-if-change tmp-gi.list gtyp-input.list echo #define BUILDING_GCC_MAJOR `echo 4.8.0 | sed -e
[Bug c++/56895] [4.8/4.9 Regression] ICE: unexpected expression of kind arrow_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56895 --- Comment #16 from André Wöbbeking Woebbeking at web dot de 2013-04-14 14:15:47 UTC --- Thanks for your fast support!
[Bug other/56881] Miscompilation (optimisation failure?) causing NULL dereference and segfault at runtime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56881 --- Comment #9 from devspam at moreofthesa dot me.uk 2013-04-14 15:03:13 UTC --- Hmm, interesting… I'm taking your patch (crediting you) and paraphrasing where necessary to make a reasonable commit message of it. I'll also forward to other projects which I know use the same code.
[Bug debug/56950] compare-debug failure for gcc.dg/pr41345.c with fschedule-insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56950
--- Comment #2 from Steven Bosscher steven at gcc dot gnu.org 2013-04-14
15:09:20 UTC ---
I am testing this fix:
Index: haifa-sched.c
===
--- haifa-sched.c (revision 197942)
+++ haifa-sched.c (working copy)
@@ -7431,14 +7431,14 @@ sched_extend_bb (void)
/* The following is done to keep current_sched_info-next_tail non null. */
insn = BB_END (EXIT_BLOCK_PTR-prev_bb);
- if (NEXT_INSN (insn) == 0
+ if (next_nondebug_insn (insn) == 0
|| (!NOTE_P (insn)
!LABEL_P (insn)
/* Don't emit a NOTE if it would end up before a BARRIER. */
!BARRIER_P (NEXT_INSN (insn
{
rtx note = emit_note_after (NOTE_INSN_DELETED, insn);
- /* Make insn appear outside BB. */
+ /* Make note appear outside BB. */
set_block_for_insn (note, NULL);
BB_END (EXIT_BLOCK_PTR-prev_bb) = insn;
}
[Bug other/56881] Miscompilation (optimisation failure?) causing NULL dereference and segfault at runtime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56881 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #10 from Steven Bosscher steven at gcc dot gnu.org 2013-04-14 15:24:28 UTC --- Not a gcc bug.
[Bug target/56866] gcc 4.7.x/gcc-4.8.x with '-O3 -march=bdver2' misscompiles glibc-2.17/crypt/sha512.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56866 --- Comment #8 from Mikael Pettersson mikpe at it dot uu.se 2013-04-14 15:55:32 UTC --- OK, I can confirm that compiling glibc-2.17 with gcc-4.7.3 -O3 -march=bdver1 causes the sha512 test to fail, but without -march=bdver1 it doesn't fail. I also saw regressions in math/test-float.out, math/test-double.out, math/test-ifloat.out, math/test-idouble.out, nptl/tst-cond25.out, and rt/tst-cpuclock2.out.
[Bug other/36150] colorize output of gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36150 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #16 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-04-14 17:57:47 UTC --- GCC 4.9 will have colorized diagnostics, although probably disabled by default: http://gcc.gnu.org/gcc-4.9/changes.html
[Bug other/56955] New: documentation for attribute malloc contradicts itself
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56955 Bug #: 56955 Summary: documentation for attribute malloc contradicts itself Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: sunf...@google.com The GCC manual's definition of the malloc function attribute is: The malloc attribute is used to tell the compiler that a function may be treated as if any non-NULL pointer it returns cannot alias any other pointer valid when the function returns and that the memory has undefined content. This often improves optimization. Standard functions with this property include malloc and calloc. realloc-like functions do not have this property as the memory pointed to does not have undefined content. It says that the attribute implies that allocated memory has undefined content, but then it says that calloc has this property, despite the fact that memory allocated by calloc has well-defined content. Since calloc is already marked with this attribute in lots of places (including GLIBC), and since the undefined-content part of this attribute seems less important than the aliasing part for optimizers anyway, I suggest just removing the undefined-content language from the description of the attribute. Also, the last sentence says that realloc-like functions don't qualify since their memory does not have undefined content. The comment on GLIBC's declaration of realloc says that realloc doesn't qualify since the returned pointer may alias the argument pointer (for some definition of alias). GLIBC's comment seems more likely to be the real reason, and it doesn't rely on the undefined-content language.
[Bug other/56955] documentation for attribute malloc contradicts itself
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56955 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2013-04-14 19:05:00 UTC --- I think it is talking about the memory returned by malloc/calloc will not point to another memory location while realloc can.
[Bug target/56797] [4.8 Regression] internal compiler error: in extract_insn, at recog.c:2150
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56797 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.1 Summary|internal compiler error: in |[4.8 Regression] internal |extract_insn, at|compiler error: in |recog.c:2150|extract_insn, at ||recog.c:2150
[Bug c/56956] New: ftrapv traps on valid abs-like code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56956
Bug #: 56956
Summary: ftrapv traps on valid abs-like code
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sunf...@google.com
This program aborts when compiled with -ftrapv, despite not having any
overflow:
#include limits.h
#include inttypes.h
#include stdio.h
__attribute__((noinline))
uint64_t foo(uint64_t x) {
return x = INT64_MAX ? x : -x;
}
int main() {
uint64_t n = foo((uint64_t)INT64_MIN);
printf(% PRIx64 \n, n);
return 0;
}
It appears that the code in foo is being folded into an absolute-value
expression which does not work properly on INT64_MIN. However, the code as
written does handle INT64_MIN without any signed overflow.
[Bug target/56796] ‘TARGET_CYGWIN64’ was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56796 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Version|4.8.0 |4.9.0 Resolution||FIXED --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2013-04-14 19:24:32 UTC --- Fixed by: 2013-04-08 Kai Tietz kti...@redhat.com * config/i386/cygwin.h (EXTRA_OS_CPP_BUILTINS): Replaced TARGET_CYGWIN64 by TARGET_64BIT.
[Bug debug/56950] compare-debug failure for gcc.dg/pr41345.c with fschedule-insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56950 --- Comment #3 from Steven Bosscher steven at gcc dot gnu.org 2013-04-14 19:30:38 UTC --- (In reply to comment #2) I am testing this fix: Hmm, no that is not a fix...
[Bug rtl-optimization/56957] New: [4.9 regression] ICE in add_insn_after, at emit-rtl.c:3783
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56957 Bug #: 56957 Summary: [4.9 regression] ICE in add_insn_after, at emit-rtl.c:3783 Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: sch...@linux-m68k.org CC: ste...@gcc.gnu.org Target: ia64-*-* spawn /usr/local/gcc/gcc-20130414/Build/gcc/xgcc -B/usr/local/gcc/gcc-20130414/Build/gcc/ -fno-diagnostics-show-caret -O3 -fomit-frame-pointer -funroll-loops -w -c -o 20070603-2.o /usr/local/gcc/gcc-20130414/gcc/testsuite/gcc.c-torture/compile/20070603-2.c /usr/local/gcc/gcc-20130414/gcc/testsuite/gcc.c-torture/compile/20070603-2.c: In function 'f': /usr/local/gcc/gcc-20130414/gcc/testsuite/gcc.c-torture/compile/20070603-2.c:9:1: internal compiler error: in add_insn_after, at emit-rtl.c:3783 0x4046b74f add_insn_after(rtx_def*, rtx_def*, basic_block_def*) ../../gcc/emit-rtl.c:3783 0x408c536f sel_gen_insn_from_expr_after(_expr*, vinsn_def*, int, rtx_def*) ../../gcc/sel-sched-ir.c:1401 0x408d3b6f emit_insn_from_expr_after ../../gcc/sel-sched.c:4520 0x408e5a3f schedule_expr_on_boundary ../../gcc/sel-sched.c:5523 0x408e9d9f fill_insns ../../gcc/sel-sched.c:5646 0x408e9d9f schedule_on_fences ../../gcc/sel-sched.c:7411 0x408e9d9f sel_sched_region_2 ../../gcc/sel-sched.c:7545 0x408f19ef sel_sched_region_1 ../../gcc/sel-sched.c:7658 0x408f19ef sel_sched_region(int) ../../gcc/sel-sched.c:7685 0x408f34af run_selective_scheduling() ../../gcc/sel-sched.c:7761 0x40dadaaf ia64_reorg ../../gcc/config/ia64/ia64.c:9728 0x40878f0f rest_of_handle_machine_reorg ../../gcc/reorg.c:3904 Caused by r197942.
[Bug other/56955] documentation for attribute malloc contradicts itself
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56955 --- Comment #2 from Dan Gohman sunfish at google dot com 2013-04-14 19:47:42 UTC --- (In reply to comment #1) I think it is talking about the memory returned by malloc/calloc will not point to another memory location while realloc can. I agree that's essentially what it ought to talk about, and the bug is that it's talking about something else -- the contents of the pointed-to memory.
[Bug c++/56958] New: Spurious unused variable warning in empty pack expansion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56958
Bug #: 56958
Summary: Spurious unused variable warning in empty pack
expansion
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lucdan...@free.fr
Created attachment 29872
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29872
Minimal testcase
Using:
g++-snapshot (Debian 20130330-1) 4.9.0 20130330 (experimental) [trunk revision
197260]
$ cat main.cpp
templatetypename... T
int foo(T... t)
{
int spurious = 0;
return false ? foo(t + spurious...) : 0;
}
int main()
{
return foo();
}
$ g++-snapshot -Wall -std=c++11 main.cpp
main.cpp: In instantiation of 'int foo(T ...) [with T = {}]':
main.cpp:10:16: required from here
main.cpp:4:9: warning: variable 'spurious' set but not used
[-Wunused-but-set-variable]
int spurious = 0;
^
No such warning is produced when passing arguments to foo.
[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383 --- Comment #11 from Sean Santos quantheory at gmail dot com 2013-04-14 20:08:59 UTC --- I'm doing a bit of research because I'm considering trying to tackle part of this soon. I believe that the Fortran standard does not require the rounding mode to apply to operations performed during constant folding, so point 4 above is moot. Please see the collected interpretations of F2003: http://j3-fortran.org/doc/standing/links/016.txt Particularly see F03/0040 and F03/0078. In combination they guarantee that the compiler is allowed to transform expressions at compile time according to the mathematical equivalence rule regardless of the rounding mode. In any case, the rounding mode cannot always be established at compile time; if the committee had not decided upon this behavior, then constant folding would often be impossible, period. The Fortran 2003 and 2008 standards also give examples where constant folding and propagation are allowed to influence whether or not an IEEE exception is signaled.
[Bug c++/56959] New: unable to find string literal operator ‘operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56959 Bug #: 56959 Summary: unable to find string literal operator ‘operator Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: daffra.clau...@gmail.com claudio@ubuntu64:~/chtulu linux$ gcc --version gcc (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2 #define strCopyRight chtulu\ \nprogramming language\ \n[2013] LGPL (2) : daffra.clau...@gmail.com const char *s = \n\ strCopyRight\ \n\nUsage :\n\ \nstrProjectName : input file \ \n\noptions\n\ \nhelp file: -h \ \ninput file : -i input file name\ \noutput file : -o output file name\ \n; main.c: In function ‘void HelpFile()’: main.c:34:2: error: unable to find string literal operator ‘operator strProjectName’ -rwxrwxr-x 1 claudio claudio 28532 apr 14 22:47 ch\r claudio@ubuntu64:~/chtulu linux$ this piece of code (up) compile with error , as you see this ohter (down) piece of code compile without error : i must separate strProjectName with space before and after n.b. same version of gcc in windows tdm64-gcc-4.7.1-3 work good const char *s = \n\ strCopyRight\ \n\nUsage :\n\ \n strProjectName : input file \ \n\noptions\n\ \nhelp file: -h \ \ninput file : -i input file name\ \noutput file : -o output file name\ \n;
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 Sean Santos quantheory at gmail dot com changed: What|Removed |Added CC||quantheory at gmail dot com --- Comment #16 from Sean Santos quantheory at gmail dot com 2013-04-14 21:28:27 UTC --- Regarding the above comment: You need to have IEEE_EXCEPTIONS or IEEE_ARITHMETIC loaded *in the scoping unit*, if you want to use IEEE 754 features. Well, yes and no. There are three cases: 1) If you don't access those modules in a particular scope, it is processor-dependent (e.g. up to the compiler) whether IEEE features are supported. They can be on or off all the time, or there can be a compiler option. 2) If you do access those modules, it is *still* processor-dependent whether IEEE features are supported, so that doesn't change. However, this does change: i) The compiler is allowed to change the level of IEEE support. It is explicitly allowed to change the degree of support for exceptions. I don't think that the committee actually intended for support of IEEE NaN and Inf to change based on whether or not IEEE_ARITHMETIC is in scope, but technically the standard seems to allow it. ii) If IEEE_ARITHMETIC is provided, the compiler is required to provide the IEEE_SUPPORT_* functions so that the program can query them. (However, it is not supposed to enforce their use at compile time.) 3) If you access IEEE_ARITHMETIC and use IEEE_NAN and IEEE_INF from IEEE_FEATURES, the compiler is required to do one of only three things: i) Error at compile time because it doesn't have one or both modules. ii) Error at compile time because it has IEEE_FEATURES, but the module doesn't contain IEEE_NAN/IEEE_INF. iii) Enable support of IEEE_NAN and IEEE_INF in the scope. TLDR: If the compiler declares that it doesn't actually have any IEEE support (which it implicitly does by not providing these modules), it can do anything it wants. If IEEE_FEATURES was provided, that should probably be used to turn on IEEE features that are turned off by default because they are inefficient, not IEEE_ARITHMETIC. If an IEEE feature isn't a significant performance hit, it may as well be on all the time.
[Bug ada/56909] [4.8 regression] s-atopri.adb:multiple undefined references on mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56909 --- Comment #10 from Arthur Zhang mail2arthur at gmail dot com 2013-04-14 22:09:34 UTC --- (In reply to comment #9) On MinGW, GCC 4.7.x Ada built successfully with default (no -with-arch or -with-tune) configure. GCC 4.8.0 s-atopri.* changes breaks same configure: 1. with default (no -with-arch or -with-tune): failed with five undefined reference (as the top of this ticket) OK, I missed that, then configure with --build=i686-pc-mingw32. Thanks for the suggestion, it built successfully too. However, since MinGW build has --enable-version-specific-runtime-libs, the old v4.7.2 has lib installed to \MinGW\lib\gcc\mingw32\4.7.2 (as --build=mingw32) but now new v4.8.0 build will install lib to ...\gcc\i686-pc-mingw32\4.8.0. For sure we can use post-install script to move it back from i686-pc-mingw32 dir to mingw32 dir. Is there any gcc configure switch I can set to do that too?
[Bug c++/56959] unable to find string literal operator ‘operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56959 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2013-04-14 22:15:59 UTC --- Are you using -std=c++11 or -std=gnu++11 or -std=c++0x or -std=gnu++-0x ? If this is the correct behavior as the strCopyRight in this case is the custom operator.
[Bug c++/56959] unable to find string literal operator ‘operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56959 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID Severity|major |normal --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2013-04-14 22:42:25 UTC --- See the section on User-defined literals and whitespace at http://gcc.gnu.org/gcc-4.7/porting_to.html
[Bug c++/56959] unable to find string literal operator ‘operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56959 --- Comment #3 from claudio daffra daffra.claudio at gmail dot com 2013-04-14 22:43:34 UTC --- no bug, std=c++11
[Bug c++/56959] unable to find string literal operator ‘operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56959 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2013-04-14 22:48:00 UTC --- Also, the backslashes are a complete waste of time, you can just write: const char *s = \n strCopyRight \n\nUsage :\n \nstrProjectName : input file \n\noptions\n \nhelp file: -h \ninput file : -i input file name \noutput file : -o output file name \n;
[Bug ada/56909] [4.8 regression] s-atopri.adb:multiple undefined references on mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56909 --- Comment #11 from Arthur Zhang mail2arthur at gmail dot com 2013-04-14 23:12:48 UTC --- Will '--exec-prefix=mingw32' work?
[Bug middle-end/56916] ICE when building libgfortran for arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56916 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2013-04-14 23:54:11 UTC --- Dup of bug 56921 really. *** This bug has been marked as a duplicate of bug 56921 ***
[Bug rtl-optimization/56921] [4.9 Regression] ICE in rtx_cost called by doloop_optimize_loops for PPC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56921 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #10 from Andrew Pinski pinskia at gcc dot gnu.org 2013-04-14 23:54:11 UTC --- *** Bug 56916 has been marked as a duplicate of this bug. ***
[Bug c/56956] ftrapv traps on valid abs-like code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56956 Chung-Ju Wu jasonwucj at gmail dot com changed: What|Removed |Added CC||jasonwucj at gmail dot com --- Comment #1 from Chung-Ju Wu jasonwucj at gmail dot com 2013-04-15 00:58:14 UTC --- I think 'x' can not present negative value.
[Bug c/56956] ftrapv traps on valid abs-like code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56956 --- Comment #2 from Dan Gohman sunfish at google dot com 2013-04-15 03:53:10 UTC --- (In reply to comment #1) I think 'x' can not present negative value. The unary minus operator is defined for unsigned types. It doesn't produce signed overflow.
[Bug c/56956] ftrapv traps on valid abs-like code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56956 --- Comment #3 from Dan Gohman sunfish at google dot com 2013-04-15 03:54:32 UTC --- Pulling the unary minus out into a separate statement, like this: uint64_t y = -x; return x = INT64_MAX ? x : -y; causes the program to execute correctly.
[Bug c/56956] ftrapv traps on valid abs-like code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56956 --- Comment #4 from Chung-Ju Wu jasonwucj at gmail dot com 2013-04-15 04:18:13 UTC --- (In reply to comment #2) (In reply to comment #1) I think 'x' can not present negative value. The unary minus operator is defined for unsigned types. It doesn't produce signed overflow. According to C99 6.5.3.3 Point 3 and C99 6.5 Point 5: The result of the unary '-' operator is the negative of its operand. ... if the result is ... not in the range of representable values for its type... the behavior is undefined. So my understanding is that the evaluation expression '-x' is not a representable value of 'uint64_t', which is undefined behavior, resulting abort if -ftrav is issued. Perhaps my understanding is incorrect? :(
[Bug c/56956] ftrapv traps on valid abs-like code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56956 --- Comment #5 from Dan Gohman sunfish at google dot com 2013-04-15 05:12:30 UTC --- (In reply to comment #4) (In reply to comment #2) (In reply to comment #1) I think 'x' can not present negative value. The unary minus operator is defined for unsigned types. It doesn't produce signed overflow. According to C99 6.5.3.3 Point 3 and C99 6.5 Point 5: The result of the unary '-' operator is the negative of its operand. ... if the result is ... not in the range of representable values for its type... the behavior is undefined. So my understanding is that the evaluation expression '-x' is not a representable value of 'uint64_t', which is undefined behavior, resulting abort if -ftrav is issued. Perhaps my understanding is incorrect? :( Yes; unsigned types are an exception to the rule: C99 6.2.5p9 says A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting type. The wording is a little vague, but it means that negative results are converted to unsigned values by conceptually adding the maximum unsigned value plus one until the value is in range.
[Bug c/56956] ftrapv traps on valid abs-like code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56956 --- Comment #6 from Dan Gohman sunfish at google dot com 2013-04-15 05:14:27 UTC --- (In reply to comment #3) Pulling the unary minus out into a separate statement, like this: uint64_t y = -x; return x = INT64_MAX ? x : -y; causes the program to execute correctly. Actually, I meant to write this: uint64_t y = -x; return x = INT64_MAX ? x : y; and it still executes correctly, with no trap.
[Bug c/56960] New: How to set up stack pointer in gcc 4.7.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56960
Bug #: 56960
Summary: How to set up stack pointer in gcc 4.7.2
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: deepak.ka...@gmail.com
void
spim_prologue(void)
{
int i,j;
emit_move_insn(gen_rtx_MEM(SImode,plus_constant(stack_pointer_rtx,-0)),return_addr_rtx);
emit_move_insn(gen_rtx_MEM(SImode,plus_constant(stack_pointer_rtx,-4)),stack_pointer_rtx);
emit_move_insn(gen_rtx_MEM(SImode,plus_constant(stack_pointer_rtx,-8)),hard_frame_pointer_rtx);
emit_move_insn(hard_frame_pointer_rtx,
plus_constant(stack_pointer_rtx,0));
for(i=0,j=4;iFIRST_PSEUDO_REGISTER;i++)
{
if(df_regs_ever_live_p(i) !call_used_regs[i]
!fixed_regs[i])
{
emit_move_insn(gen_rtx_MEM(SImode,plus_constant(hard_frame_pointer_rtx,-4*j)),
gen_rtx_REG(SImode,i));
j++;
}
}
emit_insn(gen_rtx_SET(SImode,
stack_pointer_rtx,plus_constant(hard_frame_pointer_rtx,-((3+j+1)*4+get_frame_size()))
)); //HERE is what error comes
}
The last statement of the program is producing a segmentation fault when I
compile a program. It worked fine when it was built on gcc-4.6.2 but creating
problem for 4.7.2. Can anyone help me out?
