[Bug rtl-optimization/55160] [4.8 Regression] Counterproductive loop induction variable optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55160 --- Comment #1 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org 2012-11-01 06:28:14 UTC --- Author: amylaar Date: Thu Nov 1 06:28:06 2012 New Revision: 193060 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193060 Log: PR target/55160 * config/sh/sh.md (doloop_end): Use emit_jump_insn. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.md
[Bug target/55160] [4.8 Regression] Counterproductive loop induction variable optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55160
Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org changed:
What|Removed |Added
Target|sh*-*-* arm*-*-*|sh*-*-*
Status|UNCONFIRMED |RESOLVED
Resolution||FIXED
--- Comment #2 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org
2012-11-01 07:09:25 UTC ---
(In reply to comment #0)
Starting with rev 192505 the following
int test_04 (int* x, int c)
{
int s = 0;
for (int i = 0; i c; ++i)
s += *--x;
return s;
}
..
In this case the inner loop code size effectively does not increase, but there
is overhead in setting up the loop. Similar code is also generated on ARM.
In order to get the r192504 arm port to generate a doloop_end pattern,
I have to enable thubm2 support and modulo scheduling, e.g.:
-O2 --std=c99 -mthumb -march=armv7 -fmodulo-sched
with these options, r192505 also gets the doloop_end pattern.
Therefore, I have removed arm from the target list.
[Bug c++/25466] typeid expression fails to throw bad_typeid according to 5.2.8p2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25466 --- Comment #8 from Daniel Krügler daniel.kruegler at googlemail dot com 2012-11-01 07:11:56 UTC --- (In reply to comment #7) The error is real. The original example belongs to 5.2.8 p2: When typeid is applied to a **glvalue expression** whose type is a polymorphic class type [..] which is the rule requiring dynamic evaluation of the expression. Your counter example is an expression that is an rvalue expression, which belongs to p3: When typeid is applied to an expression other than a glvalue of a polymorphic class type, the result refers to a std::type_info object representing the static type of the expression. [..] The expression is an unevaluated operand (Clause 5).
[Bug lto/53746] [lto] segfault in std::vector::__base_ctor (with -fipa-pta)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53746 vincenzo Innocente vincenzo.innocente at cern dot ch changed: What|Removed |Added Known to work||4.8.0 Known to fail||4.7.2 --- Comment #5 from vincenzo Innocente vincenzo.innocente at cern dot ch 2012-11-01 07:17:01 UTC --- the problem still persist in 4.7.2 does not happen in 4.8 20121028 (experimental) [trunk revision 192889] (too many things have changed though)
[Bug rtl-optimization/55161] New: internal compiler error: in schedule_reg_moves, at modulo-sched.c:731
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55161
Bug #: 55161
Summary: internal compiler error: in schedule_reg_moves, at
modulo-sched.c:731
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amyl...@gcc.gnu.org
CC: cr...@gcc.gnu.org, olege...@gcc.gnu.org
Target: arm-*-*
int test_04 (int* x, int c)
{
int s = 0;
for (int i = 0; i c; ++i)
s += *--x;
return s;
}
compiled with:
./cc1 -O2 t.c --std=c99 -mthumb -march=armv7 -fmodulo-sched
worked in r192505.
In r193060, we get:
t.c:7:1: internal compiler error: in schedule_reg_moves, at modulo-sched.c:731
[Bug c++/54431] [C++11] g++ crashes when compiling the following file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54431 Markus Trippelsdorf markus at trippelsdorf dot de changed: What|Removed |Added CC||markus at trippelsdorf dot ||de --- Comment #5 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-11-01 07:46:30 UTC --- unhandled expression in get_expr_operands(): field_decl 0x59f6a18 __this type pointer_type 0x5a01a80 type record_type 0x5a017e0 A sizes-gimplified type_5 type_6 QI size integer_cst 0x58acf80 constant 8 unit size integer_cst 0x58acfa0 constant 1 align 8 symtab 0 alias set -1 canonical type 0x5a017e0 fields type_decl 0x5a03450 A context translation_unit_decl 0x58c5170 D.1 full-name struct Aint X() X(constX) this=(X) n_parents=0 use_template=1 interface-unknown pointer_to_this pointer_type 0x5a01930 chain type_decl 0x5a032e0 A readonly sizes-gimplified unsigned DI size integer_cst 0x58acdc0 constant 64 unit size integer_cst 0x58acde0 constant 8 align 64 symtab 0 alias set -1 canonical type 0x5a01a80 readonly used unsigned nonlocal decl_7 DI file test.ii line 6 col 6 size integer_cst 0x58acdc0 64 unit size integer_cst 0x58acde0 8 align 64 offset_align 128 offset integer_cst 0x58ace00 type integer_type 0x58c7000 sizetype constant 0 bit offset integer_cst 0x58ace80 type integer_type 0x58c70a8 bitsizetype constant 0 context record_type 0x5a01dc8 __lambda0 chain type_decl 0x5a037e8 __lambda0
[Bug target/54996] gcc with --target=avr fails to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54996 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #4 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-11-01 08:26:21 UTC --- Don't configure GCC in the source tree. Read the online documentation on configuring GCC again. If you configured in the GCC sources, remove the sources and retrieve them again to be sure they are not messed up by the configure in the source tree. You must have a working avr-binutils in the path. Alternatively, you can build and install avr binutils with the same --prefix before configuring avr-gcc. You don't need to add it to the path in the latter case. You need binutils 2.23 or higher for avr-gcc 4.7, see the GCC 4.7 release notes.
[Bug c++/25466] typeid expression fails to throw bad_typeid according to 5.2.8p2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25466 --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-01 08:39:48 UTC --- Oops, sorry about the rvalue stupid mistake, you are right. Thus I understand that this type of wording means that assuming it's a glvalue, the null pointer can appear anywhere, I see. Currentlg we are handling only the examples in the note.
[Bug middle-end/55142] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55142 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot |gnu.org |gnu.org --- Comment #11 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-11-01 08:44:27 UTC --- Investigating.
[Bug c++/25466] typeid expression fails to throw bad_typeid according to 5.2.8p2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25466 --- Comment #10 from Daniel Krügler daniel.kruegler at googlemail dot com 2012-11-01 09:10:56 UTC --- (In reply to comment #9) I don't think that the standard says (or intends to say) that an implementation has to defer all evaluations here. For example, assume you provide polymorphic operator+(polymorphic a, polymorphic b); with some definition this is still UB when the expression *(T*)0 + *(T*)0 occurs as operand of typeid (Note the arguments are by value). An implementation is only required to detect whether an (immediate) runtime glvalue of a polymorphic class as argument of typeid refers to an empty glvalue. Anything beyond that would fall under http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#232 I think.
[Bug target/55147] [4.8 Regression] x86: wrong code for 64-bit load
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55147 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.8.0 Summary|x86: wrong code for 64-bit |[4.8 Regression] x86: wrong |load|code for 64-bit load --- Comment #4 from Uros Bizjak ubizjak at gmail dot com 2012-11-01 09:27:21 UTC --- (In reply to comment #3) it creates the same number of insns/same quality (just slightly different RA decisions/scheduling) for f1-f3, but for f4 without bswapdi2 it creates slightly worse code (with bswapdi2 f4 needs just one call saved register, without it two, supposedly because both bswap insns are scheduled together. We can live with that. I have also checked that removing the pattern doesn't degrade TARGET_MOVBE, the reason for their existence is PR53227. Also, a regression from 4.7.
[Bug target/55147] [4.8 Regression] x86: wrong code for 64-bit load
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55147
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-01
09:44:22 UTC ---
Created attachment 28589
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28589
gcc48-pr55147.patch
So like this? Or do you want to merge the bswap{si,di}2 expanders using SWI48
iterator too? That would make i386.md tiny bit shorter, but would make
gen_bswapdi2 longer (as the compiler can't figure out that for DImode (thus
TARGET_64BIT) TARGET_BSWAP is always true). Perhaps I could do
else if (MODEmode == DImode || TARGET_BSWAP)
so that at least optimized gcc builds would optimize it away.
[Bug target/55147] [4.8 Regression] x86: wrong code for 64-bit load
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55147
--- Comment #6 from Uros Bizjak ubizjak at gmail dot com 2012-11-01 09:48:50
UTC ---
(In reply to comment #5)
Created attachment 28589 [details]
gcc48-pr55147.patch
So like this? Or do you want to merge the bswap{si,di}2 expanders using SWI48
iterator too? That would make i386.md tiny bit shorter, but would make
gen_bswapdi2 longer (as the compiler can't figure out that for DImode (thus
TARGET_64BIT) TARGET_BSWAP is always true). Perhaps I could do
else if (MODEmode == DImode || TARGET_BSWAP)
so that at least optimized gcc builds would optimize it away.
No, your proposed patch is OK and pre-approved for mainline SVN.
[Bug tree-optimization/55162] New: Loop ivopts cuts off top bits of loop counter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55162
Bug #: 55162
Summary: Loop ivopts cuts off top bits of loop counter
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: olege...@gcc.gnu.org
Target: sh*-*-*
The following function:
int test (int* x, unsigned int c)
{
int s = 0;
unsigned int i;
for (i = 0; i c; ++i)
s += x[i];
return s;
}
compiled for SH (-O2 -m4 -ml) results in the following code:
tst r5,r5 // c == 0 ?
bt/s.L6
mov #0,r0
shll2 r5 // c = 2
add #-4,r5 // c += -4
shlr2 r5 // c = 2 (unsigned shift)
add #1,r5 // c += 1
.L3:
mov.l @r4+,r1
dt r5
bf/s.L3
add r1,r0
.L6:
rts
nop
If the function above is invoked with c = 0x8000 the loop will do
0x4000 number of iterations, which looks suspicious.
For example, passing a virtual address 0x1000 and c = 0x8000 to the
function should actually run over the address range 0x1000 .. 0x80001000,
not 0x1000 .. 0x40001000.
I've also checked this on ARM. There, the loop counter is transformed into the
end address and the loop compares the addresses instead of using a
decrement-and-test insn:
cmp r1, #0
beq .L4
mov r3, r0
add r1, r0, r1, asl #2
mov r0, #0
.L3:
ldr r2, [r3], #4
cmp r3, r1
add r0, r0, r2
bne .L3
bx lr
.L4:
mov r0, r1
bx lr
The same could be done on SH, too (comparing against the end address instead of
using a loop counter), but it would add a loop setup overhead. In the optimal
case the above function would result in the following SH code:
tst r5,r5
bt/s.L6
mov #0,r0
.L3:
mov.l @r4+,r1
dt r5
bf/s.L3
add r1,r0
.L6:
rts
nop
This problem is present on rev 193061 as well as on the 4.7 branch.
[Bug target/55145] [4.8 Regression] [x32] -maddress-mode=long miscompiles glibc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55145 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-11-01 Ever Confirmed|0 |1 --- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2012-11-01 10:08:50 UTC --- So is this PR a manifestation of presumably wrong fix for PR 55142 or an independent bug?
[Bug tree-optimization/55162] Loop ivopts cuts off top bits of loop counter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55162
--- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org 2012-11-01 10:11:46
UTC ---
(In reply to comment #0)
The same could be done on SH, too (comparing against the end address instead
of
using a loop counter), but it would add a loop setup overhead. In the optimal
case the above function would result in the following SH code:
tst r5,r5
bt/s.L6
mov #0,r0
.L3:
mov.l @r4+,r1
dt r5
bf/s.L3
add r1,r0
.L6:
rts
nop
... which is the case if '*x++' is used instead of 'x[i]':
int test (int* x, unsigned int c)
{
int s = 0;
unsigned int i;
for (i = 0; i c; ++i)
s += *x++;
return s;
}
[Bug bootstrap/54834] bootstrap fails when building libbacktrace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54834 Nicolai Josuttis nico at josuttis dot de changed: What|Removed |Added CC||nico at josuttis dot de --- Comment #7 from Nicolai Josuttis nico at josuttis dot de 2012-11-01 10:14:30 UTC --- I got the same problem when switching from revision 1191942 (Oct 1st, 2012) to revision 193061 (Nov 1st, 2012). The effect was that the following files existed in the build tree: -rw-r--r-- 1 nico None 10659 Sep 21 10:16 gcc/include/unwind.h lrwxrwxrwx 1 nico None36 Oct 2 00:04 i686-pc-cygwin/libgcc/unwind.h - ../../../src/libgcc/unwind-generic.h After removing gcc/include/unwind.h the problem disappeared. As you can see, my environment was: CygWin under Windows 7 x64 (i686-pc-cygwin) Config settings were: ../src/configure \ --enable-languages=c++ \ --disable-bootstrap \ --prefix=/cygdrive/p/gcc/gcc$VERSION \ --program-suffix=$VERSION \ --with-gxx-include-dir=/cygdrive/p/gcc/gcc$VERSION-include \ --disable-lto \ --disable-sjlj-exceptions \ 21 | tee -a ../make.log
[Bug rtl-optimization/55154] [4.8 Regression] ICE: in curr_insn_transform, at lra-constraints.c:2702 with custom flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55154 --- Comment #2 from Uros Bizjak ubizjak at gmail dot com 2012-11-01 10:40:37 UTC --- (In reply to comment #1) Started with http://gcc.gnu.org/viewcvs?view=revisionrevision=192719 The interesting thing is that this happened before, definitely in r190614, afterwards was fixed in some commit, and 190777 was fine. As the test name implies, it was PR46254. The problem there was that %rbx is declared as fixed reg for -fpic -mcmodel=large case. Fixed regs are unavailable to RA, so we have to handle it in a special way. This PR shows a deficiency in how subregs are handled in LRA. The test lives and dies by correct subreg handling in the RA. For reference, pre-LRA allocator resolved allocation for problematic insn with: Reloads for insn # 10 Reload 0: reload_in (DI) = (subreg:DI (reg:TI 60 [ i.1 ]) 0) reload_out (DI) = (reg:DI 4 si) AREG, RELOAD_OTHER (opnum = 0) reload_in_reg: (subreg:DI (reg:TI 60 [ i.1 ]) 0) reload_out_reg: (subreg:DI (reg:TI 4 si [65]) 0) reload_reg_rtx: (reg:DI 0 ax) Reload 1: reload_in (DI) = (subreg:DI (reg:TI 60 [ i.1 ]) 8) reload_out (DI) = (reg:DI 5 di) DREG, RELOAD_OTHER (opnum = 1) reload_in_reg: (subreg:DI (reg:TI 60 [ i.1 ]) 8) reload_out_reg: (subreg:DI (reg:TI 4 si [65]) 8) reload_reg_rtx: (reg:DI 1 dx) Reload 2: reload_in (DI) = (subreg:DI (reg:TI 60 [ i.1 ]) 0) reload_out (DI) = (scratch:DI) GENERAL_REGS, RELOAD_OTHER (opnum = 5) reload_in_reg: (subreg:DI (reg:TI 60 [ i.1 ]) 0) reload_out_reg: (scratch:DI) reload_reg_rtx: (reg:DI 38 r9) Reload 3: reload_in (DI) = (subreg:DI (reg:TI 60 [ i.1 ]) 8) CREG, RELOAD_FOR_INPUT (opnum = 6) reload_in_reg: (subreg:DI (reg:TI 60 [ i.1 ]) 8) reload_reg_rtx: (reg:DI 2 cx)
[Bug rtl-optimization/55154] [4.8 Regression] ICE: in curr_insn_transform, at lra-constraints.c:2702 with custom flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55154 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.8.0 --- Comment #3 from Uros Bizjak ubizjak at gmail dot com 2012-11-01 10:42:33 UTC --- Confirmed, a regression from 4.7.
[Bug middle-end/55132] [4.8 Regression] FAIL: g++.dg/tree-ssa/pr45453.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55132 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org 2012-11-01 10:55:27 UTC --- Fixed now.
[Bug c++/55159] pythy constexpr auto lambda pointer has no initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55159
Daniel Krügler daniel.kruegler at googlemail dot com changed:
What|Removed |Added
CC||daniel.kruegler at
||googlemail dot com
--- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com
2012-11-01 10:58:06 UTC ---
I really think that Pythy should fix this implementation, because it is not
supported by the C++11 standard. Any compiler accepting that is defect.
According to 9.4.2 p3:
A static data member of literal type can be declared in the class definition
with the constexpr specifier; if so, its declaration shall specify a
brace-or-equal-initializer in which every initializer-clause that is an
assignment-expression is a constant expression.
As of 5.19 p2 the appearance of a lambda-expression prevents an expression from
satisfying the requirements of a (core) constant expression.
But changing your example to
template typename T
T* addr(T t) { return t; }
bool less(int x, int y) { return x y ? x : y; }
const static auto* f = addr(less);
indeed points to a defect of gcc, not being able to deduce auto here. I think
this is the same bug that I can remember (but cannot find at the very moment)
which shows a similar problem during overload resolution in templates when
involving function addresses such as in
template typename T
T* addr(T t) { return t; }
bool less(int x, int y) { return x y ? x : y; }
templatetypename T
int deduce(const T*) { return 0; }
int i = deduce(addr(less));
This example should be accepted, but gcc doesn't like it saying:
error: no matching function for call to 'deduce(bool (*)(int, int))'|
note: candidate is:|
note: templateclass T int deduce(const T*)|
note: template argument deduction/substitution failed:|
note: types 'const T' and 'bool(int, int)' have incompatible cv-qualifiers
[Bug bootstrap/55163] New: Ongoing problem with gengtype-lex.c under CygWin with CRLF text mode line endings since 4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55163
Bug #: 55163
Summary: Ongoing problem with gengtype-lex.c under CygWin with
CRLF text mode line endings since 4.8
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: n...@josuttis.de
For all versions of 4.8.0 I tried to compile, I run into the same problem
when building a C++ compiler in my CygWin environment.
The error is as follows:
flex -ogengtype-lex.c ../../src/gcc/gengtype-lex.l { \
echo '#include bconfig.h' gengtype-lex.c.tmp; \
cat gengtype-lex.c gengtype-lex.c.tmp; \
mv gengtype-lex.c.tmp gengtype-lex.c; \
}
g++ -c -g -O2 -DIN_GCC-fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual
-Wmissing-format-attribute -fno-common -Wno-error -DHAVE_CONFIG_H
-DGENERATOR_FILE -I. -Ibuild -I../../src/gcc -I../../src/gcc/build
-I../../src/gcc/../include -I../../src/gcc/../libcpp/include
-I/cygdrive/p/gcc/gcc-trunk-install/build/./gmp
-I/cygdrive/p/gcc/gcc-trunk-install/src/gmp
-I/cygdrive/p/gcc/gcc-trunk-install/build/./mpfr
-I/cygdrive/p/gcc/gcc-trunk-install/src/mpfr
-I/cygdrive/p/gcc/gcc-trunk-install/src/mpc/src
-I../../src/gcc/../libdecnumber -I../../src/gcc/../libdecnumber/bid
-I../libdecnumber -I../../src/gcc/../libbacktrace \
-o build/gengtype-lex.o gengtype-lex.c
gengtype-lex.c:332: error: expected unqualified-id before do
gengtype-lex.c:332: error: expected `,' or `;' before do
gengtype-lex.c:352: error: expected unqualified-id before while
gengtype-lex.c:352: error: expected `,' or `;' before while
gengtype-lex.c:394: error: `yy_size_t' does not name a type
gengtype-lex.c:524: error: expected unqualified-id before '?' token
...
It seems that there is a CR/LF problem because I can fix it by
running
/usr/bin/sed -e 's/^M$//'
on the generated gengtype-lex.c and then continue with the build.
It looks like my CygWin settings let gengtype-lex.c get created with
some CR/LF combinations, which the compiler is then not able to handle.
This is probably caused by having DOS/text default file system type:
$ mount -m
none /cygdrive cygdrive text,posix=0,user 0 0
However, as I might not be the only one having text mode (with CRLF generated)
as default, we should better fix this problem.
Note that with gcc 4.7.x this problem does not exist, so this problem is new
with 4.8.
[Bug other/55164] New: -fdump-*-all not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55164 Bug #: 55164 Summary: -fdump-*-all not working Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: mpola...@gcc.gnu.org Since r193061, the -fdump-*-all option produces no dumps, while e.g. -fdump-tree-vrp or -fdump-rtl-expand are fine.
[Bug other/55164] [4.8 Regression] -fdump-*-all not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55164 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-01 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.8.0 Summary|-fdump-*-all not working|[4.8 Regression] ||-fdump-*-all not working Ever Confirmed|0 |1
[Bug middle-end/55150] Crash in copy_rtx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55150 --- Comment #3 from Ryan Mansfield rmansfield at qnx dot com 2012-11-01 11:46:24 UTC --- I found similar crash that happens with the fix in comment #2 applied. i.e. using rev193061: $ ./xgcc -B. -m32 -Os -fpic -g ~/ice.i /home/ryan/ice.i: In function ‘DES_ede3_cbcm_encrypt’: /home/ryan/ice.i:49:2: internal compiler error: Segmentation fault } ^ 0x8e599f crash_signal ../../gcc/toplev.c:333 0x88ff75 copy_rtx(rtx_def*) ../../gcc/rtl.c:246 0x800458 remove_pseudos ../../gcc/lra-spills.c:435 0x8004c3 remove_pseudos ../../gcc/lra-spills.c:443 0x8004c3 remove_pseudos ../../gcc/lra-spills.c:443 0x8004c3 remove_pseudos ../../gcc/lra-spills.c:443 0x8004c3 remove_pseudos ../../gcc/lra-spills.c:443 0x8004c3 remove_pseudos ../../gcc/lra-spills.c:443 0x8004c3 remove_pseudos ../../gcc/lra-spills.c:443 0x800aa3 spill_pseudos ../../gcc/lra-spills.c:481 0x800aa3 lra_spill() ../../gcc/lra-spills.c:568 0x7ec7b4 lra(_IO_FILE*) ../../gcc/lra.c:2327 0x7b4156 do_reload ../../gcc/ira.c:4624 0x7b4156 rest_of_handle_reload ../../gcc/ira.c:4737 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions.
[Bug middle-end/55150] Crash in copy_rtx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55150 --- Comment #4 from Ryan Mansfield rmansfield at qnx dot com 2012-11-01 11:47:54 UTC --- Created attachment 28590 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28590 second preprocessed src testcase
[Bug c++/25466] typeid expression fails to throw bad_typeid according to 5.2.8p2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25466 --- Comment #11 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-01 11:53:26 UTC --- I see, thanks Daniel for the additional analysis. Indeed, I can confirm that with the operator+ return type fixed, ICC doesn't throw either. Now I guess it's my job to figure out the minimal change getting us the desired behavior...
[Bug tree-optimization/55104] [4.8 Regression] ice in inline_call, at ipa-inline-transform.c:269
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55104 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Depends on||55078 --- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org 2012-11-01 12:40:22 UTC --- Most probably dup of PR55078. I am going to silence the ICE until that one is fixed, lets not forget to double check that after fixing PR55078 this testcase gets fixed, too.
[Bug middle-end/55078] [4.8 Regression] FAIL: g++.dg/torture/pr46154.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55078 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Blocks|55104 | --- Comment #6 from Jan Hubicka hubicka at gcc dot gnu.org 2012-11-01 12:43:14 UTC --- I silenced the ICE until the real issue is fixed.
[Bug tree-optimization/55104] [4.8 Regression] ice in inline_call, at ipa-inline-transform.c:269
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55104 --- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org 2012-11-01 12:44:22 UTC --- Author: hubicka Date: Thu Nov 1 12:44:13 2012 New Revision: 193062 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193062 Log: PR middle-end/55104 * ipa-inline-transform.c (inline_call): Silence an sanity check until ipa-cp issue if fixed. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline-transform.c
[Bug target/55142] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55142 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Component|middle-end |target --- Comment #12 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-11-01 12:51:26 UTC --- Recategorizing.
[Bug rtl-optimization/54457] [x32] Fail to combine 64bit index + constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54457
Jack Howarth howarth at nitro dot med.uc.edu changed:
What|Removed |Added
CC||howarth at nitro dot
||med.uc.edu
--- Comment #7 from Jack Howarth howarth at nitro dot med.uc.edu 2012-11-01
13:49:44 UTC ---
Shouldn't the gcc.target/i386/pr54457.c testcase be...
Index: gcc/testsuite/gcc.target/i386/pr54457.c
===
--- gcc/testsuite/gcc.target/i386/pr54457.c (revision 193061)
+++ gcc/testsuite/gcc.target/i386/pr54457.c (working copy)
@@ -1,4 +1,4 @@
-/* { dg-do compile { target { ! { ia32 } } } } */
+/* { dg-do compile { target { ! { ia32 || lp64 } } } } */
/* { dg-options -O2 -mx32 -maddress-mode=short } */
extern char array[40];
On x86_64-apple-darwin12 at -m64, the gcc.target/i386/pr54457.c testcase fails
the excessive errors test whereas the change above converts that to an
unsupported test.
[Bug target/55142] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55142 --- Comment #13 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-11-01 14:20:17 UTC --- Created attachment 28591 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28591 Tentative fix This generates (essentially) the same RTL as in non-PIC mode, so the generated code should be correct if it is correct in non-PIC mode. Tested only in LP64 mode though.
[Bug c++/55159] pythy constexpr auto lambda pointer has no initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55159 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-01 14:25:26 UTC --- Daniel, you mean PR54111 maybe?
[Bug other/55165] New: Build failure for x86_64-w64-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55165 Bug #: 55165 Summary: Build failure for x86_64-w64-mingw32 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: vanboxem.ru...@gmail.com Building GCC master on 1 November 2012 for build=x86_64-gnu-linux host=x86_64-w64-mingw32 results in this error during the make all-target-libgcc step: /home/ruben/mingw-w64/src/gcc/gcc/stmt.c: In function 'void compute_cases_per_edge(gimple)': /home/ruben/mingw-w64/src/gcc/gcc/stmt.c:2064:54: error: cast from 'void*' to 'long int' loses precision [-fpermissive] case_edge-aux = (void *)((long)(case_edge-aux) + 1); ^ /home/ruben/mingw-w64/src/gcc/gcc/stmt.c:2064:59: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] case_edge-aux = (void *)((long)(case_edge-aux) + 1); ^ /home/ruben/mingw-w64/src/gcc/gcc/stmt.c: In function 'void expand_case(gimple)': /home/ruben/mingw-w64/src/gcc/gcc/stmt.c:2179:57: error: cast from 'void*' to 'long int' loses precision [-fpermissive] case_edge-probability / (long)(case_edge-aux), ^ This is due to the fact that a pointer is not an int.
[Bug other/55165] Build failure for x86_64-w64-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55165 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2012-11-01 14:38:50 UTC --- Change the first two (long) casts to (uintptr_t) and the third one to (intptr_t).
[Bug c++/55159] pythy constexpr auto lambda pointer has no initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55159
--- Comment #3 from Daniel Krügler daniel.kruegler at googlemail dot com
2012-11-01 15:11:51 UTC ---
(In reply to comment #2)
Hmmh, it doesn't look like that one, maybe I was wrong about an existing issue.
But it seems that gcc doesn't ignore the const (in const T* or const auto*)
for functions here, which seems to be the root of the second problem (This is
*not* attempting to form a function with cv-qualifier-seq). Both
template typename T
T* addr(T t) { return t; }
bool less(int x, int y) { return x y ? x : y; }
static auto* f = addr(less);
and
template typename T
T* addr(T t) { return t; }
bool less(int x, int y) { return x y ? x : y; }
templatetypename T
int deduce(T*) { return 0; }
int i = deduce(addr(less));
are accepted as they should.
[Bug other/55164] [4.8 Regression] -fdump-*-all not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55164 --- Comment #1 from singhai at google dot com 2012-11-01 16:26:21 UTC --- Found the culprit. A flag was accidentally committed in wrong order. The following patch fixes it. I am testing it. Thanks, Sharad 2012-11-01 Sharad Singhai sing...@google.com PR other/55164 * dumpfile.h (struct dump_file_info): Fix order of flags. Index: dumpfile.h === --- dumpfile.h (revision 193061) +++ dumpfile.h (working copy) @@ -113,8 +113,8 @@ struct dump_file_info const char *alt_filename; /* filename for the -fopt-info stream */ FILE *pstream;/* pass-specific dump stream */ FILE *alt_stream; /* -fopt-info stream */ + int pflags; /* dump flags */ int optgroup_flags; /* optgroup flags for -fopt-info */ - int pflags; /* dump flags */ int alt_flags;/* flags for opt-info */ int pstate; /* state of pass-specific stream */ int alt_state;/* state of the -fopt-info stream */
[Bug c++/52718] -Wzero-as-null-pointer-constant: misleading location for 0 as default argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52718
--- Comment #12 from Matthew Woehlke mw_triad at users dot sourceforge.net
2012-11-01 17:47:04 UTC ---
Requires qt-devel installed, but has the benefit of being the exact issue I'm
having in production (on the chance it's something screwy about Qt...):
$ cat zero-as-pointer.cpp
#include QtGui/QLabel
int main()
{
QLabel label;
return 0;
}
$ g++ -std=c++11 -Werror=zero-as-null-pointer-constant zero-as-pointer.cpp
zero-as-pointer.cpp: In function ‘int main()’:
zero-as-pointer.cpp:5:10: error: zero as null pointer constant
[-Werror=zero-as-null-pointer-constant]
cc1plus: some warnings being treated as errors
Exit 1
$ g++ --version
g++ (GCC) 4.7.2 20120921 (Red Hat 4.7.2-2)
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
...maybe it got fixed in 4.7.3?
Note: the problem is this ctor:
explicit QLabel(QWidget *parent=0, Qt::WindowFlags f=0);
If I replace my declaration with:
QLabel label(nullptr, Qt::WindowFlags(nullptr));
...then I get no warning.
[Bug other/55164] [4.8 Regression] -fdump-*-all not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55164 --- Comment #2 from Sharad Singhai singhai at gcc dot gnu.org 2012-11-01 17:55:46 UTC --- Author: singhai Date: Thu Nov 1 17:55:23 2012 New Revision: 193064 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193064 Log: 2012-11-01 Sharad Singhai sing...@google.com PR other/55164 * dumpfile.h (struct dump_file_info): Fix order of flags. Modified: trunk/gcc/ChangeLog trunk/gcc/dumpfile.h
[Bug c++/52718] -Wzero-as-null-pointer-constant: misleading location for 0 as default argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52718
--- Comment #13 from Matthew Woehlke mw_triad at users dot sourceforge.net
2012-11-01 17:56:49 UTC ---
...and with your example I do indeed get no warning.
Simplified test case:
$ cat zero-as-pointer.h
#pragma GCC system_header
class Foo
{
public:
Foo(void** = 0);
};
class Bar
{
public:
Bar(Foo = 0);
};
$ cat zero-as-pointer.cpp
#include zero-as-pointer.h
int main()
{
Bar bar;
return 0;
}
$ g++ -std=c++11 -Werror=zero-as-null-pointer-constant zero-as-pointer.cpp
zero-as-pointer.cpp: In function ‘int main()’:
zero-as-pointer.cpp:5:7: error: zero as null pointer constant
[-Werror=zero-as-null-pointer-constant]
cc1plus: some warnings being treated as errors
Apparently it is something about the 'Foo = 0' part (replace Foo with
Qt::WindowFlags in my 'real' example).
[Bug middle-end/54957] Two crashes introduced by rev192488
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54957 --- Comment #21 from rbmj at verizon dot net 2012-11-01 18:05:36 UTC --- That fixes it for me :)
[Bug other/55164] [4.8 Regression] -fdump-*-all not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55164 Sharad Singhai singhai at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Sharad Singhai singhai at gcc dot gnu.org 2012-11-01 18:05:53 UTC --- This should be fixed now at r193064.
[Bug c++/55166] New: c++11: std::string and =std:move makes swapping
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55166
Bug #: 55166
Summary: c++11: std::string and =std:move makes swapping
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lis...@lisp2d.net
While moving std::string value to another place g++ makes something different.
std::string t0{abc};
std::string t1{123};
t0 = std::move(t1); or t0 = static_caststd::string (t1);
is the same result as
std::swap(t0,t1);
[Bug c++/55166] c++11: std::string and =std:move makes swapping
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55166
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-01
18:40:49 UTC ---
The standard says that after the move t1 will be in a valid but unspecified
state.
It does not say it will be empty.
There are performance advantages to the current behaviour because if you do
this:
std::string t0{abc};
std::string t1{123};
t0 = std::move(t1);
t1 = xyz;
there is no allocation for the last line, because it already has memory
You keep reporting invalid bugs which are actually correct C++11 behaviour.
Please find somewhere else to learn C++, such as stackoverflow.com
[Bug regression/55167] New: [4.8 Regression]: g++.dg/other/vector-compare.C, ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55167 Bug #: 55167 Summary: [4.8 Regression]: g++.dg/other/vector-compare.C, ICE Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: regression AssignedTo: unassig...@gcc.gnu.org ReportedBy: h...@gcc.gnu.org CC: gli...@gcc.gnu.org Host: x86_64-unknown-linux-gnu Target: cris-axis-elf This test previously passed, now it fails. A patch in the revision range (last_known_working:first_known_failing) 192985:192991 exposed or caused this regression. Since then it fails as follows: Running /tmp/hpautotest-gcc0/gcc/gcc/testsuite/g++.dg/dg.exp ... FAIL: g++.dg/other/vector-compare.C (internal compiler error) FAIL: g++.dg/other/vector-compare.C (test for excess errors) In g++.log: Executing on host: /tmp/hpautotest-gcc0/cris-elf/gccobj/gcc/testsuite/g++/../../g++ -B/tmp/hpautotest-gcc0/cris-elf/gccobj/gcc/testsuite/g++/../../ /tmp/hpautotest-gcc0/gcc/gcc/testsuite/g++.dg/other/vector-compare.C -fno-diagnostics-show-caret -nostdinc++ -I/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/libstdc++-v3/include/cris-elf -I/tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/libstdc++-v3/include -I/tmp/hpautotest-gcc0/gcc/libstdc++-v3/libsupc++ -I/tmp/hpautotest-gcc0/gcc/libstdc++-v3/include/backward -I/tmp/hpautotest-gcc0/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++11 -Wall -S -isystem /tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/./newlib/targ-include -isystem /tmp/hpautotest-gcc0/gcc/newlib/libc/include -o vector-compare.s(timeout = 300) /tmp/hpautotest-gcc0/gcc/gcc/testsuite/g++.dg/other/vector-compare.C: In function 'int main()': /tmp/hpautotest-gcc0/gcc/gcc/testsuite/g++.dg/other/vector-compare.C:30:21: internal compiler error: Segmentation fault 0x9fc565 crash_signal /tmp/hpautotest-gcc0/gcc/gcc/toplev.c:333 0x802f65 force_operand(rtx_def*, rtx_def*) /tmp/hpautotest-gcc0/gcc/gcc/expr.c:6975 0x743ac0 expand_gimple_stmt_1 /tmp/hpautotest-gcc0/gcc/gcc/cfgexpand.c:2168 0x743ac0 expand_gimple_stmt /tmp/hpautotest-gcc0/gcc/gcc/cfgexpand.c:2204 0x744b39 expand_gimple_basic_block /tmp/hpautotest-gcc0/gcc/gcc/cfgexpand.c:3979 0x746276 gimple_expand_cfg /tmp/hpautotest-gcc0/gcc/gcc/cfgexpand.c:4498 According to http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02858.html, this also happens for i686-linux and revision r192986 is to blame. Author of suspect patch CC:ed.
[Bug middle-end/55150] Crash in copy_rtx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55150 --- Comment #5 from Vladimir Makarov vmakarov at gcc dot gnu.org 2012-11-01 19:02:48 UTC --- Author: vmakarov Date: Thu Nov 1 19:02:40 2012 New Revision: 193065 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193065 Log: 2012-11-01 Vladimir Makarov vmaka...@redhat.com PR middle-end/55150 * lra-constraints.c (lra_constraints): Check only pseudos with equivalences. Add insns with equivalence pseudos. 2012-11-01 Vladimir Makarov vmaka...@redhat.com PR middle-end/55150 * gcc.dg/pr55150.c: Rename to gcc.dg/pr55150-1.c. * gcc.dg/pr55150-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr55150-1.c trunk/gcc/testsuite/gcc.dg/pr55150-2.c Removed: trunk/gcc/testsuite/gcc.dg/pr55150.c Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c trunk/gcc/testsuite/ChangeLog
[Bug regression/55167] [4.8 Regression]: g++.dg/other/vector-compare.C, ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55167 --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org 2012-11-01 19:05:13 UTC --- Thanks. Since the error happens in expand, I assume this is a dup of PR 55001, for which I posted a patch earlier today. Note that AFAIK, anything that starts failing because of this patch was silently miscompiled before. (I am also investigating a different problem with this testcase, due to the fact that the C front-end turns (void)(x0) into if(x0)(void)0 which vector x doesn't like)
[Bug c++/52718] -Wzero-as-null-pointer-constant: misleading location for 0 as default argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52718 --- Comment #14 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-01 19:07:10 UTC --- Ok, I can reproduce this. Note, I don't think it's the same issue reported here earlier. Apparently something is going wrong with the pragma. A WA is writing: Bar(Foo = Foo(0)); in this case the warning is correctly suppressed. The 0 in the Foo constructor doesn't matter, the warning is correctly suppressed and you can as well remove it from the testcase. I'm looking into this, hopefully can be fixed without reworking too many diagnostic things outside this specific warning proper.
[Bug regression/55168] New: [4.8 Regression]: gcc.c-torture/compile/pr44119.c ICE, all but -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55168 Bug #: 55168 Summary: [4.8 Regression]: gcc.c-torture/compile/pr44119.c ICE, all but -O0 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: regression AssignedTo: unassig...@gcc.gnu.org ReportedBy: h...@gcc.gnu.org CC: ste...@gcc.gnu.org Host: x86_64-unknown-linux-gnu Target: cris-axis-elf This test previously passed, now it fails. A patch in the revision range (last_known_working:first_known_failing) 193042:193049 exposed or caused this regression. Since then it fails as follows: Running /tmp/hpautotest-gcc0/gcc/gcc/testsuite/gcc.c-torture/compile/compile.exp ... FAIL: gcc.c-torture/compile/pr44119.c -O1 (internal compiler error) FAIL: gcc.c-torture/compile/pr44119.c -O1 (test for excess errors) FAIL: gcc.c-torture/compile/pr44119.c -O2 (internal compiler error) FAIL: gcc.c-torture/compile/pr44119.c -O2 (test for excess errors) FAIL: gcc.c-torture/compile/pr44119.c -O3 -fomit-frame-pointer (internal compiler error) FAIL: gcc.c-torture/compile/pr44119.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.c-torture/compile/pr44119.c -O3 -fomit-frame-pointer -funroll-loops (internal compiler error) FAIL: gcc.c-torture/compile/pr44119.c -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gcc.c-torture/compile/pr44119.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (internal compiler error) FAIL: gcc.c-torture/compile/pr44119.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gcc.c-torture/compile/pr44119.c -O3 -g (internal compiler error) FAIL: gcc.c-torture/compile/pr44119.c -O3 -g (test for excess errors) FAIL: gcc.c-torture/compile/pr44119.c -Os (internal compiler error) FAIL: gcc.c-torture/compile/pr44119.c -Os (test for excess errors) FAIL: gcc.c-torture/compile/pr44119.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error) FAIL: gcc.c-torture/compile/pr44119.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors) FAIL: gcc.c-torture/compile/pr44119.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (internal compiler error) FAIL: gcc.c-torture/compile/pr44119.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors) The messages in gcc.log are similar: Executing on host: /tmp/hpautotest-gcc0/cris-elf/gccobj/gcc/xgcc -B/tmp/hpautotest-gcc0/cris-elf/gccobj/gcc/ -fno-diagnostics-show-caret -O1 -w -c -isystem /tmp/hpautotest-gcc0/cris-elf/gccobj/cris-elf/./newlib/targ-include -isystem /tmp/hpautotest-gcc0/gcc/newlib/libc/include -o pr44119.o /tmp/hpautotest-gcc0/gcc/gcc/testsuite/gcc.c-torture/compile/pr44119.c (timeout = 300) /tmp/hpautotest-gcc0/gcc/gcc/testsuite/gcc.c-torture/compile/pr44119.c: In function 'func_96': /tmp/hpautotest-gcc0/gcc/gcc/testsuite/gcc.c-torture/compile/pr44119.c:45:1: internal compiler error: Floating point exception 0x84ab35 crash_signal /tmp/hpautotest-gcc0/gcc/gcc/toplev.c:333 0x7d4bbf predict_loops /tmp/hpautotest-gcc0/gcc/gcc/predict.c:1524 0x7d67b4 tree_estimate_probability() /tmp/hpautotest-gcc0/gcc/gcc/predict.c:2259 0x7d75d4 tree_estimate_probability_driver /tmp/hpautotest-gcc0/gcc/gcc/predict.c:2296 Author of only suspect patch in revision range CC:ed.
[Bug libstdc++/55169] New: std::discrete_distribution::operator(generator) makes unnecessary copy of parameter vector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55169 Bug #: 55169 Summary: std::discrete_distribution::operator(generator) makes unnecessary copy of parameter vector Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: chri.sn...@gmail.com Created attachment 28592 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28592 demonstration of slow std::discrete_distribution in GCC std::discrete_distribution::operator()(generator) is significantly slower than directly calling operator()(generator, const param_type), which it delegates to. This is because, on random.h:4805, this-param() returns a copy rather than a const reference. The attached file is a simple test demonstrating this inefficient behaviour.
[Bug libstdc++/55169] std::discrete_distribution::operator(generator) makes unnecessary copy of parameter vector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55169 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-11-01 AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-01 19:38:51 UTC --- Yes, seems easy to fix.
[Bug libstdc++/55169] std::discrete_distribution::operator(generator) makes unnecessary copy of parameter vector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55169 --- Comment #2 from Chris Nell chri.snell at gmail dot com 2012-11-01 19:48:43 UTC --- After a bit more poking, it appears that param() returns a copy (not a const reference) for all distributions, not just discrete_distribution. As such, it might we worth looking into whether other implementations of operator(generator) suffer from the same bug.
[Bug regression/55167] [4.8 Regression]: g++.dg/other/vector-compare.C, ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55167 --- Comment #2 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-11-01 19:52:02 UTC --- (In reply to comment #1) Since the error happens in expand, I assume this is a dup of PR 55001, for which I posted a patch earlier today. It could be; that PR lacks a description of the effects, so my pre-report search did not find it. (It only speaks of something missing in the code, could be just a missing optimization at a glance.) I'll leave dealing with it to you.
[Bug middle-end/55103] [4.8 Regression] All MIPS16 attribute tests ICEs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55103 Steve Ellcey sje at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-01 CC||sje at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #3 from Steve Ellcey sje at gcc dot gnu.org 2012-11-01 19:53:01 UTC --- I am seeing this failure as well when building newlib with the -mips16 option. Here is a cut down test case (1 line) that gives me the same segfault as Andrew is seeing. argz_add(char **argz , long unsigned int *argz_len , const char *str)
[Bug libstdc++/55169] std::discrete_distribution::operator(generator) makes unnecessary copy of parameter vector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55169 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-01 19:59:48 UTC --- Of course, of course. But in 4_7-branch we are going to change only the three distributions using std::vectors
[Bug regression/55167] [4.8 Regression]: g++.dg/other/vector-compare.C, ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55167 --- Comment #3 from Marc Glisse glisse at gcc dot gnu.org 2012-11-01 20:22:14 UTC --- (In reply to comment #2) It could be; that PR lacks a description of the effects, so my pre-report search did not find it. (It only speaks of something missing in the code, could be just a missing optimization at a glance.) Yes, sorry, dup probably wasn't the right term, I meant it as: I think I know what's going on. Thanks again for filing the bug and CCing me.
[Bug c++/55170] New: incorrect mangling, should not include prefix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55170
Bug #: 55170
Summary: incorrect mangling, should not include prefix
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rafael.espind...@gmail.com
Given the testcase
namespace mozilla {
templatetypename From
struct IsConvertible {
static const bool value =true;
};
templatebool B
struct EnableIf {
typedef int Type;
};
template typename S
void Handle(S x, typename EnableIfIsConvertibleS::value::Type dummy) {
}
template void
Handle(int x, EnableIfIsConvertibleint::value::Type dummy);
}
With current gcc trunk (193066) we get
$ gcc -fabi-version=0 -c test.cpp -w
$ nm test.o
W
_ZN7mozilla6HandleIiEEvT_NS_8EnableIfIXsrNS_13IsConvertibleIS1_EE5valueEE4TypeE
And with clang
$ ./build/bin/clang -c test.cpp
$ nm test.o
W
_ZN7mozilla6HandleIiEEvT_NS_8EnableIfIXsr13IsConvertibleIS1_EE5valueEE4TypeE
I initially thought the bug was in clang and reported llvm.org/pr14118, but
John McCall says that On cxx-abi-dev, I believe we decided that
prefixes on unresolved-names should be mangled essentially as written.
[Bug regression/55168] [4.8 Regression]: gcc.c-torture/compile/pr44119.c ICE, all but -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55168 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-11-01 20:26:05 UTC --- Found the patch, added co-author to CC.
[Bug c++/55170] incorrect mangling, should not include prefix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55170 --- Comment #1 from Rafael Avila de Espindola rafael.espindola at gmail dot com 2012-11-01 20:29:02 UTC --- The relevant thread seems to be http://sourcerytools.com/pipermail/cxx-abi-dev/2011-April/002404.html
Re: [Bug regression/55168] New: [4.8 Regression]: gcc.c-torture/compile/pr44119.c ICE, all but -O0
This actually looks like a previously latent issue in predict.c For all but
estimate_num_iterations_int. It uses the funny definition of number of
iterations (i.e. 0 means that loop will exit at first invocation of the exit
condition and that is what it will be predicted with when nitercst == 1.
Index: predict.c
===
--- predict.c (revision 193062)
+++ predict.c (working copy)
@@ -1433,8 +1437,8 @@ predict_loops (void)
the loop, use it to predict this exit. */
else if (n_exits == 1)
{
- nitercst = estimated_stmt_executions_int (loop);
- if (nitercst 0)
+ nitercst = estimated_stmt_executions_int (loop) + 1;
+ if (nitercst = 0)
continue;
if (nitercst max)
nitercst = max;
[Bug regression/55168] [4.8 Regression]: gcc.c-torture/compile/pr44119.c ICE, all but -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55168
--- Comment #2 from Jan Hubicka hubicka at ucw dot cz 2012-11-01 20:49:18 UTC
---
This actually looks like a previously latent issue in predict.c For all but
estimate_num_iterations_int. It uses the funny definition of number of
iterations (i.e. 0 means that loop will exit at first invocation of the exit
condition and that is what it will be predicted with when nitercst == 1.
Index: predict.c
===
--- predict.c (revision 193062)
+++ predict.c (working copy)
@@ -1433,8 +1437,8 @@ predict_loops (void)
the loop, use it to predict this exit. */
else if (n_exits == 1)
{
- nitercst = estimated_stmt_executions_int (loop);
- if (nitercst 0)
+ nitercst = estimated_stmt_executions_int (loop) + 1;
+ if (nitercst = 0)
continue;
if (nitercst max)
nitercst = max;
[Bug c++/52718] -Wzero-as-null-pointer-constant: misleading location for 0 as default argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52718
--- Comment #15 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-01
20:52:15 UTC ---
This is what I meant when I said that the issue is different, and is much more
general than -Wzero-as-null-pointer-constant. Consider, eg, with -Woverflow:
#pragma GCC system_header
class Foo
{
public:
Foo(signed char);
};
class Bar
{
public:
Bar(Foo = 1);
};
[Bug libstdc++/55047] operator() in std::exponential_distribution may call log(0)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55047 --- Comment #4 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2012-11-01 21:09:57 UTC --- Author: paolo Date: Thu Nov 1 21:09:51 2012 New Revision: 193070 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193070 Log: 2012-11-01 Haakan Younes hyou...@google.com Paolo Carlini paolo.carl...@oracle.com PR libstdc++/55047 * include/bits/random.h (exponential_distribution::operator): Fix formula to std::log(result_type(1) - __aurng()). * include/bits/random.tcc: Likewise, everywhere. Modified: branches/gcc-4_7-branch/libstdc++-v3/ChangeLog branches/gcc-4_7-branch/libstdc++-v3/include/bits/random.h branches/gcc-4_7-branch/libstdc++-v3/include/bits/random.tcc
[Bug libstdc++/55047] operator() in std::exponential_distribution may call log(0)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55047 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-01 21:11:02 UTC --- Fixed mainline and 4.7.3.
[Bug c++/55171] New: incorrect virtual thunk on mingw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55171
Bug #: 55171
Summary: incorrect virtual thunk on mingw
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mi...@ociweb.com
Created attachment 28593
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28593
test for virtual call on mingw
When a virtual call invoked on an object which uses both virtual and
non-virtual inheritance, the virtual thunk leaves the target function with an
invalid this pointer.
Attached test fails with output:
created Derived object at: 0x2c1a50
Derived virtual call at: 0x409800
Assertion failed!
From gdb:
In the body of the most-derived constructor
(gdb) inf vt this
vtable for 'Derived' @ 0x4097ec (subobject @ 0x2c1a50):
[0]: 0x40188a Derived::~Derived()
[1]: 0x40190a Derived::~Derived()
[2]: 0x401932 Derived::foo() const
vtable for 'VirtBase' @ 0x409808 (subobject @ 0x2c1a58):
[0]: 0x401902 virtual thunk to Derived::~Derived()
[1]: 0x40192a virtual thunk to Derived::~Derived()
[2]: 0x4019d1 virtual thunk to Derived::foo() const
0x004019d1 in virtual thunk to Derived::foo() const () at gccbug.cpp:45
Dump of assembler code for function _ZTv0_n16_NK7Derived3fooEv:
= 0x004019d1 +0: mov0x4(%esp),%eax
0x004019d5 +4: mov(%eax),%eax
0x004019d7 +6: add-0x10(%eax),%eax
0x004019da +9: mov%eax,0x4(%esp)
0x004019de +13:jmp0x401932 Derived::foo() const
After thunk has jumped to target function
Derived::foo (this=0x409800) at gccbug.cpp:41
41 {
(gdb) inf vt this
Cannot access memory at address 0xffec
[Bug target/54938] sh libgcc_unpack_df.o fails to build: ../../../srcw/libgcc/fp-bit.h:221:19: internal compiler error: in emit_cmp_and_jump_insn_1, at optabs.c:4273
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54938 --- Comment #7 from Oleg Endo olegendo at gcc dot gnu.org 2012-11-01 21:19:53 UTC --- I guess this is done, isn't it Easwaran?
[Bug target/29963] could speed up variable access with different object layout
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29963 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added CC||olegendo at gcc dot gnu.org --- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org 2012-11-01 21:26:56 UTC --- I'm not sure how the proposed optimization could be done in a generic way. It would not work for code (i.e. text section) that resides in read-only memory, such as ROM or MMU read-only pages.
[Bug target/55160] [4.8 Regression] Counterproductive loop induction variable optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55160 --- Comment #3 from Oleg Endo olegendo at gcc dot gnu.org 2012-11-01 21:28:53 UTC --- Author: olegendo Date: Thu Nov 1 21:28:49 2012 New Revision: 193071 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193071 Log: PR target/55160 * gcc.target/sh/pr55160.c: New. Added: trunk/gcc/testsuite/gcc.target/sh/pr55160.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/29963] could speed up variable access with different object layout
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29963 --- Comment #2 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org 2012-11-01 21:42:12 UTC --- (In reply to comment #1) I'm not sure how the proposed optimization could be done in a generic way. It would not work for code (i.e. text section) that resides in read-only memory, such as ROM or MMU read-only pages. In that case, you could indeed only do this optimization for constant variables / arrays. But it is not uncommon to load the program into RAM before executing, e.g. because the ROM it's stored in is too slow. In this case, placing the program code in a writable segment is merely a matter of policy; the user would be expected have control if this optimization is enabled, taking into account if there are any overriding security concerns.
[Bug c++/52718] -Wzero-as-null-pointer-constant: misleading location for 0 as default argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52718
--- Comment #16 from mwoehlke.floss at gmail dot com 2012-11-01 22:03:46 UTC ---
On 2012-11-01 16:52, paolo.carlini at oracle dot com wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52718
--- Comment #15 from Paolo Carlini paolo.carlini at oracle dot com
2012-11-01 20:52:15 UTC ---
This is what I meant when I said that the issue is different, and is much more
general than -Wzero-as-null-pointer-constant. Consider, eg, with -Woverflow:
#pragma GCC system_header
class Foo
{
public:
Foo(signed char);
};
class Bar
{
public:
Bar(Foo = 1);
};
Would you prefer I open a new bug report?
[Bug middle-end/55142] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55142 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|ASSIGNED|NEW Component|target |middle-end --- Comment #14 from H.J. Lu hjl.tools at gmail dot com 2012-11-01 22:24:20 UTC --- (In reply to comment #13) Created attachment 28591 [details] Tentative fix This generates (essentially) the same RTL as in non-PIC mode, so the generated code should be correct if it is correct in non-PIC mode. Tested only in LP64 mode though. The patch compiles testcase, but totally miscompiles glibc. I think the bug is in unsigned array index computation as shown in Comment 7. dyn-d_tag is signed type and Pmode != ptr_mode here.
[Bug target/55145] [4.8 Regression] [x32] -maddress-mode=long miscompiles glibc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55145 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|WAITING |NEW --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2012-11-01 22:29:22 UTC --- I don't know if there are other bugs in addition to PR 55142. I will leave it open until I can compile glibc to verify.
[Bug middle-end/55142] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55142 --- Comment #15 from H.J. Lu hjl.tools at gmail dot com 2012-11-01 22:30:16 UTC --- All binaries die before main: Starting program: /export/build/gnu/glibc-x32-long/build-x86_64-linux/libio/bug-fclose1 Program received signal SIGSEGV, Segmentation fault. 0xf7dddc8d in elf_get_dynamic_info (temp=0x0, l=0xf7ffdc18) at get-dynamic-info.h:61 61 + DT_VERSIONTAGNUM + DT_EXTRANUM + DT_VALNUM] = dyn; (gdb) disass $pc -19, +30 Dump of assembler code from 0xf7dddc7a to 0xf7dddc98: 0xf7dddc7a dl_main+5210:mov%r8d,%esi 0xf7dddc7d dl_main+5213:sub%eax,%esi 0xf7dddc7f dl_main+5215:cmp$0xa,%esi 0xf7dddc82 dl_main+5218:ja 0xf7ddd431 dl_main+3089 0xf7dddc88 dl_main+5224:neg%eax 0xf7dddc8a dl_main+5226:lea(%rcx,%rax,4),%eax = 0xf7dddc8d dl_main+5229:mov%edx,-0x4300(%rax) 0xf7dddc93 dl_main+5235:jmpq 0xf7ddd431 dl_main+3089 End of assembler dump. (gdb) p/x $rcx $1 = 0xf7ffdc38 (gdb) p/x $rax $2 = 0x37ffe064 (gdb) list 56 else if ((d_tag_utype) DT_VALTAGIDX (dyn-d_tag) DT_VALNUM) 57info[DT_VALTAGIDX (dyn-d_tag) + DT_NUM + DT_THISPROCNUM 58 + DT_VERSIONTAGNUM + DT_EXTRANUM] = dyn; 59 else if ((d_tag_utype) DT_ADDRTAGIDX (dyn-d_tag) DT_ADDRNUM) 60info[DT_ADDRTAGIDX (dyn-d_tag) + DT_NUM + DT_THISPROCNUM 61 + DT_VERSIONTAGNUM + DT_EXTRANUM + DT_VALNUM] = dyn; 62 ++dyn; 63} 64 65#define DL_RO_DYN_TEMP_CNT8 (gdb) p info $3 = (Elf32_Dyn **) 0xf7ffdc38 (gdb) bt #0 0xf7dddc8d in elf_get_dynamic_info (temp=0x0, l=0xf7ffdc18) at get-dynamic-info.h:61 #1 dl_main (phdr=optimized out, phnum=9, user_entry=optimized out, auxv=optimized out) at rtld.c:1311 #2 0xf7df12c0 in _dl_sysdep_start ( start_argptr=start_argptr@entry=0xd100, dl_main=optimized out) at ../elf/dl-sysdep.c:241 #3 0xf7ddfaa8 in _dl_start_final (arg=0xd100) at rtld.c:331 #4 _dl_start (arg=optimized out) at rtld.c:557 #5 0xf7ddc057 in _start () from /export/build/gnu/glibc-x32-long/build-x86_64-linux/elf/ld.so #6 0x0001 in ?? () #7 0x in ?? () (gdb)
[Bug rtl-optimization/54457] [x32] Fail to combine 64bit index + constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54457
--- Comment #8 from H.J. Lu hjl.tools at gmail dot com 2012-11-01 22:31:45
UTC ---
(In reply to comment #7)
Shouldn't the gcc.target/i386/pr54457.c testcase be...
Index: gcc/testsuite/gcc.target/i386/pr54457.c
===
--- gcc/testsuite/gcc.target/i386/pr54457.c (revision 193061)
+++ gcc/testsuite/gcc.target/i386/pr54457.c (working copy)
@@ -1,4 +1,4 @@
-/* { dg-do compile { target { ! { ia32 } } } } */
+/* { dg-do compile { target { ! { ia32 || lp64 } } } } */
/* { dg-options -O2 -mx32 -maddress-mode=short } */
extern char array[40];
On x86_64-apple-darwin12 at -m64, the gcc.target/i386/pr54457.c testcase fails
the excessive errors test whereas the change above converts that to an
unsupported test.
It will disable test on Linux/x86-64. We can add
check_effective_target_maybe_x32 to check if -mx32
works before compiling with -mx32.
[Bug rtl-optimization/54457] [x32] Fail to combine 64bit index + constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54457
--- Comment #9 from H.J. Lu hjl.tools at gmail dot com 2012-11-01 22:37:20
UTC ---
Like this:
# Return 1 if -mx32 can compile, 0 otherwise.
proc check_effective_target_maybe_x32 { } {
return [check_no_compiler_messages maybe_x32 object {
void foo (void) {}
} {-mx32}]
}
[Bug c++/52718] -Wzero-as-null-pointer-constant: misleading location for 0 as default argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52718 --- Comment #17 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-01 22:42:05 UTC --- If you like, sure. I want to emphasize again that the issue really is about the behavior of the pragma vs warnings for default arguments, *any* warning, and if you check is *very* old. Before filing a new PR please double check that the issue has not been discussed already and maybe resolved as wontfix for some reason. Thanks.
[Bug fortran/55172] New: ICE on invalid: gfc_variable_attr(): Bad array reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55172 Bug #: 55172 Summary: ICE on invalid: gfc_variable_attr(): Bad array reference Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: abenso...@gmail.com The following test case produces and ICE with gfortran 4.8 (r193051): module gn type :: ncb end type ncb type, public :: tn class(ncb), allocatable, dimension(:) :: cb end type tn contains integer function name(self) implicit none class (tn), intent(in) :: self select type (component = self%cb(i)) end select end function name end module gn $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-unknown- linux-gnu/4.8.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-trunk/configure -- prefix=/home/abenson/Galacticus/Tools --enable-languages=c,c++,fortran -- disable-multilib --with-gmp=/home/abenson/Galacticus/Tools Thread model: posix gcc version 4.8.0 20121031 (experimental) (GCC) $ gfortran -c bug4.F90 -o bug4.o bug4.F90:14.13: end module gn 1 Internal Error at (1): gfc_variable_attr(): Bad array reference The code is invalid because the name function contains implicit none but the variable i used in: select type (component = self%cb(i)) is not explicitly defined. If I remove the implicit none or explicitly define i the ICE goes away. (Reported by Janus at http://gcc.gnu.org/ml/fortran/2012-11/msg5.html): With 4.7 the ICE also occurs, but only after the correct error message: select type (component = self%cb(i)) 1 Error: Symbol 'i' at (1) has no IMPLICIT type
[Bug middle-end/55142] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55142 --- Comment #16 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-11-01 23:00:06 UTC --- The patch compiles testcase, but totally miscompiles glibc. Ouch. Then this means that the existing non-PIC code is wrong as well. I think the bug is in unsigned array index computation as shown in Comment 7. dyn-d_tag is signed type and Pmode != ptr_mode here. Possibly, you must be extra careful with these kinds of awkward setups. We already had similar issues in the past (MEM_REF expansion on SPARC64, array indexes on IA-64/VMS) but the bugs were in the RTL expansion. I'll dig.
[Bug c++/55173] New: GCC gives wrong location, and ignores -isystem, when warning about default arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55173
Bug #: 55173
Summary: GCC gives wrong location, and ignores -isystem, when
warning about default arguments
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mw_tr...@users.sourceforge.net
This came up originally related to bug 52718, but according to Paolo there, is
not actually related at all...
Consider the following header:
#pragma GCC system_header // or include via -isystem
class Foo
{
Foo(void* = 0);
};
class Bar
{
Bar(Foo = 0, void* = 0)
};
The following instantiation:
Bar bar;
...trips -Wzero-as-null-pointer-constant (also, the warning is reported in the
source file, not the header).
This appears to only happen when a default parameter implicitly invokes a
constructor, where the warning occurs in the constructor invocation. IOW, this:
Bar bar(nullptr);
...does not trigger a warning, as 'Foo(nullptr)' is okay.
Besides the less-helpful-than-desired diagnostic, this behavior is unfortunate,
as it prevents promoting warnings to errors in the face of such constructs, or
else forcing programmers to avoid use of default parameters.
[Bug c++/52718] -Wzero-as-null-pointer-constant: misleading location for 0 as default argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52718
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment #18 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-11-01
23:00:51 UTC ---
(In reply to comment #15)
This is what I meant when I said that the issue is different, and is much more
general than -Wzero-as-null-pointer-constant. Consider, eg, with -Woverflow:
#pragma GCC system_header
class Foo
{
public:
Foo(signed char);
};
class Bar
{
public:
Bar(Foo = 1);
};
The issue is that literals don't have locations, so input_location is used. And
input_location here is in the main file, so system_header doesn't apply. This
is why input_location must die.
Clang uses the correct location for warning, so it honors system_header
(requires -Wsystem-headers):
In file included from pr52718.c:1:
./pr52718.h:11:13: warning: implicit conversion from 'int' to 'signed char'
changes value from 1 to 16 [-Wconstant-conversion]
Bar(Foo = 1);
^
1 warning generated.
Ultimately, GCC needs to track the locations of literals like clang does.
Everything else is a hack around the main issue. This is PR43486. There have
been some recent attempts
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01222.html, but I am afraid that
work seems stalled for lack of time/help.
[Bug c++/52718] -Wzero-as-null-pointer-constant: misleading location for 0 as default argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52718 --- Comment #19 from Matthew Woehlke mw_triad at users dot sourceforge.net 2012-11-01 23:04:42 UTC --- Reported as bug 55173. I'm not going to claim to understand bug 43486 sufficiently to know it is the same issue, but if you are sure, please feel free to close as duplicate.
[Bug c++/55173] GCC gives wrong location, and ignores -isystem, when warning about default arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55173 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-01 23:06:54 UTC --- Dup *** This bug has been marked as a duplicate of bug 43486 ***
[Bug c++/43486] Preserve variable-use locations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43486 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-01 23:06:54 UTC --- *** Bug 55173 has been marked as a duplicate of this bug. ***
[Bug middle-end/55142] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55142 --- Comment #17 from H.J. Lu hjl.tools at gmail dot com 2012-11-01 23:07:06 UTC --- T(In reply to comment #16) I think the bug is in unsigned array index computation as shown in Comment 7. dyn-d_tag is signed type and Pmode != ptr_mode here. Possibly, you must be extra careful with these kinds of awkward setups. We already had similar issues in the past (MEM_REF expansion on SPARC64, array indexes on IA-64/VMS) but the bugs were in the RTL expansion. I'll dig. I agree. It is a pain to work with Pmode == DImode and ptr_mode == SImode for x32. On the other hand, it does expose many issues in middle-end as well as in backend.
[Bug middle-end/55103] [4.8 Regression] All MIPS16 attribute tests ICEs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55103 Steve Ellcey sje at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Steve Ellcey sje at gcc dot gnu.org 2012-11-01 23:17:48 UTC --- I have checked in a patch for this problem as an obvious fix. http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00153.html I forgot to put the bug number in ChangeLog, that is why bugzilla did not get updated automatically.
[Bug c++/52718] -Wzero-as-null-pointer-constant: misleading location for 0 as default argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52718 --- Comment #20 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-11-01 23:23:41 UTC --- (In reply to comment #19) Reported as bug 55173. I'm not going to claim to understand bug 43486 sufficiently to know it is the same issue, but if you are sure, please feel free to close as duplicate. Well, it is the same underlying issue. It could be worked-around case by case by passing some location (like the = location) down to the warning point. But this is likely quite a large refactoring. The alternative is some general infrastructure like the one proposed in: http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01222.html, which would require an even more massive refactoring to be useful. In fact, that particular proposal would still require to pass down an explicit location, because it does not actually add locations to constants, but stores their location together with the assignment expression (and the assignment expression is not passed down to the point of warning, only the without-location constant).
[Bug middle-end/55001] Handle VEC_COND_EXPR in tree-vect-generic.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55001
--- Comment #2 from Marc Glisse glisse at gcc dot gnu.org 2012-11-01 23:39:48
UTC ---
Author: glisse
Date: Thu Nov 1 23:39:44 2012
New Revision: 193077
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193077
Log:
2012-11-01 Marc Glisse marc.gli...@inria.fr
PR middle-end/55001
gcc/
* tree-vect-generic.c (expand_vector_condition): New function.
(expand_vector_operations_1): Call it.
testsuite/
* g++.dg/ext/vector19.C: Remove target restrictions.
* gcc.dg/fold-compare-7.c: New testcase.
Added:
trunk/gcc/testsuite/gcc.dg/fold-compare-7.c (with props)
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/ext/vector19.C
trunk/gcc/tree-vect-generic.c
Propchange: trunk/gcc/testsuite/gcc.dg/fold-compare-7.c
('svn:eol-style' added)
Propchange: trunk/gcc/testsuite/gcc.dg/fold-compare-7.c
('svn:keywords' added)
[Bug middle-end/55001] Handle VEC_COND_EXPR better in tree-vect-generic.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55001 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Summary|Handle VEC_COND_EXPR in |Handle VEC_COND_EXPR better |tree-vect-generic.c |in tree-vect-generic.c --- Comment #3 from Marc Glisse glisse at gcc dot gnu.org 2012-11-01 23:43:38 UTC --- When vcond is not handled for large vector types, the code goes straight to scalars. It should first try small vectors, as is done for other operations.
[Bug rtl-optimization/44194] struct returned by value generates useless stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194 --- Comment #50 from eraman at gcc dot gnu.org 2012-11-02 00:28:45 UTC --- Author: eraman Date: Fri Nov 2 00:28:40 2012 New Revision: 193085 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193085 Log: Backport 191302 and 192651 from trunk: 2012-09-14 Eric Botcazou ebotca...@adacore.com PR rtl-optimization/44194 * calls.c (expand_call): In the PARALLEL case, copy the return value into pseudos instead of spilling it onto the stack. * emit-rtl.c (adjust_address_1): Rename ADJUST into ADJUST_ADDRESS and add new ADJUST_OBJECT parameter. If ADJUST_OBJECT is set, drop the underlying object if it cannot be proved that the adjusted memory access is still within its bounds. (adjust_automodify_address_1): Adjust call to adjust_address_1. (widen_memory_access): Likewise. * expmed.c (store_bit_field_1): Call adjust_bitfield_address instead of adjust_address. Do not drop the underlying object of a MEM. (store_fixed_bit_field): Likewise. (extract_bit_field_1): Likewise. Fix oversight in recursion. (extract_fixed_bit_field): Likewise. * expr.h (adjust_address_1): Adjust prototype. (adjust_address): Adjust call to adjust_address_1. (adjust_address_nv): Likewise. (adjust_bitfield_address): New macro. (adjust_bitfield_address_nv): Likewise. * expr.c (expand_assignment): Handle a PARALLEL in more cases. (store_expr): Likewise. (store_field): Likewise. * dse.c: Fix typos in the head comment. 2012-10-21 Eric Botcazou ebotca...@adacore.com PR rtl-optimization/44194 * calls.c (expand_call): Allow sibling calls in the PARALLEL case. gcc/testsuite/ChangeLog: 2012-09-14 Eric Botcazou ebotca...@adacore.com * gcc.dg/pr44194-1.c: Check that there are no memory accesses left. Modified: branches/google/gcc-4_7/gcc/ChangeLog.google-4_7 branches/google/gcc-4_7/gcc/calls.c branches/google/gcc-4_7/gcc/dse.c branches/google/gcc-4_7/gcc/emit-rtl.c branches/google/gcc-4_7/gcc/expmed.c branches/google/gcc-4_7/gcc/expr.c branches/google/gcc-4_7/gcc/expr.h branches/google/gcc-4_7/gcc/testsuite/ChangeLog.google-4_7 branches/google/gcc-4_7/gcc/testsuite/gcc.dg/pr44194-1.c
[Bug fortran/55174] New: internal compiler error: Segmentation fault with bad array reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55174 Bug #: 55174 Summary: internal compiler error: Segmentation fault with bad array reference Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: john.har...@vuw.ac.nz This 4-line Fortran program has an error at line 3, where array(*) is of course not permitted as an argument of a function. implicit none integer:: array(2)=(/42,666/) print *, size(array(*)) end Other compilers (g95, ifort) correctly diagnose the error but gfortran 4.8.0 gives an internal compiler error: Segmentation fault and asks me to tell you. My compile-time output follows. cayley[~/Jfh] % /local/scratch/gf/bin/gfortran -v trybadstar.f90 Driving: /local/scratch/gf/bin/gfortran -v trybadstar.f90 -l gfortran -l m -shared-libgcc Using built-in specs. COLLECT_GCC=/local/scratch/gf/bin/gfortran COLLECT_LTO_WRAPPER=/local/scratch/gf/libexec/gcc/i686-pc-linux-gnu/4.8.0/lto-wrapper Target: i686-pc-linux-gnu Configured with: /local/scratch/gcc-4.8-20120701/configure --prefix=/local/scratch/gf --enable-languages=c,fortran --disable-libada --with-local-prefix=/local/scratch --with-gmp=/local/scratch Thread model: posix gcc version 4.8.0 20120701 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=pentiumpro' /local/scratch/gf/libexec/gcc/i686-pc-linux-gnu/4.8.0/f951 trybadstar.f90 -quiet -dumpbase trybadstar.f90 -mtune=generic -march=pentiumpro -auxbase trybadstar -version -fintrinsic-modules-path /local/scratch/gf/lib/gcc/i686-pc-linux-gnu/4.8.0/finclude -o /tmp/cccgAIgM.s GNU Fortran (GCC) version 4.8.0 20120701 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.8.0 20120701 (experimental), GMP version 5.0.5, MPFR version 3.1.0, MPC version 0.9 warning: GMP header version 5.0.5 differs from library version 5.0.3. warning: MPFR header version 3.1.0 differs from library version 3.1.0-p3. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU Fortran (GCC) version 4.8.0 20120701 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.8.0 20120701 (experimental), GMP version 5.0.5, MPFR version 3.1.0, MPC version 0.9 warning: GMP header version 5.0.5 differs from library version 5.0.3. warning: MPFR header version 3.1.0 differs from library version 3.1.0-p3. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 f951: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. cayley[~/Jfh] %
[Bug libstdc++/52839] [4.7/4.8 Regression] double free or corruption running tr1/.../default_weaktoshared.exe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839 --- Comment #35 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-02 01:35:35 UTC --- I get the same randomish failure on MIPS64 (the Octeon 1 with 16 cores) with GCC 4.7. The patch listed below will not help me at all as the code is already using the __atomic_* functions. Was there another change to the libstdc++ code which fixes similar issue too?
[Bug libstdc++/52839] [4.7/4.8 Regression] double free or corruption running tr1/.../default_weaktoshared.exe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839 --- Comment #36 from Alan Modra amodra at gmail dot com 2012-11-02 02:13:20 UTC --- The change I mention in #c22 http://gcc.gnu.org/viewcvs?view=revisionrevision=184110 tests for atomic ops on all of bool, short, int and long long, where the previous test was for *either* atomic bool or atomic short. My fix for powerpc removed the long long test. Does mips lack atomic on bool or short?
[Bug libstdc++/52839] [4.7/4.8 Regression] double free or corruption running tr1/.../default_weaktoshared.exe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839 --- Comment #37 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-02 02:16:48 UTC --- (In reply to comment #36) The change I mention in #c22 http://gcc.gnu.org/viewcvs?view=revisionrevision=184110 tests for atomic ops on all of bool, short, int and long long, where the previous test was for *either* atomic bool or atomic short. My fix for powerpc removed the long long test. Does mips lack atomic on bool or short? No it does not lack atomic for either book or short. I am getting exactly the same failure as mentioned in #c3 and not the double free though.
[Bug libstdc++/52839] [4.7/4.8 Regression] double free or corruption running tr1/.../default_weaktoshared.exe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839 --- Comment #38 from Alan Modra amodra at gmail dot com 2012-11-02 02:39:29 UTC --- Ah, the #c3 fail on powerpc was due to a powerpc glibc pthread_once bug. And comment #36 should have read: ..previous test was for *either* atomic bool or atomic int.
[Bug libstdc++/52839] [4.7/4.8 Regression] double free or corruption running tr1/.../default_weaktoshared.exe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839 --- Comment #39 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-02 02:41:37 UTC --- (In reply to comment #38) Ah, the #c3 fail on powerpc was due to a powerpc glibc pthread_once bug. And comment #36 should have read: ..previous test was for *either* atomic bool or atomic int. Looks like the MIPS glibc pthread_once has the same issue too. I should have read the comments fully to see that.
[Bug fortran/55174] internal compiler error: Segmentation fault with bad array reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55174 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org 2012-11-02 02:57:36 UTC --- (In reply to comment #0) This 4-line Fortran program has an error at line 3, where array(*) is of course not permitted as an argument of a function. implicit none integer:: array(2)=(/42,666/) print *, size(array(*)) end Other compilers (g95, ifort) correctly diagnose the error but gfortran 4.8.0 gives an internal compiler error: Segmentation fault and asks me to tell you. My compile-time output follows. cayley[~/Jfh] % /local/scratch/gf/bin/gfortran -v trybadstar.f90 Driving: /local/scratch/gf/bin/gfortran -v trybadstar.f90 -l gfortran -l m -shared-libgcc Using built-in specs. COLLECT_GCC=/local/scratch/gf/bin/gfortran COLLECT_LTO_WRAPPER=/local/scratch/gf/libexec/gcc/i686-pc-linux-gnu/4.8.0/lto-wrapper Target: i686-pc-linux-gnu Configured with: /local/scratch/gcc-4.8-20120701/configure --prefix=/local/scratch/gf --enable-languages=c,fortran --disable-libada --with-local-prefix=/local/scratch --with-gmp=/local/scratch Thread model: posix gcc version 4.8.0 20120701 (experimental) (GCC) John, It looks like it has been fixed on trunk (aka 4.8.0). For me, gfc4x is 4.8.0 20121002. gfortran 4.5.x seems to also work, so it appears that a regression crept in in the 4.6. development. troutmask:sgk[209] gfc4x -o z k.f90 k.f90:2.20: print *, size(array(*)) 1 Error: Expected array subscript at (1) troutmask:sgk[210] gfc47 -o z k.f90 f951: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. troutmask:sgk[211] gfc46 -o z k.f90 f951: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. troutmask:sgk[212] gfc45 -o z k.f90 k.f90:2.20: print *, size(array(*)) 1 Error: Expected array subscript at (1) A quick scan of gcc/fortran/ChangeLog did not reveal an obvious candidate for the revision that fixed the problem. We should probably add your test to the testsuite to make sure it does not get broken, again.
[Bug tree-optimization/55162] Loop ivopts cuts off top bits of loop counter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55162 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-02 04:08:25 UTC --- For example, passing a virtual address 0x1000 and c = 0x8000 to the function should actually run over the address range 0x1000 .. 0x80001000, No it runs over the address range 0x1000 .. -1 and more as 0x8000 * 4 wraps/overflows. If x was char* then I would say there is a bug but this is int* which has a size of 4.
[Bug bootstrap/55175] New: i386/sfp-exceptions.c:52:7: error: impossible constraint in 'asm'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55175
Bug #: 55175
Summary: i386/sfp-exceptions.c:52:7: error: impossible
constraint in 'asm'
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: corse...@gcc.gnu.org
Created attachment 28594
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28594
*.i of the file raising the breakdown
Bootstrapping gcc-trunk (xgcc (GCC) 4.8.0 20120927 (experimental)) fails with
this error for --target=i386-rtems4.11:
...
/users/rtems/src/rtems.org/rtems-gcc/BUILD-i386/./gcc/xgcc
-B/users/rtems/src/rtems.org/rtems-gcc/BUILD-i386/./gcc/ -nostdinc
-B/users/rtems/src/rtems.org/rtems-gcc/BUILD-i386/i386-rtems4.11/soft-float/newlib/
-isystem
/users/rtems/src/rtems.org/rtems-gcc/BUILD-i386/i386-rtems4.11/soft-float/newlib/targ-include
-isystem /users/rtems/src/rtems.org/rtems-gcc/newlib/libc/include
-B/opt/rtems-4.11/i386-rtems4.11/bin/ -B/opt/rtems-4.11/i386-rtems4.11/lib/
-isystem /opt/rtems-4.11/i386-rtems4.11/include -isystem
/opt/rtems-4.11/i386-rtems4.11/sys-include -msoft-float -g -O2 -Wall -O2
-I../../../../libgcc/../newlib/libc/sys/rtems/include -g -O2 -Wall -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-isystem ./include -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector
-Dinhibit_libc -I. -I. -I../../.././gcc -I../../../../libgcc
-I../../../../libgcc/. -I../../../../libgcc/../gcc
-I../../../../libgcc/../include -DHAVE_CC_TLS -o sfp-exceptions.o -MT
sfp-exceptions.o -MD -MP -MF sfp-exceptions.dep -c
../../../../libgcc/config/i386/sfp-exceptions.c -fvisibility=hidden
-DHIDE_EXPORTS
../../../../libgcc/config/i386/sfp-exceptions.c: In function
'__sfp_handle_exceptions':
../../../../libgcc/config/i386/sfp-exceptions.c:52:7: error: impossible
constraint in 'asm'
asm volatile (fdiv\t{%y0, %0|%0, %y0} : +t (f));
^
../../../../libgcc/config/i386/sfp-exceptions.c:62:7: error: impossible
constraint in 'asm'
asm volatile (fdivs\t%1 : +t (f) : m (g));
^
make: *** [sfp-exceptions.o] Error 1
[Bug regression/55167] [4.8 Regression]: g++.dg/other/vector-compare.C, ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55167 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Depends on||55001 --- Comment #4 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-11-02 05:34:06 UTC --- I made this PR depend on PR55001, which has a committed patch that solves the regression in this PR. So, looks like a dup, for some definition thereof.
