[Bug fortran/51607] New: configure: error: GNU fortran compiler is not working ;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51607 Bug #: 51607 Summary: configure: error: GNU fortran compiler is not working ; Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: d.barr...@me.com checking whether we are using the GNU Fortran compiler... yes checking whether /Users/Exodus/downloads/gcc-4.6.2/build/./gcc/gfortran -B/Users/Exodus/downloads/gcc-4.6.2/build/./gcc/ -B/Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/bin/ -B/Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/lib/ -isystem /Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/include -isystem /Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/sys-includeaccepts -g... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for /Users/Exodus/downloads/gcc-4.6.2/build/./gcc/gfortran -B/Users/Exodus/downloads/gcc-4.6.2/build/./gcc/ -B/Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/bin/ -B/Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/lib/ -isystem /Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/include -isystem /Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/sys-includeoption to produce PIC... -fno-common checking if /Users/Exodus/downloads/gcc-4.6.2/build/./gcc/gfortran -B/Users/Exodus/downloads/gcc-4.6.2/build/./gcc/ -B/Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/bin/ -B/Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/lib/ -isystem /Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/include -isystem /Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/sys-includePIC flag -fno-common works... yes checking if /Users/Exodus/downloads/gcc-4.6.2/build/./gcc/gfortran -B/Users/Exodus/downloads/gcc-4.6.2/build/./gcc/ -B/Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/bin/ -B/Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/lib/ -isystem /Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/include -isystem /Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/sys-includestatic flag -static works... no checking if /Users/Exodus/downloads/gcc-4.6.2/build/./gcc/gfortran -B/Users/Exodus/downloads/gcc-4.6.2/build/./gcc/ -B/Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/bin/ -B/Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/lib/ -isystem /Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/include -isystem /Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/sys-includesupports -c -o file.o... yes checking if /Users/Exodus/downloads/gcc-4.6.2/build/./gcc/gfortran -B/Users/Exodus/downloads/gcc-4.6.2/build/./gcc/ -B/Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/bin/ -B/Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/lib/ -isystem /Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/include -isystem /Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/sys-includesupports -c -o file.o... (cached) yes checking whether the /Users/Exodus/downloads/gcc-4.6.2/build/./gcc/gfortran -B/Users/Exodus/downloads/gcc-4.6.2/build/./gcc/ -B/Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/bin/ -B/Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/lib/ -isystem /Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/include -isystem /Users/Exodus/my_gcc/x86_64-apple-darwin11.2.0/sys-includelinker (/Users/Exodus/downloads/gcc-4.6.2/build/./gcc/collect-ld) supports shared libraries... yes checking dynamic linker characteristics... darwin11.2.0 dyld checking how to hardcode library paths into programs... immediate checking whether the GNU Fortran compiler is working... no configure: error: GNU Fortran is not working; please report a bug in http://gcc.gnu.org/bugzilla, attaching /Users/Exodus/downloads/gcc-4.6.2/build/x86_64-apple-darwin11.2.0/libgfortran/config.log make[1]: *** [configure-target-libgfortran] Error 1 make: *** [all] Error 2 i'm quite new to unix, i have tried to find solutions to this but any help/pointers would be useful
[Bug fortran/51607] configure: error: GNU fortran compiler is not working ;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51607 --- Comment #1 from David d.barrows at me dot com 2011-12-18 09:25:27 UTC --- Created attachment 26127 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26127 fortran library config log
[Bug fortran/51607] configure: error: GNU fortran compiler is not working ;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51607 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-12-18 09:51:35 UTC --- Most of the time this issue indicates a problem with the MPFR installation. On Darwin, those issues were said to be due to miscompilations of MPFR by Apple's GCC, cf. PR 51103 and PR 51343.
[Bug fortran/51605] internal compiler error gfc_trans_block_construct, at fortran/trans-stmt.c:984
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51605 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2011-12-18 10:01:13 UTC --- With the current GCC 4.7 I get for the original example (comment 0, attachment 26126) but also for Steve's reduced test case in comment 3 the error: integer_ptr = symbol_ptr 1 Error: Pointer assignment target is neither TARGET nor POINTER at (1) [Cf. comment 2, PR 48887] I believe the error message is correct due to (F2008, 16.5.1.6 Construct association): If the selector has the POINTER attribute, it shall be associated; the associate name is associated with the target of the pointer and does not have the POINTER attribute. And due to the error message, the code part which ICEs cannot be reached. Dan: You wrote: Compiles with fort 12.1, nagfor has a different problem. Do you believe the code is valid, if so, why doesn't 16.5.1.6 apply? If it applies, can you construct a valid example which still fails? Dan, Stave: If possible, please also update your GCC to 2011-12-11 or newer - at least if you use OOP/polymorphism features. (You might be able to get a newer binary from http://gcc.gnu.org/wiki/GFortranBinaries )
[Bug libstdc++/51608] New: [4.7 Regression][C++11] Unordered containers end(size_type) isn't constant time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51608 Bug #: 51608 Summary: [4.7 Regression][C++11] Unordered containers end(size_type) isn't constant time Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: paolo.carl...@oracle.com An internal reminder. The issue must be fixed in time for the release.
[Bug libstdc++/51608] [4.7 Regression][C++11] Unordered containers end(size_type) isn't constant time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51608 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-12-18 CC||fdumont at gcc dot gnu.org Target Milestone|--- |4.7.0 Ever Confirmed|0 |1
[Bug fortran/51589] Modification of loop index variable by intent(out) or intent(inout) procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51589 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-12-18 CC||tkoenig at gcc dot gnu.org Ever Confirmed|0 |1 Severity|normal |enhancement --- Comment #6 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-12-18 10:20:44 UTC --- Confirmed, would be nice to have.
[Bug c++/51602] Segmentation fault: internal compiler error on error message (I think)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51602 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011-12-18 CC|t1t0 at tiscali dot it | Ever Confirmed|0 |1 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-18 10:53:09 UTC --- gcc4.4.x is very close to its end of life, please see if you can reproduce the issue with a much more recent compiler, ideally gcc4.6.x. In case, please provide the required information: http://gcc.gnu.org/bugs/#report
[Bug c++/51571] No named return value optimization while adding a dummy scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51571 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-18 10:55:08 UTC --- Adding Jason, I seem to remember he did NRVO on trees.
[Bug c++/50504] g++ 4.5.2 -O2 with complexdouble produces incorrect code on AMD64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50504 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED Known to work||4.6.0, 4.7.0 Resolution||FIXED --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-18 11:03:18 UTC --- Thus this is fixed in the active branches.
[Bug bootstrap/51599] [4.7 Regression] Bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51599 Gerald Pfeifer gerald at pfeifer dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-12-18 CC||gerald at pfeifer dot com Ever Confirmed|0 |1 --- Comment #5 from Gerald Pfeifer gerald at pfeifer dot com 2011-12-18 11:26:19 UTC --- Same for my tests on i386-unknown-freebsd10 and x86_64-unknown-freebsd8 and minimal configure options --prefix and --with-gmp only. The bootstrapping compiler is GCC 4.2. Is it possible that this, the bootstrapping compiler being older, makes a difference somehow? I see this in the failing invocation which does not use an absolute path name for g++! g++ -I/scratch/tmp/gerald/gcc-HEAD/libcpp -I. -I/scratch/tmp/gerald/gcc-HEAD/li bcpp/../include -I./../intl -I/scratch/tmp/gerald/gcc-HEAD/libcpp/include -g -O 2 -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -pedantic - Wno-long-long -Werror -fno-exceptions -fno-rtti -I/scratch/tmp/gerald/gcc-HEAD/l ibcpp -I. -I/scratch/tmp/gerald/gcc-HEAD/libcpp/../include -I./../intl -I/scratc h/tmp/gerald/gcc-HEAD/libcpp/include -c -o identifiers.o -MT identifiers.o -MMD -MP -MF .deps/identifiers.Tpo /scratch/tmp/gerald/gcc-HEAD/libcpp/identifiers.c cc1plus: error: unrecognized command line option -Wno-narrowing
[Bug tree-optimization/51606] [4.7 Regression] FAIL: gcc.dg/vect/pr51015.c (internal compiler error) on ppc*-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51606 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-12-18 CC||irar at il dot ibm.com Ever Confirmed|0 |1 --- Comment #1 from Ira Rosen irar at il dot ibm.com 2011-12-18 11:41:41 UTC --- Caused by r182388 | jakub | 2011-12-15 22:47:29 +0200 (Thu, 15 Dec 2011) | 27 lines * tree-vectorizer.h (struct _stmt_vec_info): Remove pattern_def_stmt field, add pattern_def_seq. (STMT_VINFO_PATTERN_DEF_STMT): Remove. (STMT_VINFO_PATTERN_DEF_SEQ): Define. (NUM_PATTERNS): Bump to 10. * tree-vect-loop.c (vect_determine_vectorization_factor, vect_transform_loop): Adjust for pattern def changing from a single gimple stmt to gimple_seq. * tree-vect-stmts.c (vect_analyze_stmt, new_stmt_vec_info, free_stmt_vec_info): Likewise. * tree-vect-patterns.c (vect_recog_over_widening_pattern, vect_recog_vector_vector_shift_pattern, vect_recog_mixed_size_cond_pattern, adjust_bool_pattern_cast, adjust_bool_pattern, vect_mark_pattern_stmts): Likewise. (vect_recog_sdivmod_pow2_pattern): New function. (vect_vect_recog_func_ptrs): Add it. ... And probably PR 51580 is the same problem. Looking at pr51015.c, vect_recog_vector_vector_shift_pattern is detected and a new def stmt is created during the detection: patt.23_33 = (long long unsigned int) D.2004_3; The pattern detection fails later (on the vector type checks probably), but this stmt remains a use stmt of D.2004_3 = i_25 + -2;. Therefore, we check whether it's inside the loop, but get segfault while trying to check its not existing BB. Before the use of gimple_seq, this didn't happen, i.e., patt.23_33 = (long long unsigned int) D.2004_3; wasn't a use of D.2004_3 = i_25 + -2;.
[Bug libstdc++/51609] New: [C++11] unique_ptrconst T[]::reset rejects cv-compatible argument pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51609
Bug #: 51609
Summary: [C++11] unique_ptrconst T[]::reset rejects
cv-compatible argument pointers
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
gcc 4.7.0 20111210 (experimental) in C++0x mode rejects the following code:
//---
#include memory
struct T {};
T* bar() { return new T{}; }
int main()
{
std::unique_ptrconst T[] p;
p.reset(bar()); // # Line 10
}
//---
main.cpp||In function 'int main()':|
main.cpp|10|error: use of deleted function 'void std::unique_ptr_Tp [],
_Dp::reset(_Up) [with _Up = T*; _Tp = const T; _Dp = std::default_deleteconst
T []]'|
[..]include\c++\4.7.0\bits\unique_ptr.h|392|error: declared here|
This behaviour is in conflict with the standard. Referring to N3290
[unique.ptr.runtime] p1 b2:
— Pointers to types derived from T are rejected by the constructors, and by
reset.
Further inspection of [unique.ptr.runtime.modifiers] does not reveal any
further constraints that could invalidate the assumption that reset should
accept the pointer to non-const T. This should also not be invalidated by the
constraints on default_deleteT[]::operator(), because the deleter will always
be called on the internally hold pointer which has the correct type.
In regard to the seemingly difference to the constructor constraints of
[unique.ptr.runtime.ctor] p1 I would like to point to a new LWG issue:
http://cplusplus.github.com/LWG/lwg-active.html#2118
[Bug middle-end/51590] [4.7 Regression] ICE in gsi_for_stmt, at gimple-iterator.c:560
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51590 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
Re: [Bug c/50111] New: Option -O0 cause Error: unsupported for `movq'
Same error building SDL 1.2.14 on msys/mingw using gcc 4.6.1. By default, no optimization flags are passed to gcc, adding -O2 makes the build succeed.
[Bug middle-end/51590] [4.7 Regression] ICE in gsi_for_stmt, at gimple-iterator.c:560
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51590
--- Comment #2 from Dmitry G. Dyachenko dimhen at gmail dot com 2011-12-18
13:13:36 UTC ---
gcc version 4.7.0 20111218 (experimental) [trunk revision 182459] (GCC)
Fedora 16/x64
$ cat c51590.c
#include sys/time.h
extern void baz(char *);
static
void
bar( struct timeval *sv)
{
char bt[8];
int i;
for(i=0; i 8; i++)
bt[i] = sv-tv_sec ( ( 7 - i ) * 8 );
baz(bt);
}
void
foo(const char *s)
{
struct timeval sp_cur;
int i;
for(i=0; *s; s++)
i++;
if(i != 1)
return;
bar(sp_cur);
}
$ LANG=C gcc -O3 -Wall -Wextra -c c51590.c
c51590.c: In function 'foo':
c51590.c:19:1: internal compiler error: in gsi_for_stmt, at
gimple-iterator.c:560
[Bug fortran/51605] internal compiler error gfc_trans_block_construct, at fortran/trans-stmt.c:984
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51605 --- Comment #5 from Dan Nagle danlnagle at me dot com 2011-12-18 13:13:48 UTC --- Citations from 10-007r1.pdf [185:17-18] says the polymorphic symbol_ptr takes the type of the type guard within the type guard. [171:7-8] says the associating entity loses the pointer attribute but keeps the target attribute. (It has the target attribute because it was a pointer outside the type guard.) Therefore I believe it's conforming to point to the associating entity with a typed pointer. (integer_ptr = symbol_ptr) My analysis could be faulty. I'm using the gfortran I'm using because it had a Mac installer. I thought 4.6.2 was fairly recent. This is all new stuff and I'm learning it myself and getting surprised here and there. Thanks for your efforts.
[Bug target/50588] gcc produce bad inlined code with -march=athlon -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50588 --- Comment #15 from Mikael Pettersson mikpe at it dot uu.se 2011-12-18 13:54:42 UTC --- The problem appears to occur in rtx_addr_can_trap_p_1, case REG. It returns false for any address formed by the frame or stack pointer plus an offset, regardless of the value of the offset. In the test case it allows offsets in the half GB range, which is bogus. If I force it to return true for offsets larger than, say, +/- 4KB, then the test case is unbroken. Could rtx_addr_can_trap_p_1 find out what the ranges of safe offsets from the stack and frame pointers are?
[Bug fortran/51605] internal compiler error gfc_trans_block_construct, at fortran/trans-stmt.c:984
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51605 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2011-12-18 14:11:00 UTC --- (In reply to comment #5) Therefore I believe it's conforming to point to the associating entity with a typed pointer. (integer_ptr = symbol_ptr) I should have read the test case more carefully. The associate name is on the right and not on the left hand side. I concur that in this case the associate name should get the target attribute. Thanks for pointing that out! I'm using the gfortran I'm using because it had a Mac installer. I thought 4.6.2 was fairly recent. Yes, 4.6.2 is the latest release; however, the 4.6 branch is now 9 months old and thus misses all the changes for 4.7, which will be released in March. [The trunk (= main development line) is currently in the stabilization and bug fixing Stage 3.] As Fortran's polymorphism support is quite complicated, implementing it takes a while and the current implementations are still incomplete and buggy. (That's the case for all compilers, though the stability and completeness varies.) In case of GCC/gfortran, 4.7 now supports constructors (DT name = generic function name) and - since 2011-12-11 -polymorphic arrays. Additionally, several other bugs were fixed. See http://gcc.gnu.org/wiki/OOP for an overview. There is a fairly new 4.7 binary available for Darwin (cf. http://gcc.gnu.org/wiki/GFortranBinaries#MacOS ) but the build is almost 4 weeks old and thus does not yet support polymorphic arrays. My idea was that I will asked for a new build soon, but only after a few additional OOP bugs have been fixed.
[Bug fortran/51607] configure: error: GNU fortran compiler is not working ;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51607 --- Comment #3 from David d.barrows at me dot com 2011-12-18 14:15:15 UTC --- any ideas of how to solve this?
[Bug libstdc++/51609] [C++11] unique_ptrconst T[]::reset rejects cv-compatible argument pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51609 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-18 14:47:50 UTC --- I'll look into this today...
[Bug c/51597] math libraryb not works
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51597 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-18 15:05:59 UTC --- (In reply to comment #0) :~$gcc -lm rf.c try gcc rf.c -lm
[Bug fortran/51605] internal compiler error gfc_trans_block_construct, at fortran/trans-stmt.c:984
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51605 --- Comment #7 from Steve Kargl sgk at troutmask dot apl.washington.edu 2011-12-18 16:39:24 UTC --- On Sun, Dec 18, 2011 at 10:01:13AM +, burnus at gcc dot gnu.org wrote: Dan, Stave: If possible, please also update your GCC to 2011-12-11 or newer - at least if you use OOP/polymorphism features. (You might be able to get a newer binary from http://gcc.gnu.org/wiki/GFortranBinaries ) I did the update last night whlie dreamed of sugarplums. This morning with the new gfortran, I get the error messages that you and Domonique report: laptop:kargl[221] gfc4x -c coco.f90 coco.f90:91.24: integer_ptr = symbol_ptr 1 Error: Pointer assignment target is neither TARGET nor POINTER at (1) coco.f90:94.24: logical_ptr = symbol_ptr 1 Error: Pointer assignment target is neither TARGET nor POINTER at (1)
[Bug fortran/51610] New: [OOP] Class container does not properly handle POINTER and TARGET
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51610 Bug #: 51610 Summary: [OOP] Class container does not properly handle POINTER and TARGET Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: accepts-invalid, rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: ja...@gcc.gnu.org, pa...@gcc.gnu.org Blocks: 51605 The following program compiles - but it is invalid. 1. The TARGET attribute is required for b and c But if one tries to set it, one gets an error. Expected: One can mark them as TARGET and without one gets an error for the CALL. 2. The ptr = x is invalid as x is not TARGET but no error is printed. 3. If one swaps the x and the z lines, one gets the error: ptr = x 1 Error: Non-POINTER in pointer association context (pointer assignment) But one get also an error for the ptr = y and ptr = z lines. Related is PR 51605: SELECT TYPE's associate-name needs to set TARGET attribute type t end type t class(t), allocatable :: a(:), b(:), c(:) ! Bogus error: Error: Duplicate TARGET attribute specified ! target :: a, b, c allocate (a(1), b(1), c(1)) ! Requires: TARGET attribute - call test(a, b, c) ! possibly not correctly diagnosed contains subroutine test(x, y, z) class(t), pointer, intent(in) :: z(:) class(t), target :: y(3) class(t) :: x(3) class(t), pointer :: ptr(:) ptr = x ! Invalid: x is not a TARGET ptr = y ! Valid: x is a TARGET ptr = z ! Valid: z is a POINTER end subroutine end
[Bug bootstrap/51599] [4.7 Regression] Bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51599 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Richard Henderson rth at gcc dot gnu.org 2011-12-18 18:34:18 UTC --- The patch in question was reverted.
[Bug bootstrap/51072] [4.7 Regression] Build with --disable-bootstrap fails in libitm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51072 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #14 from Richard Henderson rth at gcc dot gnu.org 2011-12-18 18:35:36 UTC --- So, that fix didn't work...
[Bug rtl-optimization/51374] [avr] insn combine reorders volatile memory accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51374 --- Comment #6 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-12-18 19:01:56 UTC --- In combine.c:try_combine, just after the Trying... dump output, there is: i0 = 0 i1 = 0 i2 = (set (reg/v:QI 43 [ status ]) (mem/v:QI (const_int 43 [0x2b]))) i3 = (set (pc) (if_then_else (eq (zero_extract:QI (reg/v:QI 43 [ status ]) (const_int 1) (const_int 4)) (const_int 0)) (label_ref:HI 16) (pc))) where the potential insertion is i2 into i3. These insns are fed into can_combine_p with src = (mem/v:QI (const_int 43)) dest = (reg/v:QI 43) and then there is this part of an if-clause: /* Make sure that the value that is to be substituted for the register does not use any registers whose values alter in between. However, If the insns are adjacent, a use can't cross a set even though we think it might (this can happen for a sequence of insns each setting the same destination; last_set of that register might point to a NOTE). If INSN has a REG_EQUIV note, the register is always equivalent to the memory so the substitution is valid even if there are intervening stores. Also, don't move a volatile asm or UNSPEC_VOLATILE across any other insns. */ || (! all_adjacent (((!MEM_P (src) || ! find_reg_note (insn, REG_EQUIV, src)) use_crosses_set_p (src, DF_INSN_LUID (insn))) || (GET_CODE (src) == ASM_OPERANDS MEM_VOLATILE_P (src)) || GET_CODE (src) == UNSPEC_VOLATILE)) In addition to these tests, the following must be disallowed: If src contains volatile memory, then disallow moving it across: * volatile memory * unspec_volatile * asm volatile As far as I can see, use_crosses_set_p (src,...) returns 0 (false) which is incorrect. So either use_crosses_set_p is incorrect or it relies on incorrect data from data flow analysis or from wherever.
[Bug driver/48524] spec language does not cover switches with separated form
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48524 Magnus Granberg zorry at gentoo dot org changed: What|Removed |Added Attachment #26124|0 |1 is obsolete|| --- Comment #7 from Magnus Granberg zorry at gentoo dot org 2011-12-18 20:11:32 UTC --- Created attachment 26128 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26128 switches with separated form -D and -U Same patch but with a testcase. Tested on Gentoo with snapshot 4.7-20111217
[Bug c++/33475] New warning suggestion: virtual functions called from constructors/destructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33475 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||reichelt at gcc dot gnu.org Resolution||DUPLICATE --- Comment #8 from Volker Reichelt reichelt at gcc dot gnu.org 2011-12-18 20:45:42 UTC --- Duplicate of PR 24058. *** This bug has been marked as a duplicate of bug 24058 ***
[Bug c++/24058] g++ should warn about virtual methods called in constructors and destructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24058 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added CC||yuri at tsoft dot com --- Comment #2 from Volker Reichelt reichelt at gcc dot gnu.org 2011-12-18 20:45:42 UTC --- *** Bug 33475 has been marked as a duplicate of this bug. ***
[Bug c++/51611] New: [c++0x] ICE with non-static data member initializer and virtual base class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51611
Bug #: 51611
Summary: [c++0x] ICE with non-static data member initializer
and virtual base class
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reich...@gcc.gnu.org
The following valid code snippet triggers an ICE on trunk:
struct A
{
int i;
};
struct B : virtual A
{
int j = i;
};
bug.cc:8:11: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
[Bug c++/51612] New: [c++0x] [4.7 Regression] ICE with constexpr constructor and virtual base class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51612
Bug #: 51612
Summary: [c++0x] [4.7 Regression] ICE with constexpr
constructor and virtual base class
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reich...@gcc.gnu.org
The following valid code snippet triggers an ICE on trunk:
struct A {};
struct B : virtual A
{
constexpr B() {}
};
bug.cc: In constructor 'constexpr B::B()':
bug.cc:5:18: internal compiler error: in build_data_member_initialization, at
cp/semantics.c:5781
Please submit a full bug report, [etc.]
[Bug c++/51612] [c++0x] [4.7 Regression] ICE with constexpr constructor and virtual base class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51612 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |4.7.0
[Bug target/43437] ICE in CSE, during libgcc build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43437 --- Comment #11 from Thorsten Glaser tg at mirbsd dot org 2011-12-18 21:52:43 UTC --- Created attachment 26129 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26129 preprocessed source for another occurence I’m also getting one of these. Not sure if it’s the same issue though. Messages: /tmp/buildd/libvirt-0.9.8/./src/conf/domain_conf.c: In function 'virDomainDefParseXML': /tmp/buildd/libvirt-0.9.8/./src/conf/domain_conf.c:7939:1: internal compiler error: in cselib_record_set, at cselib.c:2148 Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.6/README.Bugs for instructions. Preprocessed source stored into /tmp/ccCjFD7F.out file, please attach this to your bugreport. Compile command: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I/tmp/buildd/libvirt-0.9.8/./src -I.. -I/tmp/buildd/libvirt-0.9.8/./gnulib/lib -I../gnulib/lib -I../include -I/tmp/buildd/libvirt-0.9.8/./src/util -I/tmp/buildd/libvirt-0.9.8/./include -DIN_LIBVIRT -I/usr/include/libxml2 -Wall -W -Wformat-y2k -Wformat-security -Winit-self -Wmissing-include-dirs -Wunused -Wunknown-pragmas -Wstrict-aliasing -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-align -Wwrite-strings -Wlogical-op -Waggregate-return -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -Wmissing-format-attribute -Wredundant-decls -Wnested-externs -Winline -Winvalid-pch -Wvolatile-register-var -Wdisabled-optimization -Wbuiltin-macro-redefined -Wmudflap -Wpacked-bitfield-compat -Wsync-nand -Wattributes -Wcoverage-mismatch -Wmultichar -Wcpp -Wdeprecated-declarations -Wdiv-by-zero -Wdouble-promotion -Wendif-labels -Wextra -Wformat-contains-nul -Wformat-extra-args -Wformat-zero-length -Wformat=2 -Wmultichar -Wnormalized=nfc -Woverflow -Wpointer-to-int-cast -Wpragmas -Wsuggest-attribute=const -Wsuggest-attribute=noreturn -Wsuggest-attribute=pure -Wtrampolines -Wno-missing-field-initializers -Wno-sign-compare -Wjump-misses-init -Wno-format-nonliteral -Wframe-larger-than=4096 -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-all --param=ssp-buffer-size=4 -fexceptions -fasynchronous-unwind-tables -fdiagnostics-show-option -funit-at-a-time -fipa-pure-const -Wno-suggest-attribute=pure -Wno-suggest-attribute=const -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -Wall -c /tmp/buildd/libvirt-0.9.8/./src/conf/domain_conf.c -o libvirt_conf_la-domain_conf.o Compiler used: (pbuild22074)root@ara5:/tmp # gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/m68k-linux-gnu/4.6/lto-wrapper Target: m68k-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.2-7' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --disable-libssp --enable-plugin --enable-objc-gc --disable-werror --disable-multilib --enable-checking=release --build=m68k-linux-gnu --host=m68k-linux-gnu --target=m68k-linux-gnu Thread model: posix gcc version 4.6.2 (Debian 4.6.2-7) Environment: clean cowbuilder chroot of Debian sid (unstable) Linux ara5.mirbsd.org 3.0.0-2-atari #1 Sun Oct 9 00:23:32 UTC 2011 m68k GNU/Linux Interestingly enough (this is a libtool build), the line with -fPIC -DPIC did not fail.
[Bug target/43437] ICE in CSE, during libgcc build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43437 Thorsten Glaser tg at mirbsd dot org changed: What|Removed |Added CC||tg at mirbsd dot org --- Comment #12 from Thorsten Glaser tg at mirbsd dot org 2011-12-18 22:00:28 UTC --- Indeed. Compiling the file (renamed to x.i) with • gcc -O2 -c x.i ⇒ fails with the same error • gcc -O2 -c -fPIC x.i ⇒ succeeds. Note that -O2 is needed, otherwise it won’t compile at all (apparently some bug when something is not inlined in the original source, didn’t investigate).
[Bug libgcj/51500] [4.7 regression] 106 unexpected libjava testsuite failures with mingw32
--disable-bootstrap --target=i686-pc-mingw32 --enable-shared --enable-load-library --enable-interpreter --disable-sjlj-exceptions --enable-gomp --with-ecj-jar=/tmp/gcc/org.eclipse.jdt.core_3.7.0.v_B35.jar --with-antlr-jar=/tmp/gcc/antlr-3.3-complete.jar --with-libiconv-prefix=/usr/i686-pc-mingw32 --with-x=no --enable-cloog-backend=isl --with-sysroot=/usr/i686-pc-mingw32/sys-root --with-build-sysroot=/usr/i686-pc-mingw32/sys-root target_alias=i686-pc-mingw32 --enable-languages=c,c++,java,lto --no-create --no-recursion Thread model: win32 gcc version 4.7.0 20111218 (experimental) (GCC)
[Bug target/43437] ICE in CSE, during libgcc build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43437 --- Comment #13 from Thorsten Glaser tg at mirbsd dot org 2011-12-18 22:10:13 UTC --- This is a regression: this works gcc-4.4 -std=gnu99 -DHAVE_CONFIG_H -I. -I/tmp/buildd/libvirt-0.9.8/./src -I.. -I/tmp/buildd/libvirt-0.9.8/./gnulib/lib -I../gnulib/lib -I../include -I/tmp/buildd/libvirt-0.9.8/./src/util -I/tmp/buildd/libvirt-0.9.8/./include -DIN_LIBVIRT -I/usr/include/libxml2 -Wall -W -Wformat-y2k -Wformat-security -Winit-self -Wmissing-include-dirs -Wunused -Wunknown-pragmas -Wstrict-aliasing -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-align -Wwrite-strings -Wlogical-op -Waggregate-return -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -Wmissing-format-attribute -Wredundant-decls -Wnested-externs -Winline -Winvalid-pch -Wvolatile-register-var -Wdisabled-optimization -Wbuiltin-macro-redefined -Wmudflap -Wpacked-bitfield-compat -Wsync-nand -Wattributes -Wcoverage-mismatch -Wmultichar -Wdeprecated-declarations -Wdiv-by-zero -Wendif-labels -Wextra -Wformat-contains-nul -Wformat-extra-args -Wformat-zero-length -Wformat=2 -Wmultichar -Wnormalized=nfc -Woverflow -Wpointer-to-int-cast -Wpragmas -Wno-missing-field-initializers -Wno-sign-compare -Wno-format-nonliteral -Wframe-larger-than=4096 -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-all --param=ssp-buffer-size=4 -fexceptions -fasynchronous-unwind-tables -fdiagnostics-show-option -funit-at-a-time -fipa-pure-const -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -Wall -c /tmp/buildd/libvirt-0.9.8/./src/conf/domain_conf.c -o libvirt_conf_la-domain_conf.o (same command line with s/^gcc/gcc-4.4/ and a few -W* options removed); the preprocessed source FTB with gcc-4.4 (pbuild22074)root@ara5:~/libvirt-0.9.8/debian/build/src # gcc-4.4 -v Using built-in specs. Target: m68k-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.6-14' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --disable-libssp --enable-objc-gc --disable-werror --disable-multilib --enable-checking=release --build=m68k-linux-gnu --host=m68k-linux-gnu --target=m68k-linux-gnu Thread model: posix gcc version 4.4.6 (Debian 4.4.6-14)
[Bug c++/51613] New: Ambiguous function template instantiations as template argument are not rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51613
Bug #: 51613
Summary: Ambiguous function template instantiations as template
argument are not rejected
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pkmx...@gmail.com
In the book C++ Templates - The Complete Guide section 8.3, the following
code snippet is given:
templatetypename F, typename T
void apply(F f, T t)
{
f(t);
}
templatetypename T
void multi(T)
{
}
templatetypename T
void multi(T*)
{
}
int main()
{
apply(multiint, 7);
return 0;
}
My understanding is that multiint here instantiates two functions of types
void (*)(int) and void (*)(int*) with no ways to disambiguate and therefore F
cannot be deducted. However, gcc currently deducts F as void (*)(int) and
ultimately calls multi(int). This is the same case for gcc 4.4.3, gcc 4.6.2,
gcc 4.7.0 2012 snapshot and probably other versions.
[Bug c++/51614] New: [4.6/4.7 Regression] ICE with ambiguous base class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51614
Bug #: 51614
Summary: [4.6/4.7 Regression] ICE with ambiguous base class
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reich...@gcc.gnu.org
The following invalid code snippet triggers an ICE since GCC 4.6.0:
==
struct A
{
void foo();
};
struct B : A {};
struct C : A {};
struct D : B, C
{
D() { A::foo(); }
};
==
bug.cc: In constructor 'D::D()':
bug.cc:11:16: internal compiler error: in build_base_path, at cp/class.c:272
Please submit a full bug report, [etc.]
In earlier versions, a misleading error message was given:
bug.cc: In constructor 'D::D()':
bug.cc:11:16: error: cannot call member function 'void A::foo()' without object
Instead, the compiler should complain about an ambiguous base class.
[Bug c++/51614] [4.6/4.7 Regression] ICE with ambiguous base class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51614 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic, ||ice-on-invalid-code Target Milestone|--- |4.6.3
[Bug libgcj/51615] New: Condition Variable queue state corruption and infinite loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51615 Bug #: 51615 Summary: Condition Variable queue state corruption and infinite loop Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassig...@gcc.gnu.org ReportedBy: nwfila...@gmail.com When attempting to run ecj-3.8M4.jar on a large number of files, gij hangs. (On a small number of files, it runs fine, curiously enough.) Invoking gdb (7.3.1), I see that the thread is stuck in (gdb) bt #0 _Jv_CondWait (cv=0x1729a48, mu=optimized out, millis=optimized out, nanos=optimized out) at ../.././../gcc-4.7-20111210/libjava/posix-threads.cc:241 #1 0x419d99b8 in java::lang::Object::wait (this=0x1704900, timeout=250, nanos=optimized out) at ../.././../gcc-4.7-20111210/libjava/java/lang/natObject.cc:226 #2 0x42486aa4 in ffi_call_v9 () at ../.././../gcc-4.7-20111210/libffi/src/sparc/v9.S:83 #3 0x42486400 in ffi_call (cif=0x1815f08, fn=optimized out, rvalue=0x7fdff7f97e8, avalue=0x7fdff7f9680) at ../.././../gcc-4.7-20111210/libffi/src/sparc/ffi.c:415 #4 0x424830c8 in ffi_java_raw_call (cif=optimized out, fn=optimized out, rvalue=optimized out, raw=optimized out) at ../.././../gcc-4.7-20111210/libffi/src/java_raw_api.c:300 #5 0x419b6430 in _Jv_InterpMethod::run (retp=0x7fdff7f9aa0, args=0x419b6d9c, meth=0x13a0c00) at ../.././../gcc-4.7-20111210/libjava/interpret-run.cc:613 #6 0x42483028 in ffi_java_translate_args (cif=optimized out, rvalue=optimized out, avalue=optimized out, user_data=optimized out) at ../.././../gcc-4.7-20111210/libffi/src/java_raw_api.c:314 #7 0x424867e0 in ffi_closure_sparc_inner_v9 (closure=optimized out, rvalue=0x7fdff7f9aa0, gpr=0x7fdff7f9bc0, fpr=0x7fdff7f9ac0) at ../.././../gcc-4.7-20111210/libffi/src/sparc/ffi.c:621 #8 0x42486b90 in ffi_closure_v9 () at ../.././../gcc-4.7-20111210/libffi/src/sparc/v9.S:181 #9 0x41dd2ce8 in java.lang.Thread.run()void (this=optimized out) at /var/ports/usr/ports/lang/gcc47/work/gcc-4.7-20111210/libjava/java/lang/Thread.java:761 #10 0x419ddbec in _Jv_ThreadRun (thread=optimized out) at ../.././../gcc-4.7-20111210/libjava/java/lang/natThread.cc:335 #11 0x419e78a8 in really_start (x=optimized out) at ../.././../gcc-4.7-20111210/libjava/posix-threads.cc:639 #12 0x4249950c in GC_start_routine (arg=0x12ca120) at ../.././../gcc-4.7-20111210/boehm-gc/pthread_support.c:1301 #13 0x43c68890 in ?? () from /lib/libthr.so.3 #14 0x43c68890 in ?? () from /lib/libthr.so.3 and if I (gdb) print cv.first $14 = (_Jv_Thread_t *) 0x446c4830 (gdb) print cv.first.next $15 = (_Jv_Thread_t *) 0x446c4830 which is obviously bad since the loop we're stuck in is over -next pointers until we see a NULL, which we won't. Note that current has also become corrupted in the same way: (gdb) print current $16 = (_Jv_Thread_t *) 0x446c4860 (gdb) print current.next $17 = (_Jv_Thread_t *) 0x446c4860 I am on a FreeBSD/sparc64 machine, running 8.2 and using gcc47 from ports (which means exactly 4.7.0 20111210). It's quite easy to get into this state, so if I've left something out please don't hesitate to ask.
[Bug c++/51612] [c++0x] [4.7 Regression] ICE with constexpr constructor and virtual base class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51612 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Keywords|ice-on-valid-code |ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2011-12-18 CC||jason at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org 2011-12-18 22:27:30 UTC --- This is not valid code; a class with virtual bases cannot have a constexpr constructor.
[Bug libstdc++/51540] doxygen documentation for partial_sum misleading
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51540 --- Comment #18 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-18 22:33:19 UTC --- Author: redi Date: Sun Dec 18 22:33:15 2011 New Revision: 182461 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182461 Log: PR libstdc++/51540 * include/bits/stl_numeric.h (partial_sum): Adjust doxygen comments. Modified: branches/gcc-4_6-branch/libstdc++-v3/ChangeLog branches/gcc-4_6-branch/libstdc++-v3/include/bits/stl_numeric.h
[Bug libstdc++/51540] doxygen documentation for partial_sum misleading
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51540 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #19 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-18 22:34:32 UTC --- also fixed in the 4.6 branch
[Bug c++/51364] C++ interoperability with ISO-C extension DFP types requires explicit typedefs.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51364 --- Comment #8 from Domingo Alvarez mingodad at gmail dot com 2011-12-18 23:30:43 UTC --- (In reply to comment #7) An executable with decimal float support is very big because the runtime support is in static libraries, not in shared libraries (DLLs). That will probably change if it ever gets widespread use. Thanks for the answer but there is something strange because the jump from a small executable to a big one +2.5MB is a bit strange, in one test program consisting of compiling the printf.c of sqlite3 after some defines to allow it compile outside sqlite3 source tree, the executable using _Decimal64 and _Decimal128 is 2.49MB and if I remove a call to isnan the size go down to 480KB and if I use _Decimal64 in place of _Decimal128 it goes down to 228KB. With other program that only do some calculations with _Decimal64 and one use of _Decimal128 result in an executable of 135KB if I add a call to isnan there is no change at all on executable size. So I got lost on understando the logic that makes gcc add 2MB of static code. By the results of the second program it seems that it's possible to use _Decimal64 _Decimal128 and have a reasonable executable size, but suddenly it jumps to 2.5MB. I tested lua 5.1.4 as well and it goes from using double from 150KB to using _Decimal64 to 2.48MB and I tried to cut code where _Math is done on numbers but without get any executable reduction. So resuming I think there is possibility to use _Decimal64 without load 2.5MB it only needs some adjusts to the way gcc is generating code.
[Bug middle-end/51252] FAIL: c-c++-common/tm/freq.c (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51252 --- Comment #7 from dave.anglin at bell dot net 2011-12-19 00:08:54 UTC --- The attached patch seems to fix the tm test failures. However, it needs a bit more testing and I don't understand the registration magic. -- John David Anglindave.ang...@bell.net
[Bug target/43437] ICE in CSE, during libgcc build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43437 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #14 from Mikael Pettersson mikpe at it dot uu.se 2011-12-19 00:10:17 UTC --- Is the ICE for m68k reproducible with a cross-compiler hosted on x86? That would make bisection and other investigation a lot easier...
[Bug fortran/51529] [OOP] gfortran.dg/class_to_type_1.f03 is miscompiled: Uninitialized variable used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51529 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #5 from John David Anglin danglin at gcc dot gnu.org 2011-12-19 00:21:44 UTC --- On hppa2.0w-hp-hpux11.11, the test fails but the backtrace also fails: A fatal error occurred! Backtrace for this error:#0 0xC1B39FE3FAIL: gfortran.dg/class_to_type_1.f03 -O0 execution test
[Bug c++/51364] C++ interoperability with ISO-C extension DFP types requires explicit typedefs.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51364 --- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-19 00:21:36 UTC --- There's nothing strange - the runtime code is in static libraries, so all the code for doing I/O must be linked into the executable if you use e.g. printf. Using isnan probably doesn't require linking to a library function, so doesn't pull in all the code.
[Bug fortran/51616] New: [4.7 Regression] gfortran.dg/quad_2.f90 fails on hppa*-*-hpux*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51616 Bug #: 51616 Summary: [4.7 Regression] gfortran.dg/quad_2.f90 fails on hppa*-*-hpux* Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran -B /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../ -B/test/gnu/gcc/objdir/hppa2. 0w-hp-hpux11.11/./libgfortran/ /test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/quad_ 2.f90-O0 -pedantic-errors -B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./ libgfortran/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.li bs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs -B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs -lm -o ./quad_2.exe(timeout = 300)/usr/ccs/bin/ld: Unsatisfied symbols: sqrtl (first referenced in /var/tmp//cc8hxOpo.o) (code)collect2: error: ld returned 1 exit statuscompiler exited with status 1output is: /usr/ccs/bin/ld: Unsatisfied symbols: sqrtl (first referenced in /var/tmp//cc8hxOpo.o) (code) collect2: error: ld returned 1 exit status FAIL: gfortran.dg/quad_2.f90 -O0 (test for excess errors)
[Bug target/43437] ICE in CSE, during libgcc build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43437 --- Comment #15 from Thorsten Glaser tg at mirbsd dot org 2011-12-19 00:28:18 UTC --- Hi Mikael, thanks for caring, you seem to be everywhere ;-) Yes, it is reproducible with the cross-compilers I build using the standard procedure from https://wiki.debian.org/BuildingCrossCompilers on amd64. tg@zigo:~ $ m68k-linux-gnu-gcc-4.6 -O2 -c x.i /tmp/buildd/libvirt-0.9.8/./src/conf/domain_conf.c: In function ‘virDomainDefParseXML’: /tmp/buildd/libvirt-0.9.8/./src/conf/domain_conf.c:7939:1: internal compiler error: in cselib_record_set, at cselib.c:2148 Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.6/README.Bugs for instructions. Preprocessed source stored into /tmp/cckdrq16.out file, please attach this to your bugreport. 1|tg@zigo:~ $ m68k-linux-gnu-gcc-4.6 -v Using built-in specs. COLLECT_GCC=m68k-linux-gnu-gcc-4.6 COLLECT_LTO_WRAPPER=/usr/lib/gcc/m68k-linux-gnu/4.6/lto-wrapper Target: m68k-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.2-7' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/m68k-linux-gnu/include/c++/4.6.2 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --disable-libssp --enable-plugin --enable-objc-gc --disable-werror --disable-multilib --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=m68k-linux-gnu --program-prefix=m68k-linux-gnu- --includedir=/usr/m68k-linux-gnu/include --with-headers=/usr/m68k-linux-gnu/include --with-libs=/usr/m68k-linux-gnu/lib Thread model: posix gcc version 4.6.2 (Debian 4.6.2-7)
[Bug libstdc++/50862] deadlock in std::condition_variable_any
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50862 --- Comment #18 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-19 00:34:33 UTC --- Author: redi Date: Mon Dec 19 00:34:29 2011 New Revision: 182467 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182467 Log: PR libstdc++/50862 * include/std/condition_variable (condition_variable_any::wait): Fix deadlock and ensure _Lock::lock() is called on exit. * testsuite/30_threads/condition_variable_any/50862.cc: New. Added: branches/gcc-4_6-branch/libstdc++-v3/testsuite/30_threads/condition_variable_any/50862.cc Modified: branches/gcc-4_6-branch/libstdc++-v3/ChangeLog branches/gcc-4_6-branch/libstdc++-v3/include/std/condition_variable
[Bug libstdc++/50862] deadlock in std::condition_variable_any
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50862 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #19 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-19 00:35:07 UTC --- fixed for 4.6.3
[Bug fortran/51616] [4.7 Regression] gfortran.dg/quad_2.f90 fails on hppa*-*-hpux*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51616 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 2011-12-19 00:55:56 UTC --- (In reply to comment #0) Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran -B /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../ -B/test/gnu/gcc/objdir/hppa2. 0w-hp-hpux11.11/./libgfortran/ /test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/quad_ 2.f90-O0 -pedantic-errors -B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./ libgfortran/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.li bs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs -B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs -lm -o ./quad_2.exe(timeout = 300)/usr/ccs/bin/ld: Unsatisfied symbols: sqrtl (first referenced in /var/tmp//cc8hxOpo.o) (code)collect2: error: ld returned 1 exit statuscompiler exited with status 1output is: /usr/ccs/bin/ld: Unsatisfied symbols: sqrtl (first referenced in /var/tmp//cc8hxOpo.o) (code) collect2: error: ld returned 1 exit status FAIL: gfortran.dg/quad_2.f90 -O0 (test for excess errors) Well, the obvious questions is Does hpux11 have a sqrtl() in libm? Possibly, relates to PR 51057
[Bug fortran/51616] [4.7 Regression] gfortran.dg/quad_2.f90 fails on hppa*-*-hpux*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51616 --- Comment #2 from dave.anglin at bell dot net 2011-12-19 01:03:44 UTC --- On 18-Dec-11, at 7:55 PM, kargl at gcc dot gnu.org wrote: Well, the obvious questions is Does hpux11 have a sqrtl() in libm? No. It only has basic quad arithmetic. Previously, the libquadmath version was used. Possibly, relates to PR 51057 I filed a separate bug because I thought it was a different issue. Dave -- John David Anglindave.ang...@bell.net
[Bug target/51340] SH Target: Make -mfused-madd enabled by default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51340 --- Comment #2 from Oleg Endo oleg.e...@t-online.de 2011-12-19 01:29:12 UTC --- (In reply to comment #1) (In reply to comment #0) Is there any particular reason why this should not be enabled by default for SH targets that support the FMAC insn? PR29100? Uhm, yes... The title should have been Enable -mfused-madd by -ffast-math BTW, if SH fmac satisfies the semantics for fused multiplication and add operation, the fmaf4 instruction pattern would be better now. I don't know the exact semantics for the new patterns. All I know is that rounding is supposed to be done only once after the two operations. This is the case for the SH fmac insn. Not sure whether this is enough though.
[Bug fortran/51616] [4.7 Regression] gfortran.dg/quad_2.f90 fails on hppa*-*-hpux*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51616 --- Comment #3 from Steve Kargl sgk at troutmask dot apl.washington.edu 2011-12-19 01:30:19 UTC --- On Mon, Dec 19, 2011 at 01:03:44AM +, dave.anglin at bell dot net wrote: Possibly, relates to PR 51057 I filed a separate bug because I thought it was a different issue. I said 'related' not 'duplicate'. In both cases, sqrtl() is not found.
[Bug fortran/51616] [4.7 Regression] gfortran.dg/quad_2.f90 fails on hppa*-*-hpux*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51616 --- Comment #4 from John David Anglin danglin at gcc dot gnu.org 2011-12-19 01:45:16 UTC --- Possibly, you referred to the wrong PR. PR 51057 is about the precision of IBM long double.
[Bug libstdc++/51083] TR1 [tr.c99.cmath.over] and C++11 [cmplx.over] overloads not constrained
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51083 --- Comment #19 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-19 01:49:14 UTC --- Author: redi Date: Mon Dec 19 01:49:08 2011 New Revision: 182468 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182468 Log: Backport from mainline 2011-11-13 Paolo Carlini paolo.carl...@oracle.com * include/c_global/cmath (atan2, pow): Simplify constraining on the return type. Backport from mainline 2011-11-12 Jonathan Wakely jwakely@gmail.com PR libstdc++/51083 * include/ext/type_traits.h (__promote): Only define __type member for integral and floating point types, to prevent math functions participating in overload resolution for other types. (__promote_2, __promote_3, __promote_4): Use __promote in default template argument values, so deduction only succeeds for integral and floating point types. * testsuite/26_numerics/cmath/51083.cc: New. * testsuite/26_numerics/complex/51083.cc: New. * testsuite/tr1/8_c_compatibility/cmath/51083.cc: New. * testsuite/tr1/8_c_compatibility/complex/51083.cc: New. Added: branches/gcc-4_6-branch/libstdc++-v3/testsuite/26_numerics/cmath/ branches/gcc-4_6-branch/libstdc++-v3/testsuite/26_numerics/cmath/51083.cc branches/gcc-4_6-branch/libstdc++-v3/testsuite/26_numerics/complex/51083.cc branches/gcc-4_6-branch/libstdc++-v3/testsuite/tr1/8_c_compatibility/cmath/51083.cc branches/gcc-4_6-branch/libstdc++-v3/testsuite/tr1/8_c_compatibility/complex/51083.cc Modified: branches/gcc-4_6-branch/libstdc++-v3/ChangeLog branches/gcc-4_6-branch/libstdc++-v3/include/c_global/cmath branches/gcc-4_6-branch/libstdc++-v3/include/ext/type_traits.h
[Bug libstdc++/51083] TR1 [tr.c99.cmath.over] and C++11 [cmplx.over] overloads not constrained
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51083 --- Comment #20 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-19 01:49:59 UTC --- backported for 4.6.3
[Bug libstdc++/48933] Infinite recursion in tr1/cmath functions with complex parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48933 --- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-19 01:52:05 UTC --- This has also been partially fixed for 4.6.3 by backporting the fix for bug 51083
[Bug fortran/51616] [4.7 Regression] gfortran.dg/quad_2.f90 fails on hppa*-*-hpux*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51616 --- Comment #5 from Steve Kargl sgk at troutmask dot apl.washington.edu 2011-12-19 02:21:34 UTC --- On Mon, Dec 19, 2011 at 01:45:16AM +, danglin at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51616 --- Comment #4 from John David Anglin danglin at gcc dot gnu.org 2011-12-19 01:45:16 UTC --- Possibly, you referred to the wrong PR. PR 51057 is about the precision of IBM long double. Read the entire PR. You'll eventually find the thread starting at http://gcc.gnu.org/ml/fortran/2011-11/msg00051.html hpux11 appears to be yet another OS that has sufficient quad support that gfortran detects a REAL(16) type, but the OS lacks the basic libm functions.
[Bug libstdc++/51609] [C++11] unique_ptrconst T[]::reset rejects cv-compatible argument pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51609 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-19 02:24:24 UTC --- While I agree the code is reasonable, I think an LWG issue is needed, because I don't think GCC's behaviour is in conflict with the standard. I don't read [unique.ptr.runtime] p1 b2 as requiring that cv-qualified types must be accepted. It only says types derived from T are rejected, which GCC does. The standard defines exactly these overloads: void reset(pointer p = pointer()) noexcept; void reset(nullptr_t) noexcept; template class U void reset(U) = delete; and there is nothing in [unique.ptr.runtime.modifiers] to constrain the template.
[Bug c++/51364] C++ interoperability with ISO-C extension DFP types requires explicit typedefs.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51364 --- Comment #10 from Domingo Alvarez mingodad at gmail dot com 2011-12-19 02:25:16 UTC --- Created attachment 26131 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26131 Program to show that gcc doesn't generate good code size Here is a program and a batch file that call gcc to generate executables with different features to show that gcc doesn't generate good code size when it probably can with _Decimal*. There is two source files main.c and printf.c the smallest executable is generated with main.c alone, the biggest executable is generated with main.c and printf.c using _Decimal128 mixed with _Decimal128 and using isnan. gcc -O2 main.c -o smallest.exe - 175KB gcc -O2 -DWITH_DEC128 -DWITH_ISNAN -DWITH_MPRINTF main.c printf.c -o biggest.exe - 2.606KB gcc -O2 -DWITH_MPRINTF main.c printf.c -o optimus.exe - 279KB gcc -O2 -DWITH_DEC128 -DWITH_MPRINTF main.c printf.c -o good.exe - 503KB They make several mixes to show how gcc is generating code sizes to basically the same use of features. My hope is that this will help analyze and find why this happen. The answers to this till now don't seem to be valid/consistent.
[Bug testsuite/51603] ERROR: g++.dg/cpp0x/rv-cast[34].C: syntax error in target selector target c++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51603 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #1 from Hans-Peter Nilsson hp at gcc dot gnu.org 2011-12-19 03:33:06 UTC --- Maybe your expect or Tcl is too old? Minimum requirement is not stated at http://gcc.gnu.org/install/prerequisites.html (itself a bug), but for me, expect-5.43.0-19.fc12.x86_64 and tcl-8.5.7-5.fc12.x86_64 (in Fedora version parlance, with base version numbers as obvious) works for me.
[Bug testsuite/51128] [4.7 Regression] New LTO failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51128 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #4 from Hans-Peter Nilsson hp at gcc dot gnu.org 2011-12-19 03:47:00 UTC --- (In reply to comment #3) Fixed. A better fix is outlined in my comment to the original post of this patch at http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01998.html, with my patch referring to http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01917.html (since long committed).
[Bug c++/51617] New: [C++0x] async(f) isn't.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51617 Bug #: 51617 Summary: [C++0x] async(f) isn't. Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: d...@boostpro.com Created attachment 26132 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26132 demonstration I am finding I have to explicitly pass a launch policy to get async to run anything in a thread. For example, when I time the attached with -DFORCE_PARALLEL I get /tmp/tst 81.54s user 0.23s system 628% cpu 13.001 total and without it I get: /tmp/tst 41.29s user 0.05s system 99% cpu 41.343 total See also bug 49204
[Bug c++/51617] [C++0x] async(f) isn't.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51617 --- Comment #1 from Dave Abrahams dave at boostpro dot com 2011-12-19 05:11:20 UTC --- I should add this (non-normative, but still) note from [futures.async]: [ Note: If this policy is specified together with other policies, such as when using a policy value of launch::async | launch::deferred, implementations should defer invocation or the selection of the policy when no more concurrency can be effectively exploited. — end note ]
[Bug c++/51489] constexpr not working consistently
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51489 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-12-19 05:57:58 UTC --- Author: jason Date: Mon Dec 19 05:57:52 2011 New Revision: 182470 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182470 Log: PR c++/51489 * semantics.c (cxx_eval_outermost_constant_expr): Check for conversion from pointer to integer here. (cxx_eval_constant_expression) [NOP_EXPR]: Not here. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-ptrsub.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug c++/51489] constexpr not working consistently
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51489 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2011-12-19 05:58:26 UTC --- Fixed.
[Bug libstdc++/51618] New: synchronous futures are slow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51618 Bug #: 51618 Summary: synchronous futures are slow Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: d...@boostpro.com Created attachment 26133 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26133 demo The attached program demonstrates; if you compile with -DNO_SYNCHRONOUS_FUTURE it will run much faster. I don't know if this should be considered a performance bug or not, but it seems to me that in principle it should be possible to make synchronous futures much faster than that; they could type-erase an object with no attached synchronization, right?
[Bug libstdc++/51609] [C++11] unique_ptrconst T[]::reset rejects cv-compatible argument pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51609 --- Comment #3 from Daniel Krügler daniel.kruegler at googlemail dot com 2011-12-19 07:07:52 UTC --- (In reply to comment #2) While I agree the code is reasonable, I think an LWG issue is needed, because I don't think GCC's behaviour is in conflict with the standard. I agree, my argumentation was solely based on the text and I overlooked the difference in the signatures in the class synopsis. So, this issue should be closed as invalid.
[Bug c++/51619] New: [c++0x] [4.6/4.7 Regression] ICE with array class member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51619
Bug #: 51619
Summary: [c++0x] [4.6/4.7 Regression] ICE with array class
member
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reich...@gcc.gnu.org
The following valid code snippet triggers an ICE since GCC 4.6.0 when compiled
with -std=c++0x:
===
struct A
{
virtual ~A();
};
struct B
{
A a[1][1];
};
B b;
===
bug.cc:11:3: in constexpr expansion of 'b.B::B()'
bug.cc:11:3: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
[Bug c++/51619] [c++0x] [4.6/4.7 Regression] ICE with array class member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51619 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |4.6.3
[Bug c++/51620] New: [c++0x] [4.6/4.7 Regression] ICE with private destructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51620
Bug #: 51620
Summary: [c++0x] [4.6/4.7 Regression] ICE with private
destructor
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reich...@gcc.gnu.org
The following invalid code snippet triggers an ICE since GCC 4.6.0 when
compiled with -std=c++0x:
===
templateint class A
{
virtual ~A();
};
struct B : A0, A1
{
B() {}
};
===
bug.cc:6:8: error: deleted function 'virtual B::~B()'
bug.cc:3:11: error: overriding non-deleted function 'Aanonymous ::~A()
[with int anonymous = 0]'
bug.cc:6:8: note: 'virtual B::~B()' is implicitly deleted because the default
definition would be ill-formed:
bug.cc:3:11: error: 'Aanonymous ::~A() [with int anonymous = 0]' is
private
bug.cc:6:8: error: within this context
bug.cc:3:11: error: 'Aanonymous ::~A() [with int anonymous = 1]' is
private
bug.cc:6:8: error: within this context
bug.cc:6:8: error: deleted function 'virtual B::~B()'
bug.cc:3:11: error: overriding non-deleted function 'Aanonymous ::~A()
[with int anonymous = 1]'
bug.cc: In constructor 'B::B()':
bug.cc:3:11: error: 'Aanonymous ::~A() [with int anonymous = 0]' is
private
bug.cc:8:7: error: within this context
bug.cc:3:11: error: 'Aanonymous ::~A() [with int anonymous = 1]' is
private
bug.cc:8:7: error: within this context
bug.cc: At global scope:
bug.cc:9:2: error: use of deleted function 'virtual B::~B()'
bug.cc:9:2: error: use of deleted function 'virtual B::~B()'
bug.cc:9:2: error: use of deleted function 'virtual B::~B()'
bug.cc:9:2: error: use of deleted function 'void B::_ZThn4_N1BD1Ev()'
bug.cc:6:8: note: 'void B::_ZThn4_N1BD1Ev()' is implicitly deleted because the
default definition would be ill-formed:
bug.cc:6:8: internal compiler error: in synthesized_method_walk, at
cp/method.c:1168
Please submit a full bug report, [etc.]
In addition, the first part of the message is duplicated, use of deleted
function 'virtual B::~B()' appears 3 times, and B::_ZThn4_N1BD1Ev() is not
very meaningful to the user.
[Bug c++/51620] [c++0x] [4.6/4.7 Regression] ICE with private destructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51620 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic, error-recovery, ||ice-on-invalid-code Target Milestone|--- |4.6.3
[Bug bootstrap/48135] build fails on Solaris2.8 due to Glob.pm not found within /usr/perl5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48135 --- Comment #26 from Denis Excoffier g...@denis-excoffier.org 2011-12-19 07:36:33 UTC --- Just for the record: gcc-4.7-20111210 works (with --enable-obsolete of course).
[Bug c++/51621] New: [c++0x] [4.6/4.7 Regression] ICE with invalid constexpr and array class member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51621
Bug #: 51621
Summary: [c++0x] [4.6/4.7 Regression] ICE with invalid
constexpr and array class member
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reich...@gcc.gnu.org
The following invalid code snippet triggers an ICE since GCC 4.6.0:
struct A
{
A() {}
};
struct B
{
A a[1];
constexpr B() : a() {}
};
bug.cc: In constructor 'B::B()':
bug.cc:9:24: error: non-constant array initialization
bug.cc:9:24: internal compiler error: in build_vec_init_elt, at cp/tree.c:485
Please submit a full bug report, [etc.]
In GCC 4.5.x, the code was wrongly accepted.
[Bug c++/51621] [c++0x] [4.6/4.7 Regression] ICE with invalid constexpr and array class member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51621 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Keywords||error-recovery, ||ice-on-invalid-code Target Milestone|--- |4.6.3
