[Bug objc++/48275] getter=namespace failing with .mm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48275 --- Comment #4 from Nicola Pero 2011-10-15 08:04:39 UTC --- Author: nicola Date: Sat Oct 15 08:04:33 2011 New Revision: 180023 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180023 Log: In gcc/cp/: 2011-10-15 Nicola Pero Backport from mainline 2011-06-06 Nicola Pero , PR obj-c++/48275 * parser.c (cp_parser_objc_at_property_declaration): Allow setter and getter names to use all the allowed method names. In gcc/testsuite/: 2011-10-15 Nicola Pero Backport from mainline 2011-06-06 Nicola Pero PR objc-++/48275 * obj-c++.dg/property/cxx-property-1.mm: New. * obj-c++.dg/property/cxx-property-2.mm: New. Added: branches/gcc-4_6-branch/gcc/testsuite/obj-c++.dg/property/cxx-property-1.mm branches/gcc-4_6-branch/gcc/testsuite/obj-c++.dg/property/cxx-property-2.mm Modified: branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/parser.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug objc++/48275] getter=namespace failing with .mm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48275 Nicola Pero changed: What|Removed |Added Target Milestone|--- |4.6.2
[Bug tree-optimization/50735] [4.7 Regression] gcc.dg/torture/vector-2.c:52:1: ICE: verify_ssa failed at -O1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50735 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-10-15 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2011-10-15 08:44:51 UTC --- Maybe caused by the addressable changes. Clearly the IL is invalid because we have a partial def of an SSA name.
[Bug middle-end/50640] [4.7 Regression] FAIL: gfortran.dg/select_type_12.f03 -O (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50640 Hans-Peter Nilsson changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-10-15 Ever Confirmed|0 |1 --- Comment #8 from Hans-Peter Nilsson 2011-10-15 08:47:07 UTC --- Still there, so I'll confirm it; cris-elf at r180014 too, introduced r179598:179611.
[Bug rtl-optimization/38644] [4.4/4.5/4.6/4.7 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644 --- Comment #52 from Sebastian Huber 2011-10-15 08:48:10 UTC --- In GCC 4.6.2 20111014 (prerelease) the problem is still not fixed and "arm-eabi-gcc -march=armv5t -mthumb -O2" produces wrong code. Please don't let it slip through the next release.
[Bug middle-end/50724] isnan broken by -ffinite-math-only in g++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50724 Richard Guenther changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Comment #12 from Richard Guenther 2011-10-15 08:50:56 UTC --- (In reply to comment #11) > Marc: is this code perusable? I'm curious because I expect either the > calculations may generate NaN or not at all. If they might and you even have > test cases to handle it, then I'm surprised you would ever want to support > running with -ff-m-o. Conversely if you knew the code doesn't generate the > nonfinite values, then you don't need the classifications in the first > place...? > > I'm guessing (and apologies if this is inaccurate) that this might boil down > to > saying that you want to interpret an end user setting -ff-m-o as an > opportunity > to skip validating their input or skip doing assertions during its processing, > which could be a reasonable thing to do, but that's a choice I'd rather leave > to individual developers, e.g. can also wrap code with #if > __FINITE_MATH_ONLY__==0 or such... > > Or in other words, it's only a missed optimization if you wind up with > classification calls, whereas it's a full-fledged execution error when NaN > gets > past validation. You can switch between explicit checking and trapping for example, by switching between -ffinite-math-only and -fno-trapping-math. Note that in general it is impossible to decide whether an argument of isnan() is from user input or previous computation. Which means that making isnan() special for -ffinite-math-only makes as much sense as special-casing any math library function (that may also take user input). This has been discussed to death already, and the present behavior is how GCC behaved since ever. It's not a bug. The documentation states "Allow optimizations for floating-point arithmetic that assume that arguments and results are not NaNs or +-Infs." it is clear that isnan(x) may then be optimized assuming that x is not NaN.
[Bug c++/50734] const and pure attributes don't have the effect as in C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50734 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #1 from Richard Guenther 2011-10-15 08:54:32 UTC --- This is because f can throw, you need to mark it nothrow as well in C++. Whether something throws or accesses global memory is orthogonal. Works with -fno-exceptions.
[Bug rtl-optimization/50728] Inefficient vector loads from aggregates passed by value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50728
--- Comment #4 from Richard Guenther 2011-10-15
08:57:27 UTC ---
(In reply to comment #3)
> The problem is that the ABI was designed with the scalar operations
> in mind, rather than possible vectorization. If you consider an
> alternate function
>
> A foo(A a, A b)
> {
> a.a[0] += b.a[0];
> a.a[1] -= b.a[1];
> a.a[2] *= b.a[2];
> a.a[3] /= b.a[3];
> return a;
> }
>
> then the way the ABI passes the floats *is* optimal. I.e. already
> unpacked in the registers, ready for use in their scalar operations.
Actually they are passed in pairs, not exactly ready for computation
(they are for doubles, but not for floats due to the 8-byte packing).
> What you're asking for is a special private ABI for "sum", with the
> knowledge that the inputs are used, packed in their vectors.
Actually I ask for the compiler to optimize the stack store/load
sequence into register moves using movhps ...
> Given that you can achieve the parameter register assignment that
> you want via passing the proper vector type, this seems to be a
> simple matter of function cloning/versioning:
>
> V4SF sum.vector(V4SF a, V4SF b)
> {
> return a + b;
> }
>
> user_of_sum()
> {
> ...
> V4SF r.v = sum.vector(VIEW_CONVERT, VIEW_CONVERT);
> A r = VIEW_CONVERT;
> ...
> }
>
> Of course, I've no idea how you're going to decide when to produce
> this particular clone. That seems like a fairly hard decision to make,
> given the relative placements of the vectorization passes and the
> IPA passes.
Yeah, that's going to be difficult.
[Bug middle-end/50731] [4.7 Regression] FAIL: gcc.dg/torture/vector-shift2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50731 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-10-15 Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther 2011-10-15 08:58:20 UTC --- Confirmed.
[Bug middle-end/50724] isnan broken by -ffinite-math-only in g++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50724 --- Comment #13 from Marc Glisse 2011-10-15 09:05:57 UTC --- (In reply to comment #11) > I'm guessing (and apologies if this is inaccurate) that this might boil down > to > saying that you want to interpret an end user setting -ff-m-o as an > opportunity > to skip validating their input or skip doing assertions during its processing, Yes, exactly. > which could be a reasonable thing to do, but that's a choice I'd rather leave > to individual developers, e.g. can also wrap code with #if > __FINITE_MATH_ONLY__==0 or such... Not very portable afaik. > Or in other words, it's only a missed optimization if you wind up with > classification calls, -ffinite-math-only exists for the sole purpose of allowing extra optimizations at the expanse of correctness if the contract is broken. > whereas it's a full-fledged execution error when NaN gets > past validation. A full-fledged user error to have used this flag ;-) Actually, I can understand why you'ld want to be able to write assert(!isnan(x)) and get a useful result. If on the other hand you want if(isnan(x))f();else g(); then g should be in a separate translation unit that can use -ffinite-math-only (and using LTO may require a lot of prayers in that case) or it could use the optimize attribute/pragma. This could work for the assertion as well: have a validate_input function compiled without the flag. I am not sure if it is possible to have it both ways: be able to validate the input and still be able to optimize headers.
[Bug middle-end/50640] [4.7 Regression] FAIL: gfortran.dg/select_type_12.f03 -O (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50640 --- Comment #9 from janus at gcc dot gnu.org 2011-10-15 09:13:02 UTC --- (In reply to comment #5) > (In reply to comment #4) > > Or another solution: should the fortran frontend perhaps put all these > > variables not in MAINs scope (where they aren't referenced anyway), but > > rather into file scope? That last solution would probably be the sanest. > > Looks sensible. Janus & Paul, What do you think? Yes, I think that would be ok. The 'vtab' symbols are really meant to be global. (Sorry for the late answer. I almost forgot about this one.)
[Bug c++/50736] New: ISO_IEC_14882-2011-5.1.2/10 - bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50736
Bug #: 50736
Summary: ISO_IEC_14882-2011-5.1.2/10 - bug
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: i.nix...@gmail.com
Quote from ISO_IEC_14882-2011, 5.1.2/10:
> The identifiers in a capture-list are looked up using
> the usual rules for unqualified name lookup (3.4.1); each
> such lookup shall find a variable with automatic
> storage duration declared in the reaching scope of the local
> lambda expression. An entity (i.e. a variable or this) is
> said to be explicitly captured if it appears in the
> lambda-expression’s capture-list.
But this code successfuly compiled on gcc-4.6.1:
#include
int main() {
using std::cout;
auto f = [&cout]() { cout << 1; }; // <<
f();
}
http://liveworkspace.org/code/ae698b7daf7b5b531beafd9faaa6a409
Intel C++ 12.1 says: error : a variable with static storage
duration cannot be captured in a lambda
niXman.
[Bug target/50737] New: FAIL: Throw_3 -O3 execution, generic dwarf2 EH problem?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50737
Bug #: 50737
Summary: FAIL: Throw_3 -O3 execution, generic dwarf2 EH
problem?
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ubiz...@gmail.com
Target: dwarf2 EH targets (alphaev68-pc-linux-gnu)
This problem shows on alphaev68-pc-linux-gnu as "FAIL: Throw_3 -O3 execution -
source compiled test" in [1], but I believe that it points to generic problem
in dwarf2 EH handling. It was uncovered by changing alpha target to use .cfi
directives.
After java test throws an exception (through libjava/exception.cc), it calls
_Unwind_RaiseException from _Jv_Throw. However, one of the functions in unwind
chain, just before target function is defined as:
$_ZN7Throw_33fooEJiP6JArrayIiE..ng:
_ZN7Throw_33fooEJiP6JArrayIiE:
.eflag 48
.frame $30,0,$26,0
$LFB3:
.loc 1 38 0
.cfi_startproc
.prologue 0
$LVL2:
$LBB3:
.loc 1 38 0
ldl $0,8($17)
$LVL3:
.loc 1 39 0
addl $0,$0,$0
$LVL4:
addl $31,$0,$0
$LBE3:
ret $31,($26),1
.cfi_endproc
$LFE3:
This results in "empty" FDE:
0030 0010 0034 FDE cie= pc=0030..0040
DW_CFA_nop
DW_CFA_nop
DW_CFA_nop
The target function:
_ZN7Throw_34mainEJvP6JArrayIPN4java4lang6StringEE:
.eflag 48
.frame $30,48,$26,0
.mask 0x4001e00,-48
$LFB1:
.loc 1 7 0
.cfi_startproc
.cfi_personality 0x9b,DW.ref.__gcj_personality_v0
.cfi_lsda 0x1b,$LLSDA1
$LEHB0:
ldah $29,0($27) !gpdisp!8
lda $29,0($29) !gpdisp!8
$_ZN7Throw_34mainEJvP6JArrayIPN4java4lang6StringEE..ng:
lda $30,-48($30)
$LCFI4:
.cfi_def_cfa_offset 48
defines correct .cfi_personality.
Tracing the unwinder through libbgcc/unwin.inc, _Unwind_RaiseException shows:
(gdb) p cur_context
$29 = {reg = {0x11ff10e60, 0x11ff10e68, 0x11ff10e70, 0x11ff10e78, 0x11ff10e80,
0x11ff10e88, 0x11ff10e90, 0x11ff10e98, 0x11ff10ea0, 0x11ff10ea8,
0x11ff10eb0, 0x11ff10eb8, 0x11ff10ec0, 0x11ff10ec8, 0x11ff10ed0,
0x11ff10ed8, 0x11ff10ee0, 0x11ff10ee8, 0x11ff10ef0, 0x11ff10ef8,
0x11ff10f00, 0x11ff10f08, 0x11ff10f10, 0x11ff10f18, 0x11ff10f20,
0x11ff10f28, 0x11ff10f30, 0x11ff10f38, 0x11ff10f40, 0x11ff10f48, 0x0, 0x0,
0x11ff10f68, 0x11ff10f70, 0x11ff10f78, 0x11ff10f80, 0x11ff10f88,
0x11ff10f90, 0x11ff10f98, 0x11ff10fa0, 0x11ff10fa8, 0x11ff10fb0,
0x11ff10fb8, 0x11ff10fc0, 0x11ff10fc8, 0x11ff10fd0, 0x11ff10fd8,
0x11ff10fe0, 0x11ff10fe8, 0x11ff10ff0, 0x11ff10ff8, 0x11ff11000,
0x11ff11008, 0x11ff11010, 0x11ff11018, 0x11ff11020, 0x11ff11028,
0x11ff11030, 0x11ff11038, 0x11ff11040, 0x11ff11048, 0x11ff11050,
0x11ff11058, 0x0, 0x11ff10e50}, cfa = 0x11ff110e0, ra = 0x129d4,
lsda = 0x0, bases = {tbase = 0x0, dbase = 0x0, func = 0x2000189fc90},
flags = 4611686018427387904, version = 0, args_size = 0,
by_value = '\000' }
(gdb) p cur_context
$30 = {reg = {0x11ff10e60, 0x11ff10e68, 0x11ff10e70, 0x11ff10e78, 0x11ff10e80,
0x11ff10e88, 0x11ff10e90, 0x11ff10e98, 0x11ff10ea0, 0x11ff10ea8,
0x11ff10eb0, 0x11ff10eb8, 0x11ff10ec0, 0x11ff10ec8, 0x11ff10ed0,
0x11ff10ed8, 0x11ff10ee0, 0x11ff10ee8, 0x11ff10ef0, 0x11ff10ef8,
0x11ff10f00, 0x11ff10f08, 0x11ff10f10, 0x11ff10f18, 0x11ff10f20,
0x11ff10f28, 0x11ff10f30, 0x11ff10f38, 0x11ff10f40, 0x11ff10f48, 0x0, 0x0,
0x11ff10f68, 0x11ff10f70, 0x11ff10f78, 0x11ff10f80, 0x11ff10f88,
0x11ff10f90, 0x11ff10f98, 0x11ff10fa0, 0x11ff10fa8, 0x11ff10fb0,
0x11ff10fb8, 0x11ff10fc0, 0x11ff10fc8, 0x11ff10fd0, 0x11ff10fd8,
0x11ff10fe0, 0x11ff10fe8, 0x11ff10ff0, 0x11ff10ff8, 0x11ff11000,
0x11ff11008, 0x11ff11010, 0x11ff11018, 0x11ff11020, 0x11ff11028,
0x11ff11030, 0x11ff11038, 0x11ff11040, 0x11ff11048, 0x11ff11050,
0x11ff11058, 0x0, 0x11ff10e50}, cfa = 0x11ff110e0, ra = 0x12af4,
lsda = 0x0, bases = {tbase = 0x0, dbase = 0x0, func = 0x129d0},
flags = 4611686018427387904, version = 0, args_size = 0,
by_value = '\000' }
where cfa of the former context shows "cfa = 0x11ff110e0" that is equal to cfa
from the later context. The return address (ra) from the former points to:
000129d0 <_ZN7Throw_33fooEJiP6JArrayIiE>:
129d0:08 00 11 a0 ldlv0,8(a1)
129d4:00 00 00 40 addlv0,v0,v0
129d8:00 00 e0 43 sextlv0,v0
129dc:01 80 fa 6b ret
and the return address of the later context points to:
00012a64 <_ZN7Throw_34mainEJvP6JArrayIPN4java4lang6StringEE>:
12a64:02 00 bb 27 ldahgp,2(t12)
12a68:2c 8d bd 23 ldagp,-29396(gp)
12a6c:d0 ff de 23 ldasp,-48(sp)
...
12af0
[Bug target/50737] FAIL: Throw_3 -O3 execution, generic dwarf2 EH problem?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50737 --- Comment #1 from Uros Bizjak 2011-10-15 10:11:44 UTC --- Created attachment 25506 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25506 Assembly dump of Throw_3.java
[Bug target/50737] FAIL: Throw_3 -O3 execution, generic dwarf2 EH problem?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50737 --- Comment #2 from Uros Bizjak 2011-10-15 10:13:04 UTC --- Created attachment 25507 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25507 Object dump of text section of Throw_3.java
[Bug target/50737] FAIL: Throw_3 -O3 execution, generic dwarf2 EH problem?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50737 --- Comment #3 from Uros Bizjak 2011-10-15 10:18:48 UTC --- Created attachment 25508 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25508 Dwarf2 frames of Throw_3.java
[Bug rtl-optimization/49941] [4.7 Regression] segmentation fault in redirect_jump_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49941 --- Comment #10 from Alan Modra 2011-10-15 10:32:36 UTC --- Author: amodra Date: Sat Oct 15 10:32:33 2011 New Revision: 180027 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180027 Log: PR rtl-optimization/49941 * jump.c (mark_jump_label_1): Set JUMP_LABEL for simple_return jumps. * rtl.h (set_return_jump_label): Declare. * function.c (set_return_jump_label): New function, extracted.. (thread_prologue_and_epilogue_insns): ..from here. Use it in another instance to set return jump_label. * cfgrtl.c (force_nonfallthru_and_redirect): Use set_return_jump_label. * reorg.c (find_end_label): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgrtl.c trunk/gcc/function.c trunk/gcc/jump.c trunk/gcc/reorg.c trunk/gcc/rtl.h
[Bug tree-optimization/50735] [4.7 Regression] gcc.dg/torture/vector-2.c:52:1: ICE: verify_ssa failed at -O1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50735
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org
|gnu.org |
--- Comment #2 from Jakub Jelinek 2011-10-15
10:48:12 UTC ---
Created attachment 25509
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25509
gcc47-pr50735.patch
Untested fix. Alternatively we could do:
/* If PARM was addressable, move that flag over
to the local copy, as its address will be taken,
not the PARMs. Keep the parms address taken
as we'll query that flag during gimplification. */
if (TREE_ADDRESSABLE (parm))
{
local = create_tmp_var (type, get_name (parm));
TREE_ADDRESSABLE (local) = 1;
}
else
local = create_tmp_reg (type, get_name (parm));
DECL_IGNORED_P (local) = 0;
[Bug target/50737] FAIL: Throw_3 -O3 execution, generic dwarf2 EH problem?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50737 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot ||gnu.org --- Comment #4 from Eric Botcazou 2011-10-15 10:57:57 UTC --- > IMO, this points to a bug in generic dwarf2 exception handling, in how context > is identified. For illustration, I will attach asm dump, object dump and > corresponding .eh_frame --dwarf dump of Throw_3.java. This is an old debate. This was changed by Geoff in 2007: http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01252.html The problematic function is leaf though; how come it appears in the unwind chain? Does it raise a signal? If so, there may be a missing _Unwind_IsSignalFrame bit.
[Bug target/50737] FAIL: Throw_3 -O3 execution, generic dwarf2 EH problem?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50737 --- Comment #5 from Uros Bizjak 2011-10-15 11:11:51 UTC --- (In reply to comment #4) > > IMO, this points to a bug in generic dwarf2 exception handling, in how > > context > > is identified. For illustration, I will attach asm dump, object dump and > > corresponding .eh_frame --dwarf dump of Throw_3.java. > > This is an old debate. This was changed by Geoff in 2007: > http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01252.html > > The problematic function is leaf though; how come it appears in the unwind > chain? > Does it raise a signal? If so, there may be a missing _Unwind_IsSignalFrame > bit. I hope that RTH can provide this answer, this is a bit uncharted territory to me.
[Bug target/50737] FAIL: Throw_3 -O3 execution, generic dwarf2 EH problem?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50737 --- Comment #6 from Uros Bizjak 2011-10-15 11:23:54 UTC --- (In reply to comment #5) > I hope that RTH can provide this answer, this is a bit uncharted territory to > me. ... but looking at Dwarf2 frames dump, there is no "S" in any of the CIE augmentation data.
[Bug bootstrap/50738] New: [4.7 Regression] Bootstrap failure at revision 180028 on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50738 Bug #: 50738 Summary: [4.7 Regression] Bootstrap failure at revision 180028 on powerpc-apple-darwin9 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: amo...@gmail.com, ia...@gcc.gnu.org Host: powerpc-apple-darwin9 Target: powerpc-apple-darwin9 Build: powerpc-apple-darwin9 On powerpc-apple-darwin9 at revision 180029, bootstrap fails with: gcc -c -O0 -g -fexceptions -mmacosx-version-min=10.4 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -I. -I../../work/gcc -I../../work/gcc/. -I../../work/gcc/../include -I../../work/gcc/../libcpp/include -I/sw/include -I../../work/gcc/../libdecnumber -I../../work/gcc/../libdecnumber/dpd -I../libdecnumber -I/sw/include -DCLOOG_INT_GMP -DCLOOG_ORG ../../work/gcc/ifcvt.c -o ifcvt.o ../../work/gcc/ifcvt.c: In function 'dead_or_predicable': ../../work/gcc/ifcvt.c:4176: error: 'HAVE_simple_return' undeclared (first use in this function) ../../work/gcc/ifcvt.c:4176: error: (Each undeclared identifier is reported only once ../../work/gcc/ifcvt.c:4176: error: for each function it appears in.) This has been introduced by revision 180028 Author:amodra Date:Sat Oct 15 10:36:00 2011 UTC (65 minutes, 35 seconds ago) Changed paths:2 Log Message: * ifcvt.c (dead_or_predicable): Disable if-conversion when doing so is likely to kill a shrink-wrapping opportunity. I am now testing the new block protected by '#ifdef HAVE_simple_return' as done elsewhere.
[Bug fortran/50659] [4.4/4.5/4.6/4.7 Regression] [F03] ICE with PROCEDURE statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50659 --- Comment #15 from janus at gcc dot gnu.org 2011-10-15 12:16:22 UTC --- Author: janus Date: Sat Oct 15 12:16:13 2011 New Revision: 180032 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180032 Log: 2011-10-15 Janus Weil PR fortran/50659 * expr.c (replace_symbol): Only do replacement if the symbol is a dummy. 2011-10-15 Janus Weil PR fortran/50659 * gfortran.dg/proc_decl_27.f90: New. Added: branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/proc_decl_27.f90 Modified: branches/gcc-4_4-branch/gcc/fortran/ChangeLog branches/gcc-4_4-branch/gcc/fortran/expr.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
[Bug fortran/50659] [4.4/4.5/4.6/4.7 Regression] [F03] ICE with PROCEDURE statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50659 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #16 from janus at gcc dot gnu.org 2011-10-15 12:18:17 UTC --- The fix has landed on all branches from 4.4 on upwards, so we can finally close this one.
[Bug libstdc++/49894] [C++0x] Uniform initialization in constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49894 --- Comment #7 from Jonathan Wakely 2011-10-15 12:25:41 UTC --- Yeah, this pr inspired http://gcc.gnu.org/ml/libstdc++/2011-10/msg00016.html
[Bug rtl-optimization/50496] [4.7 regression] ICE in redirect_jump, at jump.c:1497
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50496 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-10-15 CC||ebotcazou at gcc dot ||gnu.org Component|middle-end |rtl-optimization Ever Confirmed|0 |1 --- Comment #6 from Eric Botcazou 2011-10-15 12:51:30 UTC --- I can reproduce.
[Bug libstdc++/49894] [C++0x] Uniform initialization in constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49894 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |redi at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.0 --- Comment #8 from Jonathan Wakely 2011-10-15 12:53:47 UTC --- I'll deal with this after PR 50196
[Bug libstdc++/50196] [C++0x] std::thread not available under macos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50196 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug rtl-optimization/50496] [4.7 regression] ICE in redirect_jump, at jump.c:1497
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50496 Markus Trippelsdorf changed: What|Removed |Added CC||cltang at gcc dot gnu.org --- Comment #7 from Markus Trippelsdorf 2011-10-15 12:58:01 UTC --- Chung-Lin told me in a private mail, that he'll handle this when he finds time.
[Bug target/49910] "internal compiler error: in redirect_jump, at jump.c:1485" when build ppl-0.11.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49910 niXman changed: What|Removed |Added Severity|normal |critical
[Bug fortran/50570] [4.6/4.7 Regression] Incorrect error for assignment to intent(in) pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50570 --- Comment #14 from janus at gcc dot gnu.org 2011-10-15 13:30:13 UTC --- Author: janus Date: Sat Oct 15 13:30:07 2011 New Revision: 180037 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180037 Log: 2011-10-15 Janus Weil PR fortran/50570 * expr.c (gfc_check_vardef_context): Don't throw an error on non-pointer assignments involving an intent(in) pointer dummy. 2011-10-15 Janus Weil PR fortran/50570 * gfortran.dg/pointer_intent_5.f90: New. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/pointer_intent_5.f90 Modified: branches/gcc-4_6-branch/gcc/fortran/ChangeLog branches/gcc-4_6-branch/gcc/fortran/expr.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug fortran/50570] [4.6/4.7 Regression] Incorrect error for assignment to intent(in) pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50570 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #15 from janus at gcc dot gnu.org 2011-10-15 13:31:51 UTC --- Fixed on 4.6 and trunk. Closing. Thanks for the report!
[Bug bootstrap/50738] [4.7 Regression] Bootstrap failure at revision 180028 on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50738 --- Comment #1 from Alan Modra 2011-10-15 13:40:02 UTC --- Author: amodra Date: Sat Oct 15 13:39:58 2011 New Revision: 180038 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180038 Log: PR bootstrap/50738 * ifcvt.c (dead_or_predicable): Revert accidental commit with HAVE_simple_return test. Modified: trunk/gcc/ChangeLog trunk/gcc/ifcvt.c
[Bug tree-optimization/50698] pretending to create versioning for alias when not required
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50698
--- Comment #6 from vincenzo Innocente
2011-10-15 13:40:31 UTC ---
I now moved to a more realistic case that can be reduced to this:
void loop(float * x, int n) {
for (int i=0;i!=n; ++i)
x[i]=x[i+n]+x[i+2*n];
}
and it creates aliases even if the memory region are clearly disjoint:
(used gcc version 4.7.0 20111015 (experimental) (GCC) )
keep here or open an other "enhancement request"?
2: versioning for alias required: can't determine dependence between *D.2199_12
and *D.2195_8
2: mark for run-time aliasing test between *D.2199_12 and *D.2195_8
2: versioning for alias required: can't determine dependence between *D.2205_18
and *D.2195_8
2: mark for run-time aliasing test between *D.2205_18 and *D.2195_8
2: Vectorizing an unaligned access.
2: Vectorizing an unaligned access.
2: Vectorizing an unaligned access.
2: vect_model_load_cost: unaligned supported by hardware.
2: vect_model_load_cost: inside_cost = 2, outside_cost = 0 .
2: vect_model_load_cost: unaligned supported by hardware.
2: vect_model_load_cost: inside_cost = 2, outside_cost = 0 .
2: vect_model_simple_cost: inside_cost = 1, outside_cost = 0 .
2: vect_model_store_cost: unaligned supported by hardware.
2: vect_model_store_cost: inside_cost = 2, outside_cost = 0 .
2: cost model: Adding cost of checks for loop versioning aliasing.
2: cost model: epilogue peel iters set to vf/2 because loop iterations are
unknown .
2: Cost model analysis:
Vector inside of loop cost: 7
Vector outside of loop cost: 19
Scalar iteration cost: 4
Scalar outside cost: 1
prologue iterations: 0
epilogue iterations: 2
Calculated minimum iters for profitability: 7
2: Profitability threshold = 6
Vectorizing loop at Arena.cpp:2
2: Profitability threshold is 6 loop iterations.
2: create runtime check for data references *D.2199_12 and *D.2195_8
2: create runtime check for data references *D.2205_18 and *D.2195_8
2: created 2 versioning for alias checks.
2: LOOP VECTORIZED.
Arena.cpp:1: note: vectorized 1 loops in function.
[Bug bootstrap/50738] [4.7 Regression] Bootstrap failure at revision 180028 on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50738 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Alan Modra 2011-10-15 13:41:00 UTC --- Oops, sorry, I didn't mean to commit the HAVE_simple_return test (which is a change from my posted patch).
[Bug middle-end/50724] isnan broken by -ffinite-math-only in g++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50724
Ethan Tira-Thompson changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID |
--- Comment #14 from Ethan Tira-Thompson 2011-10-15
14:01:11 UTC ---
Richard said:
> The documentation states
> "Allow optimizations for floating-point arithmetic that
> assume that arguments and results are not NaNs or +-Infs."
Yes, that's my argument as well. Note ARITHMETIC. Also note MATH in the name
of both --finite-MATH-only, and -ffast-MATH it falls under. And it doesn't
reference the 'math library' to qualify that.
Basically, if you want to close on this point, I want to see you explicitly
argue why the classification functions should be considered arithmetic.
I'm going to nail this down and list there are 5 classification functions
(fpclassify, infinite, isinf, isnan, isnormal) and the vast majority of the
other library functions are obviously proper arithmetic operations. The ones
that aren't (signbit, copysign, nextafter, nan), you're exactly right that we
should carefully consider the result of NaN optimization ("special cases").
You don't have to do this if *you* don't want to, but it should be done and it
sounds like no one has.
> This has been discussed to death already, and the present behavior is how
> GCC behaved since ever.
Except also NOT TRUE. It currently doesn't behave this way with math.h. It
didn't behave this way in 4.1 (Fedora) or 4.2 (Apple). I only got screwed by
this by the CHANGE in behavior on upgrading to 4.4. (Not sure about 4.3). I
already presented this in the original post at the top (except the Apple test
is a new data point; FYI Apple gcc math.h also 'works', so either 4.2 was
generally consistent or Apple likes to patch theirs for consistency)
This is further evidence gcc has not had a good policy discussion of where NaN
optimizations should be applied, because the implementation keeps changing, and
it's not even consistent between math.h and cmath within any given version
other than 4.2-Apple.
Marc said:
>> __FINITE_MATH_ONLY__
> Not very portable afaik.
Neither is -ffast-math, add a 'defined(__FINITE_MATH_ONLY__) &&' and it will be
applied opportunistically when available, or even better: the user can
-D__FINITE_MATH_ONLY__=1 themselves on non-gcc platforms and still get the
performance benefit you're looking for even without -ffast-math support, so
it's a double win. IMHO, on the other hand it's harder and more error prone to
override isnan with my own implementation.
[Bug target/50737] FAIL: Throw_3 -O3 execution, generic dwarf2 EH problem?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50737 --- Comment #7 from Eric Botcazou 2011-10-15 14:56:44 UTC --- > ... but looking at Dwarf2 frames dump, there is no "S" in any of the CIE > augmentation data. Try to add fs->signal_frame = 1; at the end of alpha_fallback_frame_state then.
[Bug c++/50734] const and pure attributes don't have the effect as in C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50734 --- Comment #2 from joseph at codesourcery dot com 2011-10-15 15:47:27 UTC --- On Sat, 15 Oct 2011, rguenth at gcc dot gnu.org wrote: > This is because f can throw, you need to mark it nothrow as well in C++. > Whether something throws or accesses global memory is orthogonal. > Works with -fno-exceptions. I don't see the difference here from C. In C, f might exit the program or call longjmp (if you allow such functions to throw, I'd have thought they could also not-return in other ways) - but if it does, the exit status, or where it longjmps do, will only depend on the global state visible to f, meaning that it will do so on the first time through the loop. The same reasoning that it's safe to hoist the call out of the loop in C - the loop is guaranteed to call f at least once with the same state as if it is called before the loop - should apply in C++; throwing from a hoisted call could not be distinguished by a catcher from throwing from the first call in the loop.
[Bug target/50737] FAIL: Throw_3 -O3 execution, generic dwarf2 EH problem?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50737 --- Comment #8 from Uros Bizjak 2011-10-15 16:35:16 UTC --- (In reply to comment #7) > > ... but looking at Dwarf2 frames dump, there is no "S" in any of the CIE > > augmentation data. > > Try to add > > fs->signal_frame = 1; > > at the end of alpha_fallback_frame_state then. Whoa, Throw_3 passes with following patch: Index: config/alpha/linux-unwind.h === --- config/alpha/linux-unwind.h(revision 179788) +++ config/alpha/linux-unwind.h(working copy) @@ -74,5 +74,7 @@ fs->regs.reg[64].how = REG_SAVED_OFFSET; fs->regs.reg[64].loc.offset = (long)&sc->sc_pc - new_cfa; fs->retaddr_column = 64; + fs->signal_frame = 1; + return _URC_NO_REASON; } I'm doing full bootstrap+regression test.
[Bug regression/49498] [4.7 Regression]: gcc.dg/uninit-pred-8_b.c bogus warning line 20
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49498
Kai Tietz changed:
What|Removed |Added
CC||ktietz at gcc dot gnu.org
--- Comment #13 from Kai Tietz 2011-10-15 17:10:11
UTC ---
This bug seems to be caused by vrp's jump-threading and branching into
different if-branch
For example this case gets expanded by vrp to:
int g;
void bar();
void blah(int);
int foo (int n, int l, int m, int r)
{
int v;
int v;
if ((n != 0) & (l != 0))
v = r;
if (m) g++;
else bar();
if ( n && l)
blah(v); /* { dg-bogus "uninitialized" "bogus warning" } */
if (l ) if ( n)
blah(v); /* { dg-bogus "uninitialized" "bogus warning" } */
return 0;
}
foo (int n, int l, int m, int r)
{
int v;
int g.3;
int g.2;
_Bool D.2766;
_Bool D.2765;
_Bool D.2764;
:
D.2764_3 = n_2(D) != 0;
D.2765_5 = l_4(D) != 0;
D.2766_6 = D.2764_3 & D.2765_5;
if (D.2766_6 != 0)
goto ;
else
goto ;
:
:
# v_1 = PHI
if (m_10(D) != 0)
goto ;
else
goto ;
:
g.2_11 = g;
g.3_12 = g.2_11 + 1;
g = g.3_12;
goto ;
:
bar ();
:
if (D.2766_6 != 0)
goto ;
else
goto ;
:
blah (v_1);
goto ;
:
if (l_4(D) != 0)
goto ;
else
goto ;
:
if (n_2(D) != 0)
goto ;
else
goto ;
:
blah (v_1);
:
return 0;
:
goto ;
}
Of interest is the insert goto at to via .
itself is the inner branch of the 'if (l ) if ( n)'. So 'if ( n)' has
two users, and so it gets warned, as it isn't clear to later check, that 's condition is for also true. IMHO vrp needs to learn that
should be the target of instead.
That -mbranch-costs shows for such cases some effect, is caused by
combining/not-combining if-conditions.
To solve this, we shouldn't make differences in AST about branching-costs high
or low. The tree-ssa-ifcombine pass should run before (and maybe after as now)
first vrp pass, and should try to merge if-s together as well. In one of the
last gimple-passes then we should actually apply to conditions the branching
rule and break-up conditions to their if-chains.
[Bug middle-end/50724] isnan broken by -ffinite-math-only in g++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50724 Andrew Pinski changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Comment #15 from Andrew Pinski 2011-10-15 18:00:10 UTC --- It has always been assumed that arithmetic includes isnan. isnan can be implemented as a macro defining to !(a==a) which then becomes an arithmetic.
[Bug middle-end/50598] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50598 --- Comment #4 from Dominique d'Humieres 2011-10-15 18:36:00 UTC --- The difference for the test libgomp.c++/pr24455.C comes from the companion file libgomp.c++/pr24455-1.C. With gcc/cgraphunit.c in revision 179429 reverted, pr24455-1.s is [macbook] f90/bug% cat pr24455-1_rev.s .globl ___emutls_v.i .data .align 5 ___emutls_v.i: .quad4 .quad4 .quad0 .quad0 .constructor .destructor .align 1 .subsections_via_symbols while for trunk it is [macbook] f90/bug% cat pr24455-1_orig.s .constructor .destructor .align 1 .subsections_via_symbols
[Bug target/50678] [4.7 Regression] FAIL: c52104y on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678 --- Comment #29 from Iain Sandoe 2011-10-15 19:33:25 UTC --- (In reply to comment #28) > > OK. well libgcc_s or libSystem contains the unwinder, depending on whether > > it's darwin9 or darwin10 (and assuming that there's no insertion caused by a > > DYLD_LIBRARY_PATH). I'll have to trawl through it in more detail. > > I'll try as well. so far, I added a little debugging code to init.c and looked at the params into __gnat_error_handler. AFAICT it looks perfectly sensible - and the "Right Thing" seems to happen with the stack area being recognized (for the probe) and the exception correctly chosen. The saved exception state seems OK (if one arranges to examine ucontext). however I've not got far through Raise_From_Signal_Handler () - if one continues from there it ends with a loop on x86-64/darwin9 and another segv on x86-64/darwin10. The thing that's itching slightly is that there is a syscall (in __gnat_error_handler ) to switch the signal stack - before the raise, and I wonder if the use of the alt sigstack is what's causing the problem. One would imagine that anything as radical as a missing reg. save/rest in eh would be spotted outside Ada ;-) I might try to cook up a simplified 'c' mimicry and see if that fails too. The generated eh_frame data is unchanged from O0-O2 .. ... the exception tables differ - but I guess that reflects code motion in the different optimizations.
[Bug c++/50732] [type_traits] is_base_of unnecessarily instantiates Base (which shouldn't be instantiated)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50732 --- Comment #2 from paolo at gcc dot gnu.org 2011-10-15 19:49:36 UTC --- Author: paolo Date: Sat Oct 15 19:49:33 2011 New Revision: 180048 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180048 Log: /cp 2011-10-15 Paolo Carlini PR c++/50732 * semantics.c (finish_trait_expr): Do not try to instantiate the the base type of an __is_base_of trait. (check_trait_type): Return a tree; use complete_type_or_else. /testsuite 2011-10-15 Paolo Carlini PR c++/50732 * g++.dg/ext/is_base_of_incomplete.C: New. * g++.dg/ext/is_base_of_diagnostic.C: Adjust dg-errors. * g++.dg/ext/unary_trait_incomplete.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/ext/is_base_of_incomplete.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/ext/is_base_of_diagnostic.C trunk/gcc/testsuite/g++.dg/ext/unary_trait_incomplete.C
[Bug c++/50732] [type_traits] is_base_of unnecessarily instantiates Base (which shouldn't be instantiated)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50732 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #3 from Paolo Carlini 2011-10-15 19:50:50 UTC --- Fixed.
[Bug libstdc++/49894] [C++0x] Uniform initialization in constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49894 Paolo Carlini changed: What|Removed |Added CC|jwakely.gcc at gmail dot| |com | --- Comment #9 from Paolo Carlini 2011-10-15 19:53:22 UTC --- Indeed. Thanks a lot!
[Bug target/50739] New: [avr] nameless error with -fmerge-all-constants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50739 Bug #: 50739 Summary: [avr] nameless error with -fmerge-all-constants Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@gcc.gnu.org CC: eric.wedding...@atmel.com Host: i386-mingw32 Target: avr Build: i686-linux-gnu With the source that will follow, I get the following error message (same without -da): $ avr-gcc -fmerge-all-constants -mmcu=atmega88 -S foo.c -da foo.c:18: confused by earlier errors, bailing out foo.s is printed but the output stops after printing __c.1229: .string"a" see following attachment. Trunk versions that show the problem: r179594, r179997. Configured with: ../../gcc.gnu.org/trunk/configure --target=avr --prefix=/local/gnu/install/gcc-4.7-pgm-mingw32 --host=i386-mingw32 --build=i686-linux-gnu --enable-languages=c,c++ --disable-nls --disable-shared --disable-lto --disable-checking --with-dwarf2 Thread model: single gcc version 4.7.0 20111014 (experimental) (GCC) GNU C (GCC) version 4.7.0 20111014 (experimental) (avr) compiled by GNU C version 3.4.5 (mingw-vista special r2), GMP version 5.0.1, MPFR version 3.0.0-p8, MPC version 0.8.2
[Bug target/50678] [4.7 Regression] FAIL: c52104y on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678 --- Comment #30 from Eric Botcazou 2011-10-15 20:49:03 UTC --- > however I've not got far through Raise_From_Signal_Handler () - if one > continues from there it ends with a loop on x86-64/darwin9 and another segv on > x86-64/darwin10. You need to compile with -fstack-check. Then you'll be able to debug the unwinding phase. Here are some possible breakpoints: 0x7fff85b7a260 in unw_init_local () from /usr/lib/libSystem.B.dylib (gdb) disass Dump of assembler code for function unw_init_local: Breakpoint 3, 0x7fff85b9fe32 in unwind_phase2 () from /usr/lib/libSystem.B.dylib (gdb) disass Dump of assembler code for function unwind_phase2: 0x7fff85ba0150 in libunwind::Registers_x86_64::jumpto() () from /usr/lib/libSystem.B.dylib (gdb) disass Dump of assembler code for function _ZN9libunwind16Registers_x86_646jumptoEv: => 0x7fff85ba0150 <+0>: mov0x38(%rdi),%rax The context from which jumpto restores the registers has the wrong %rbx line. > The thing that's itching slightly is that there is a syscall (in > __gnat_error_handler ) to switch the signal stack - before the raise, and I > wonder if the use of the alt sigstack is what's causing the problem. This call doesn't actually do anything. The stack is switched by the system before __gnat_error_handler is entered and all the processing is done using the alternate stack, until execution is resumed in the exception handler. > One would imagine that anything as radical as a missing reg. save/rest in eh > would be spotted outside Ada ;-) Java is the only other language that supports this kind of things though.
[Bug target/50739] [avr] nameless error with -fmerge-all-constants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50739 --- Comment #1 from Georg-Johann Lay 2011-10-15 20:50:21 UTC --- Created attachment 25510 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25510 foo.c
[Bug c++/50736] [C++0x] ISO_IEC_14882-2011-5.1.2/10 - bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50736 --- Comment #1 from Paolo Carlini 2011-10-15 20:50:58 UTC --- (of course no need to use to test this)
[Bug target/50739] [avr] nameless error with -fmerge-all-constants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50739 Georg-Johann Lay changed: What|Removed |Added Known to work||4.6.2 Target Milestone|--- |4.7.0
[Bug target/50739] [avr] nameless error with -fmerge-all-constants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50739 --- Comment #2 from Georg-Johann Lay 2011-10-15 20:51:50 UTC --- Created attachment 25511 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25511 foo.s
[Bug target/50739] [avr] nameless error with -fmerge-all-constants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50739 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-10-15 Ever Confirmed|0 |1
[Bug c++/38980] [4.4/4.5/4.6 Regression] missing -Wformat warning on const char format string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38980 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.4.7 |4.7.0 --- Comment #6 from Paolo Carlini 2011-10-15 20:54:43 UTC --- Fixed for 4.7.0, wontfix 4.4/4.5/4.6.
[Bug c++/50593] improve __attribute__((format(printf)))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50593 Paolo Carlini changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #3 from Paolo Carlini 2011-10-15 20:56:42 UTC --- PR38980 bits fixed for 4.7.0. Maybe Jason can have a look to the constexpr bits..
[Bug c++/50593] improve __attribute__((format(printf)))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50593 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-10-15 Ever Confirmed|0 |1
[Bug c++/50593] [C++0x] improve __attribute__((format(printf)))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50593 --- Comment #4 from Jason Merrill 2011-10-15 21:16:47 UTC --- Seems like it's a matter of changing check_format_arg to call a more general front-end interface than decl_constant_value, one that could accept an arbitrary expression rather than just a decl, and would call maybe_constant_value.
[Bug c++/42743] Inexplicable error message with constructing SIMD values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42743 Paolo Carlini changed: What|Removed |Added CC||jsm28 at gcc dot gnu.org --- Comment #2 from Paolo Carlini 2011-10-15 21:26:19 UTC --- The first part of this I also noticed some time ago (and mentioned in another PR): roughly speaking, __m128 doesn't seem default-constructible. Is there something we can do about that? Seems rather weird, naively.
[Bug tree-optimization/50717] [4.7 Regression] Silent code gen fault with incorrect widening of multiply
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50717 --- Comment #6 from Andrew Stubbs 2011-10-15 21:29:12 UTC --- Patch posted here: http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01397.html
[Bug c++/41847] warning: array subscript is above array bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41847 --- Comment #6 from Paolo Carlini 2011-10-15 21:30:07 UTC --- Should this be target or middle-end instead of c++? (I have no easy way to check whether it's still an issue today)
[Bug target/50678] [4.7 Regression] FAIL: c52104y on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678 --- Comment #31 from Eric Botcazou 2011-10-15 21:34:32 UTC --- There is some suspicious code in #0 0x7fff85c75d48 in libunwind::DwarfInstructions::stepWithDwarf(libunwind::LocalAddressSpace&, unsigned long long, unsigned long long, libunwind::Registers_x86_64&) () from /usr/lib/libSystem.B.dylib (gdb) disass Dump of assembler code for function _ZN9libunwind17DwarfInstructionsINS_17LocalAddressSpaceENS_16Registers_x86_64EE13stepWithDwarfERS1_yyRS2_: 0x7fff85c75990 <+0>: push %rbp 0x7fff85c75c81 <+753>: mov-0x860(%rbp),%rax 0x7fff85c75c88 <+760>: mov%rax,0xa0(%r13) 0x7fff85c75c8f <+767>: mov-0x868(%rbp),%rdx 0x7fff85c75c96 <+774>: mov%rdx,0x98(%r13) 0x7fff85c75c9d <+781>: mov-0x870(%rbp),%rcx 0x7fff85c75ca4 <+788>: mov%rcx,0x90(%r13) 0x7fff85c75cab <+795>: mov-0x878(%rbp),%rax 0x7fff85c75cb2 <+802>: mov%rax,0x88(%r13) 0x7fff85c75cb9 <+809>: mov-0x8e8(%rbp),%rdx 0x7fff85c75cc0 <+816>: mov%rdx,0x78(%r13) 0x7fff85c75cc4 <+820>: mov-0x8e0(%rbp),%rcx 0x7fff85c75ccb <+827>: mov%rcx,0x70(%r13) 0x7fff85c75ccf <+831>: mov-0x8d8(%rbp),%rax 0x7fff85c75cd6 <+838>: mov%rax,0x68(%r13) 0x7fff85c75cda <+842>: mov-0x8d0(%rbp),%rdx 0x7fff85c75ce1 <+849>: mov%rdx,0x60(%r13) 0x7fff85c75ce5 <+853>: mov-0x8c8(%rbp),%rcx 0x7fff85c75cec <+860>: mov%rcx,0x58(%r13) 0x7fff85c75cf0 <+864>: mov-0x8c0(%rbp),%rax 0x7fff85c75cf7 <+871>: mov%rax,0x50(%r13) 0x7fff85c75cfb <+875>: mov-0x8b8(%rbp),%rdx 0x7fff85c75d02 <+882>: mov%rdx,0x48(%r13) 0x7fff85c75d06 <+886>: mov-0x8b0(%rbp),%rcx 0x7fff85c75d0d <+893>: mov%rcx,0x40(%r13) 0x7fff85c75d11 <+897>: mov-0x8a8(%rbp),%rax 0x7fff85c75d18 <+904>: mov%rax,0x30(%r13) 0x7fff85c75d1c <+908>: mov-0x8a0(%rbp),%rdx 0x7fff85c75d23 <+915>: mov%rdx,0x20(%r13) 0x7fff85c75d27 <+919>: mov-0x898(%rbp),%rcx 0x7fff85c75d2e <+926>: mov%rcx,0x28(%r13) 0x7fff85c75d32 <+930>: mov-0x890(%rbp),%rax 0x7fff85c75d39 <+937>: mov%rax,0x8(%r13) 0x7fff85c75d3d <+941>: mov-0x888(%rbp),%rdx 0x7fff85c75d44 <+948>: mov%rdx,0x10(%r13) 0x7fff85c75d48 <+952>: mov-0x880(%rbp),%rcx 0x7fff85c75d4f <+959>: mov%rcx,0x18(%r13) 0x7fff85c75d53 <+963>: mov%r15,0x0(%r13) 0x7fff85c75d57 <+967>: mov%r12,0x38(%r13) 0x7fff85c75d5b <+971>: mov%rbx,0x80(%r13) -0x860(%rbp) seems to be a saved context: (gdb) x/gx (-0x860 + $rbp - 8 * 4) 0x100036900:0x7fff5fbff9f0 (gdb) x/gx (-0x860 + $rbp - 8 * 5) 0x1000368f8:0x7fff5f3ff9f0 (gdb) x/gx (-0x860 + $rbp - 8 * 6) 0x1000368f0:0x (gdb) x/gx (-0x860 + $rbp - 8 * 7) 0x1000368e8:0x7fff5fbff9f0 (gdb) x/gx (-0x860 + $rbp - 8 * 8) 0x1000368e0:0x7fff4fbfc9f0 (gdb) x/gx (-0x860 + $rbp - 8 * 9) 0x1000368d8:0x7fff5fbffa30 (gdb) x/gx (-0x860 + $rbp - 8 * 10) 0x1000368d0:0x8002 (gdb) x/gx (-0x860 + $rbp - 8 * 11) 0x1000368c8:0x1000 (gdb) x/gx (-0x860 + $rbp - 8 * 12) 0x1000368c0:0x8002 (gdb) x/gx (-0x860 + $rbp - 8 * 13) 0x1000368b8:0x1001 (gdb) x/gx (-0x860 + $rbp - 8 * 14) 0x1000368b0:0xfffa (gdb) x/gx (-0x860 + $rbp - 8 * 15) 0x1000368a8:0x000d (gdb) x/gx (-0x860 + $rbp - 8 * 16) 0x1000368a0:0x (gdb) x/gx (-0x860 + $rbp - 8 * 17) 0x100036898:0x0001 This is the same context as the one displayed by GDB when the probe hits: (gdb) info reg rax0x1010 268435472 rbx0x7fff5fbff9f0 140734799804912 rcx0x7fff5f3ff9f0 140734791416304 rdx0x0 0 rsi0x7fff5fbff9f0 140734799804912 rdi0x7fff4fbfc9f0 140734531357168 rbp0x7fff5fbffa30 0x7fff5fbffa30 rsp0x7fff5fbff9f0 0x7fff5fbff9f0 r8 0x8002 2147483650 r9 0x1000 268435456 r100x8002 2147483650 r110x1001 268435457 r120xfffa -6 r130xd 13 r140x0 0 r150x1 1 Now, at the end of the code sequence, the context pointed to by %r13 is: (gdb) x/gx ($r13 + 8 * 0) 0x1000372b0:0x1010 (gdb) x/gx ($r13 + 8 * 1) 0x1000372b8:0x (gdb) x/gx ($r13 + 8 * 2) 0x1000372c0:0x7fff5f3ff9f0 (gdb) x/gx ($r13 + 8 * 3) 0x1000372c8:0x7fff5fbff9f0 (gdb) x/gx ($r13 + 8 * 4) 0x1000372d0:0x7fff4fbfc9f0 (gdb) x/gx ($r13 + 8 * 5) 0x1000372d8:0x7fff5fbff9f0 (gdb) x/gx ($r13 + 8 * 6) 0x1000372e0:0x7
[Bug c/35649] Incorrect printf warning: expect double has float
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35649 Søren Holm changed: What|Removed |Added CC||sgh at sgh dot dk --- Comment #11 from Søren Holm 2011-10-15 21:48:25 UTC --- Iøm having the same isssue whne compiling with -fshort-double
[Bug c++/50593] [C++0x] improve __attribute__((format(printf)))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50593 --- Comment #5 from Paolo Carlini 2011-10-15 21:56:57 UTC --- I see. I'll give it some thought.
[Bug target/50678] [4.7 Regression] FAIL: c52104y on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678 --- Comment #32 from Iain Sandoe 2011-10-15 22:37:41 UTC --- thanks Eric, you're going much quicker then me ;) ... had some other things to do. I think libUnwind is released as OS these days, so it should be possible to look ... will try to find it tomorrow.
[Bug driver/50740] New: CPUID leaf 7 for BMI/BMI2/AVX2 feature detection not qualified with max_level and doesn't use subleaf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50740 Bug #: 50740 Summary: CPUID leaf 7 for BMI/BMI2/AVX2 feature detection not qualified with max_level and doesn't use subleaf Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassig...@gcc.gnu.org ReportedBy: craig.top...@gmail.com The cpuid code for detecting BMI, BMI2, and AVX2 support needs to be qualified with max_level >= 7. Additionally, it should use __cpuid_count instead of __cpuid because leaf 7 uses subleafs just like leaf 4. Relevant code from i386-driver.c __cpuid (0x7, eax, ebx, ecx, edx); has_bmi = ebx & bit_BMI; has_avx2 = ebx & bit_AVX2; has_bmi2 = ebx & bit_BMI2;
