[Bug c++/54021] [c++0x] __builtin_constant_p should be constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54021 --- Comment #7 from David Stone david at doublewise dot net 2012-09-09 06:00:37 UTC --- That seems to me like saying that `constexpr bool d = sizeof(x);` should be disallowed because it uses a non-constexpr. You're not using the value of x, just a property about it. Whether a value is constexpr is guaranteed to be known at compile time, and so should be usable as a constexpr.
[Bug c++/54021] [c++0x] __builtin_constant_p should be constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54021 --- Comment #8 from Andy Lutomirski luto at mit dot edu 2012-09-09 06:05:34 UTC --- Did you mean constexpr bool a instead of book const a? If so, I agree. But consider: bool const a = something complicated Is a a constant?
[Bug debug/54533] breakpoint on C-style variadic function not hit at -O0 on amd64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54533 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-09-09 07:01:52 UTC --- I have seen a bug about this before but I cannot find it. It only happen on x86_64 as al tells the function if it uses floating point arguments or not. It might be a bug in gdb in figuring out the prologue of the function too.
[Bug debug/54533] breakpoint on C-style variadic function not hit at -O0 on amd64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54533 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-09-09 07:12:07 UTC --- Looks like powerpc has the same issue: http://sourceware.org/ml/gdb/2009-01/msg00161.html
[Bug debug/54533] breakpoint on C-style variadic function not hit at -O0 on amd64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54533 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-09-09 07:17:00 UTC --- (In reply to comment #2) Looks like powerpc has the same issue: http://sourceware.org/ml/gdb/2009-01/msg00161.html Which has a patch: http://gcc.gnu.org/ml/gcc-patches/2009-02/msg01213.html Though I don't know what happened to that. Though it does look there is a target specific part to it.
[Bug c++/54527] wcout breaks on win32 console
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54527 vurentjie vurentjie at gmail dot com changed: What|Removed |Added Severity|blocker |enhancement
[Bug c++/54527] wcout breaks on win32 console
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54527 vurentjie vurentjie at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from vurentjie vurentjie at gmail dot com 2012-09-09 07:25:24 UTC --- nevermind
[Bug debug/54534] New: [4.7 Regression] Missing location for unused variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54534 Bug #: 54534 Summary: [4.7 Regression] Missing location for unused variable Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: jan.kratoch...@redhat.com Target: x86_64-unknown-linux-gnu static int i; gcc -c -Wall -g 13.c:1:12: warning: ‘i’ defined but not used [-Wunused-variable] PASS: gcc (GCC) 4.5.4 PASS: gcc (GCC) 4.6.4 20120909 (prerelease) PASS: gcc (GCC) 4.8.0 20120909 (experimental) 12d: Abbrev Number: 2 (DW_TAG_variable) 2e DW_AT_name: i 30 DW_AT_decl_file : 1 31 DW_AT_decl_line : 1 32 DW_AT_type: 0x40 36 DW_AT_location: 9 byte block: 3 0 0 0 0 0 0 0 0 (DW_OP_addr: 0) (gdb) p i $1 = 0 FAIL: gcc (GCC) 4.7.2 20120909 (prerelease) 11d: Abbrev Number: 2 (DW_TAG_variable) 1e DW_AT_name: i 20 DW_AT_decl_file : 1 21 DW_AT_decl_line : 1 22 DW_AT_type: 0x26 (gdb) p i No symbol i in current context. Regression: 2012-09-07 - 2012-09-08 It breaks GDB several testfiles such as: gdb.base/memattr.exp
[Bug pch/39618] trunk revision 145459 - The configure of libstdc++-v3 hangs while checking for PCH support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39618 kettenis at gnu dot org changed: What|Removed |Added CC||kettenis at gnu dot org --- Comment #6 from kettenis at gnu dot org 2012-09-09 08:44:02 UTC --- This is fixed by the following commit. Turns out it is possible to use a carefully chosen address to get PCH working reliably, so I did go for that approach since it has a chance to work if GCC is compiled as a position independent executable as well. 2012-09-02 Mark Kettenis kette...@openbsd.org * config.gcc (x86_64-*-openbsd*): New target. * config.host (*-*-openbsd*): New target. * config/openbsd.h (TARGET_C99_FUNCTIONS): Define. * config/i386/openbsdelf.h: Remove some superfluous defines and group things together in a more logical fashion. (DBX_REGISTER_NUMBER): Provide a definition that works on both 32-bit and 64-bit targets. (WCHAR_TYPE_SIZE): Hardcode as 32. (NO_DOLLAR_IN_LABEL): Remove undef. (TARGET_DEFAULT): Remove. (SET_ASM_OP): Remove. (DEFAULT_PCC_STRUCT_RETURN): Undef first to prevent warning. (ASM_OUTPUT_MAX_SKIP_ALIGN): Synch with x86-64.h (DWARF2_UNWIND_INFO): Remove define. (HAVE_ENABLE_EXECUTE_STACK): Define. * config/host-openbsd.c: New file. * config/t-openbsd (USER_H): Add EXTRA_HEADERS. * config/x-openbsd: New file.
[Bug target/54531] vpermilpd(x, 2 or 10) is a move
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54531 --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org 2012-09-09 09:30:57 UTC --- As a side note, is there a reason to prefer vpermpd to vpermilpd when both are available (apart from the fact that they are written in that order in the .md file)? I would expect that by default we take the intra-lane version, which in theory could be cheaper on some machines. I guess in practice they are equivalent and it doesn't matter...
[Bug tree-optimization/54505] RFE: Inline function tables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54505 --- Comment #4 from Avi Kivity avi at redhat dot com 2012-09-09 11:12:53 UTC --- (In reply to comment #2) I don't think this transformation would always be an improvement. gcc should make the transformation when it improves the code (like all other transformations). Had a developer wanted to use a switch, I'd think he/she would have used one. A dispatch table is much more code-size efficient compared to a switch. gcc often transforms a switch to a dispatch table, with the difference that the function call convention is not used. Instead, register values are maintained across the call, and instead of call/ret, jmp/jmp (on x86) are used. gcc should allow the programmer to write the code in the cleanest way, and transform it to the most performing way. In the same way that gcc converts some multiplies to a shift, it should convert some indirect function calls to a non-function dispatch table. It's inlining but on a larger scale.
[Bug target/29845] sh floating point emulation is inefficient
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29845 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added CC||olegendo at gcc dot gnu.org --- Comment #8 from Oleg Endo olegendo at gcc dot gnu.org 2012-09-09 11:22:33 UTC --- Just for the record, a rather recent discussion on the issue: Original thread start: http://gcc.gnu.org/ml/gcc/2010-06/msg00388.html Continuation: http://gcc.gnu.org/ml/gcc/2010-07/msg00250.html Continuation: http://gcc.gnu.org/ml/gcc/2010-08/msg00044.html Aggregated version: http://www.mentby.com/Group/gcc-discuss/sh-optimized-software-floating-point-routines.html
[Bug libstdc++/54530] [4.8 regression] error: std::piecewise_construct causes a section type conflict with std::piecewise_construct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54530 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|aaw at google dot com, | |fdumont at gcc dot gnu.org | Resolution||DUPLICATE --- Comment #2 from Andreas Schwab sch...@linux-m68k.org 2012-09-09 11:44:55 UTC --- Apparently a dup. *** This bug has been marked as a duplicate of bug 53475 ***
[Bug libstdc++/54451] c++11/random.cc build failure when _GLIBCXX_USE_C99_STDINT_TR1 is not defined in config.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54451 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||drepper.fsp at gmail dot ||com --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-09-09 11:44:45 UTC --- If it's not defined, it means that the configure time tests fails because the target doesn't support the feature. In general - even for stdint which is supported by most targets now - we should simply make sure that the build works in both cases, simply the random features may end up not being available. Adding Ulrich in CC, something needs tweaking in his recent work.
[Bug c++/53475] [4.8 Regression] Section type conflict errors in libstdc++ testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53475 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added CC||sch...@linux-m68k.org --- Comment #8 from Andreas Schwab sch...@linux-m68k.org 2012-09-09 11:44:55 UTC --- *** Bug 54530 has been marked as a duplicate of this bug. ***
[Bug libstdc++/54451] c++11/random.cc build failure when _GLIBCXX_USE_C99_STDINT_TR1 is not defined in config.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54451 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-09 Ever Confirmed|0 |1 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2012-09-09 11:50:18 UTC --- (In reply to comment #0) Commenting out '#ifdef _GLIBCXX_USE_C99_STDINT_TR1' fixed build problem, but I'm not sure that it is correct solution. It's not. (In reply to comment #1) etc. Those are the only uses of it in code that I can find. It's used in many more headers. It seems like it isn't exactly the best name for the define (it no longer just applies to TR1), but it doesn't do too much. I can't think of a case where this would not be desired behavior (I don't remember, but I *think* that the C++ standard says that those typenames should be in the standard namespace). But the C standard requires stdint.h and if the OS doesn't provide that we can't provide a useful cstdint. Anyway, it doesn't appear like removing that code will have any adverse effects. It would completely break libstdc++ on platforms without stdint.h, such as djgpp The fix is simply to check for the macro in random.cc index 50b5359..1d0723d 100644 --- a/libstdc++-v3/src/c++11/random.cc +++ b/libstdc++-v3/src/c++11/random.cc @@ -24,6 +24,8 @@ #include random +#ifdef _GLIBCXX_USE_C99_STDINT_TR1 + #if defined __i386__ || defined __x86_64__ # include cpuid.h #endif @@ -142,5 +144,5 @@ namespace std _GLIBCXX_VISIBILITY(default) 0xUL, 7, 0x9d2c5680UL, 15, 0xefc6UL, 18, 1812433253UL; - } +#endif
[Bug c++/54532] [C++0x][constexpr] internal error when initializing static constexpr with pointer to non-static member variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54532 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-09 Ever Confirmed|0 |1 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-09-09 12:01:29 UTC --- also ICEs on trunk
[Bug pch/39618] trunk revision 145459 - The configure of libstdc++-v3 hangs while checking for PCH support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39618 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2012-09-09 12:02:53 UTC --- Thanks, closing then
[Bug c++/54535] New: gcc fails to warn when functions are inlined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54535
Bug #: 54535
Summary: gcc fails to warn when functions are inlined
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: da...@doublewise.net
#include iostream
namespace {
static void f(bool condition) {
volatile int const x = (__builtin_constant_p(condition) ? (1 /
(condition)) : 0); \
}
}
int main() {
f(false);
}
I compile this with -Werror=div-by-zero, and I do not get any warnings while
compiling. Instead, I get Floating point exception (core dumped) when I
attempt to run it.
The same sort of thing happens with other situations that should be warned
about, such as indexing an array with a negative number. I do get a warning if
I manually inline the call to f or make it a macro.
gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.7.0/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --disable-build-with-cxx
--disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.7.0 20120507 (Red Hat 4.7.0-5) (GCC)
[Bug fortran/54522] Using g77 -O -fno-automatic, reassignment of a variable in an if statement in a function triggers a compiler bug.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54522 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #2 from janus at gcc dot gnu.org 2012-09-09 14:48:16 UTC --- (In reply to comment #1) g77 is no longer supported. gfortran, which is g77's successor, does not seem to have any trouble with your test case (I tried versions 4.3, 4.6, 4.7 and trunk). Please consider upgrading to gfortran.
[Bug target/54536] New: [avr]: incorrect crt with -mmcu=at90usb1287
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54536 Bug #: 54536 Summary: [avr]: incorrect crt with -mmcu=at90usb1287 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: michael.schaenz...@nurfuerspam.de The avr-gcc driver is linking against crtusb1286.o when using the mcu option -mmcu=at90usb1287. It should use crtusb1287.o instead. Since crtusb1286.o and crtusb1287.o are identical this is ok for the default avr-libc multilib setup but causes problems with non-standard build systems (e.g. device specific builds).
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419 --- Comment #55 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-09-09 15:21:45 UTC --- (In reply to comments #53 and #54) Please post the patch to the right list and I'll approve it, all libstdc++ patches need to go to the libstdc++ list. I've tested the patch myself now, it's ok, please commit it asap (but in future remember to send patches to the libstdc++ list as well as gcc-patches, I could have approved it sooner had I seen it) I'ld to make a few comments: (1) A new patch has been posted at http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00466.html to fix a typo in my email address. (2) Jack Howarth does not seem to be around. So if someone with write access care about ASAP, he(r)? may commit the last version. (3) Jack has posted five revisions of the patch: http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00409.html http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00416.html http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00421.html http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00465.html http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00466.html following the request made at http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00411.html http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00417.html http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00418.html http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00432.html followed by a last post http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00499.html AFAICT nobody has been asking to cross post to libstdc++. (4) Managing libstdc++ on a specific mailing list made sense when G++ was an optional component of GCC. Now that C++, hence libstdc++, is mandatory, I think this policy should be revised: - the final patch should be posted and approved on gcc-patc...@gcc.gnu.org; - the libstdc++ maintainers should be more careful: four bootstrap failures caused by a single commit is way to much; - the libstdc++ maintainers should be more responsive: more than ten days to fix a bootstrap failure on primary platforms is way too long.
[Bug fortran/54522] Using g77 -O -fno-automatic, reassignment of a variable in an if statement in a function triggers a compiler bug.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54522 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-09-09 15:27:29 UTC --- The test case with -O -fno-automatic compiles on powerpc-apple-darwin9 with gcc 3.4.3.
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419 --- Comment #56 from Paolo Carlini paolo.carlini at oracle dot com 2012-09-09 16:14:41 UTC --- I suppose that the lack of responsiveness may be ultimately due to the fact that the issue only shows up on some specific systems (that is, those using old assemblers) which normally the maintainers (in general, not just the library ones) working on mainline GCC don't develop on and don't assume are the reference systems on which the next release series will be eventually primarily installed. Indeed, if you look at gcc-patches it's pretty obvious that the development of GCC mainline proceeded quite normally, and, at this stage at least, this is what *really* counts.
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419 --- Comment #57 from Jonathan Wakely redi at gcc dot gnu.org 2012-09-09 16:18:12 UTC --- (In reply to comment #55) (1) A new patch has been posted at http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00466.html to fix a typo in my email address. But not to a list I actually read. (2) Jack Howarth does not seem to be around. So if someone with write access care about ASAP, he(r)? may commit the last version. I'll do it today. AFAICT nobody has been asking to cross post to libstdc++. See http://gcc.gnu.org/contribute.html#patches and http://gcc.gnu.org/lists.html Patches to libstdc++-v3 should be sent to both this list and gcc-patches. That is the standard policy, that's true whether or not anyone noticed the policy wasn't followed or pointed it out. Anyway, I'm asking now. Please follow the policy in future if you want me to review libstdc++ patches. (4) Managing libstdc++ on a specific mailing list made sense when G++ was an optional component of GCC. Now that C++, hence libstdc++, is mandatory, I think this policy should be revised: - the final patch should be posted and approved on gcc-patc...@gcc.gnu.org; No, it should go to both. I don't want to subscribe to gcc-patches to review just the libstdc++ patches, and I doubt everyone subscribed to g...@gcc.gnu.org wants to read discussion of e.g. the C++11 standard library components (which aren't used by the rest of GCC.) If patches are sent to both lists I can reply-to-all and the approval and review will be sent to both lists. I see no reason to change that policy. In any case, changing policies should be discussed on the gcc list, not in bugzilla. - the libstdc++ maintainers should be more careful: four bootstrap failures caused by a single commit is way to much; - the libstdc++ maintainers should be more responsive: more than ten days to fix a bootstrap failure on primary platforms is way too long. Myself and Paolo were both travelling for the past week, so we were less responsive than normal. If the patch had been posted to the right list I would have reviewed the patch while on holiday, but I didn't even realise there was a patch to fix it because it wasn't sent to the list I read (I was surprised when I got back from holiday to find the change hadn't been reverted after the 48 hour countdown was started.)
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419 --- Comment #58 from Jonathan Wakely redi at gcc dot gnu.org 2012-09-09 16:21:25 UTC --- (In reply to comment #56) I suppose that the lack of responsiveness may be ultimately due to the fact that the issue only shows up on some specific systems (that is, those using old assemblers) which normally the maintainers (in general, not just the library ones) working on mainline GCC don't develop on The fact the build was broken on the compile farm machines would normally be an issue for me, but as I was on holiday I wasn't building gcc. As soon as I tried to build on the compile farm I found the PR and reviewed the patch. Again, if it had been sent to the right list I could have done that sooner, instead of waiting until the bug affected me directly.
[Bug libstdc++/54451] c++11/random.cc build failure when _GLIBCXX_USE_C99_STDINT_TR1 is not defined in config.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54451 --- Comment #4 from Andris Pavenis andris.pavenis at iki dot fi 2012-09-09 16:47:44 UTC --- My test was done with DJGPP development version (2.04) only. It has stdint.h, but it was recognized by configure as unusable due to bug unrelated to GCC itself. After fixing this problem locally libstdc++-v3 builds OK for DJGPP v2.04 (only tested cross-native build from Linux) Stable version DJGPP v2.03 does not have stdint.h As the result I agree with the suggestion in comment 3 to completely disable random.cc when _GLIBCXX_USE_C99_STDINT_TR1 is not defined Maybe it would be nice to use #error in header file to inform the user that this feature is not supported for target system (nicer than to get linker error later)
[Bug c++/54021] [c++0x] __builtin_constant_p should be constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54021 --- Comment #9 from Jason Merrill jason at gcc dot gnu.org 2012-09-09 16:48:46 UTC --- (In reply to comment #5) // This causes error: the value of 'x' is not usable in a constant expression constexpr bool c = __builtin_constant_p(x); } This is also fixed by my patch.
[Bug libstdc++/54451] c++11/random.cc build failure when _GLIBCXX_USE_C99_STDINT_TR1 is not defined in config.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54451 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2012-09-09 17:19:44 UTC --- (In reply to comment #4) Maybe it would be nice to use #error in header file to inform the user that this feature is not supported for target system (nicer than to get linker error later) You won't get a linker error, if the macro is not defined then the types in random are not declared, so code using them won't compile. Using #error would prevent #include random which I don't think is a good idea. There's no harm including the header as long as you don't try to use types which require a working stdint.h The fix is to simply make random.cc check the macro. This is what we already do in future.cc and thread.cc and mutex.cc and other files too.
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419 --- Comment #59 from Jonathan Wakely redi at gcc dot gnu.org 2012-09-09 17:20:47 UTC --- Author: redi Date: Sun Sep 9 17:20:42 2012 New Revision: 19 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=19 Log: 2012-09-09 Ulrich Drepper drep...@gmail.com Dominique d'Humieres domi...@lps.ens.fr Jack Howarth howa...@bromo.med.uc.edu PR bootstrap/54419 * acinclude.m4: Define GLIBCXX_CHECK_X86_RDRAND. * configure.ac: Use GLIBCXX_CHECK_X86_RDRAND to test for rdrand support in assembler. * src/c++11/random.cc (__x86_rdrand): Depend on _GLIBCXX_X86_RDRAND. (random_device::_M_init): Likewise. (random_device::_M_getval): Likewise. * configure: Regenerated. * config.h.in: Regenerated. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/config.h.in trunk/libstdc++-v3/configure trunk/libstdc++-v3/configure.ac trunk/libstdc++-v3/src/c++11/random.cc
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #60 from Jonathan Wakely redi at gcc dot gnu.org 2012-09-09 17:30:30 UTC --- patch committed
[Bug c++/54537] New: undiagnosed using-declaration conflicting with used function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54537
Bug #: 54537
Summary: undiagnosed using-declaration conflicting with used
function
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: fab...@gcc.gnu.org
Noticed while working on DR39, the below is wrongly accepted. A diagnostic is
issued if the function f is not used.
namespace a
{
void f(int);
}
namespace b
{
void f(int);
void g()
{
f (3);
}
using a::f; // { dg-error already declared }
}
I have a patch for it.
[Bug c++/54537] undiagnosed using-declaration conflicting with used function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54537 fabien at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-09-09 AssignedTo|unassigned at gcc dot |fabien at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 Known to fail||4.6.3, 4.8.0
[Bug libstdc++/54388] [4.7/4.8 Regression] std::array.at() const results in undefined behaviour
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54388
--- Comment #13 from Jonathan Wakely redi at gcc dot gnu.org 2012-09-09
17:56:15 UTC ---
(In reply to comment #10)
Can the compiler warn about the original (buggy) code?
It already does:
c.cc: In function ‘A get(int)’:
c.cc:3:43: error: invalid initialization of non-const reference of type ‘A’
from an rvalue of type ‘A’
A get(int i) { return i == 0 ? a : throw 1; }
^
But warnings are suppressed in system headers.
[Bug libstdc++/54388] [4.7/4.8 Regression] std::array.at() const results in undefined behaviour
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54388
--- Comment #13 from Jonathan Wakely redi at gcc dot gnu.org 2012-09-09
17:56:15 UTC ---
(In reply to comment #10)
Can the compiler warn about the original (buggy) code?
It already does:
c.cc: In function ‘A get(int)’:
c.cc:3:43: error: invalid initialization of non-const reference of type ‘A’
from an rvalue of type ‘A’
A get(int i) { return i == 0 ? a : throw 1; }
^
But warnings are suppressed in system headers.
--- Comment #14 from Jonathan Wakely redi at gcc dot gnu.org 2012-09-09
17:56:56 UTC ---
Author: redi
Date: Sun Sep 9 17:56:51 2012
New Revision: 191114
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191114
Log:
PR libstdc++/54388
* include/std/array (array::at() const): Ensure lvalue result.
* testsuite/23_containers/array/element_access/54388.cc: New.
* testsuite/23_containers/array/tuple_interface/get_neg.cc: Adjust
dg-error line numbers.
* testsuite/23_containers/array/tuple_interface/tuple_element_neg.cc:
Likewise.
Added:
trunk/libstdc++-v3/testsuite/23_containers/array/element_access/54388.cc
- copied, changed from r191113,
trunk/libstdc++-v3/testsuite/23_containers/array/tuple_interface/tuple_element_neg.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/array
trunk/libstdc++-v3/testsuite/23_containers/array/tuple_interface/get_neg.cc
trunk/libstdc++-v3/testsuite/23_containers/array/tuple_interface/tuple_element_neg.cc
[Bug libstdc++/54451] c++11/random.cc build failure when _GLIBCXX_USE_C99_STDINT_TR1 is not defined in config.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54451 --- Comment #6 from rbmj at verizon dot net 2012-09-09 18:08:11 UTC --- Making local changes to bring stdint.h into compliance works for me as well. (In reply to comment #5) (In reply to comment #4) Maybe it would be nice to use #error in header file to inform the user that this feature is not supported for target system (nicer than to get linker error later) You won't get a linker error, if the macro is not defined then the types in random are not declared, so code using them won't compile. However, you will get weird std::random_device not declared errors, which will seem strange to any end user. Using #error would prevent #include random which I don't think is a good idea. There's no harm including the header as long as you don't try to use types which require a working stdint.h Agreed. But could we use #warning to tell the user what's happening (if portability is an issue we can check for __GNUC__) without going through the source? The fix is to simply make random.cc check the macro. This is what we already do in future.cc and thread.cc and mutex.cc and other files too. Also true.
[Bug libstdc++/54451] c++11/random.cc build failure when _GLIBCXX_USE_C99_STDINT_TR1 is not defined in config.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54451 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2012-09-09 18:18:32 UTC --- No, it should be consistent with how it's handled everywhere else.
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419 --- Comment #61 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-09-09 18:17:09 UTC --- patch committed Thanks.
[Bug libstdc++/54388] [4.7/4.8 Regression] std::array.at() const results in undefined behaviour
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54388 --- Comment #15 from Jonathan Wakely redi at gcc dot gnu.org 2012-09-09 18:40:50 UTC --- Author: redi Date: Sun Sep 9 18:40:46 2012 New Revision: 191117 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191117 Log: PR libstdc++/54388 * include/std/array (array::at() const): Ensure lvalue result. * testsuite/23_containers/array/element_access/54388.cc: New. Added: branches/gcc-4_7-branch/libstdc++-v3/testsuite/23_containers/array/element_access/54388.cc Modified: branches/gcc-4_7-branch/libstdc++-v3/ChangeLog branches/gcc-4_7-branch/libstdc++-v3/include/std/array
[Bug libstdc++/54388] [4.7/4.8 Regression] std::array.at() const results in undefined behaviour
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54388 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #16 from Jonathan Wakely redi at gcc dot gnu.org 2012-09-09 18:44:59 UTC --- fixed
[Bug c++/54538] New: Getting assembler messages when compiling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54538
Bug #: 54538
Summary: Getting assembler messages when compiling
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: leo...@volnitsky.com
Created attachment 28157
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28157
scc.ii
I am getting Assembler Messages below from gcc-4.8 when compiling my code.
scc.ii file is attached (original code -- https://github.com/lvv/scc ). I can
successfully compile if I will use gcc-3.7.1.
Error Messages:
---
{standard input}: Assembler messages:
{standard input}:12769: Error: symbol
`_ZNK3sto11chain_rangeIT_E12default_predMUlRKiE_clES4_' is already defined
{standard input}:17883: Error: symbol
`_ZSt4moveIRN3sto11chain_rangeIT_E12default_predMUlRKiE_EEONSt16remove_referenceIS2_E4typeEOS2_'
is already defined
{standard input}:17903: Error: symbol
`_ZNSt8functionIFbRKiEEC2IN3sto11chain_rangeIT_E12default_predMUlS1_E_EvEET_'
is already defined
{standard input}:23564: Error: symbol
`_ZNSt14_Function_base13_Base_managerIN3sto11chain_rangeIT_E12default_predMUlRKiE_EE21_M_not_empty_functionIS7_EEbRKT_'
is already defined
{standard input}:23583: Error: symbol
`_ZNSt17_Function_handlerIFbRKiEN3sto11chain_rangeIT_E12default_predMUlS1_E_EE9_M_invokeERKSt9_Any_dataS1_'
is already defined
{standard input}:23617: Error: symbol
`_ZNSt14_Function_base13_Base_managerIN3sto11chain_rangeIT_E12default_predMUlRKiE_EE10_M_managerERSt9_Any_dataRKS9_St18_Manager_operation'
is already defined
{standard input}:23722: Error: symbol
`_ZNSt14_Function_base13_Base_managerIN3sto11chain_rangeIT_E12default_predMUlRKiE_EE15_M_init_functorERSt9_Any_dataOS7_'
is already defined
{standard input}:28014: Error: symbol
`_ZNSt14_Function_base13_Base_managerIN3sto11chain_rangeIT_E12default_predMUlRKiE_EE14_M_get_pointerERKSt9_Any_data'
is already defined
{standard input}:28040: Error: symbol
`_ZNSt9_Any_data9_M_accessIPN3sto11chain_rangeIT_E12default_predMUlRKiE_EEERS3_v'
is already defined
{standard input}:28062: Error: symbol
`_ZNSt14_Function_base13_Base_managerIN3sto11chain_rangeIT_E12default_predMUlRKiE_EE8_M_cloneERSt9_Any_dataRKS9_St17integral_constantIbLb0EE'
is already defined
{standard input}:28096: Error: symbol
`_ZNSt14_Function_base13_Base_managerIN3sto11chain_rangeIT_E12default_predMUlRKiE_EE10_M_destroyERSt9_Any_dataSt17integral_constantIbLb0EE'
is already defined
{standard input}:28121: Error: symbol
`_ZNSt14_Function_base13_Base_managerIN3sto11chain_rangeIT_E12default_predMUlRKiE_EE15_M_init_functorERSt9_Any_dataOS7_St17integral_constantIbLb0EE'
is already defined
{standard input}:31822: Error: symbol
`_ZNKSt9_Any_data9_M_accessIPN3sto11chain_rangeIT_E12default_predMUlRKiE_EEERKS3_v'
is already defined
--
Compiled with:
g++ -std=gnu++11 -Wall -pipe -Wno-sign-compare -I /home/lvv/p/ -include debug.h
-Wno-unused-function -I /home/lvv/p/scc -I /home/lvv/p -include
/home/lvv/p/scc/.scc.h /home/lvv/p/scc/scc.cc -o /tmp/lvv-scc
GCC version:
gcc -v
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0-pre/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.0-pre/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.8.0_pre/work/gcc-4.8.0-/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0-pre
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-pre/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-pre/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --with-ppl --with-cloog --disable-ppl-version-check
--with-cloog-include=/usr/include/cloog-ppl --enable-lto --enable-nls
--without-included-gettext --with-system-zlib --enable-obsolete
--disable-werror --enable-secureplt --enable-multilib
--with-multilib-list=m32,m64 --enable-libmudflap --disable-libssp
--enable-libgomp
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre/python
--enable-checking=release --disable-libgcj --enable-languages=c,c++,go,fortran
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-targets=all --with-bugurl=http://bugs.gentoo.org/
--with-pkgversion='Gentoo 4.8.0_pre'
Thread model: posix
gcc version 4.8.0-pre 20120820 (experimental) commit
2bf99680c2012de150798c933642aa4c82a85410 (Gentoo 4.8.0_pre)
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419 --- Comment #62 from Jonathan Wakely redi at gcc dot gnu.org 2012-09-09 19:46:45 UTC --- Author: redi Date: Sun Sep 9 19:46:41 2012 New Revision: 191119 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191119 Log: PR bootstrap/54419 * acinclude.m4 (GLIBCXX_CHECK_X86_RDRAND): Remove stray character. * configure: Regenerated. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/configure
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419 --- Comment #63 from Jonathan Wakely redi at gcc dot gnu.org 2012-09-09 20:45:11 UTC --- (In reply to comment #55) AFAICT nobody has been asking to cross post to libstdc++. Also see comment 40, before the first patch.
[Bug c++/54506] Defaulted move constructors and move assignment operators are erroneously defined as deleted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54506
--- Comment #3 from Nikolka tsoae at mail dot ru 2012-09-09 20:55:38 UTC ---
g++ v4.7.2 20120908 (prerelease) compiles the original example successfully,
but it fails to compile the following code:
template class T
struct A
{
A() {}
A(A const volatile ) = delete;
A operator =(A const volatile ) = delete;
template class U
A(AU ) {}
template class U
A operator =(AU ) { return *this; }
};
struct B
{
Aint a;
B() = default;
};
int main()
{
B b = B();
b = B();
}
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=../target --enable-languages=c,c++
Thread model: posix
gcc version 4.7.2 20120908 (prerelease) (GCC)
COLLECT_GCC_OPTIONS='-v' '-std=c++11' '-shared-libgcc' '-mtune=generic'
'-march=pentiumpro'
../target/libexec/gcc/i686-pc-linux-gnu/4.7.2/cc1plus -quiet -v -D_GNU_SOURCE
test.cpp -quiet -dumpbase test.cpp -mtune=generic -march=pentiumpro -auxbase
test -std=c++11 -version -o /tmp/cc0973J0.s
GNU C++ (GCC) version 4.7.2 20120908 (prerelease) (i686-pc-linux-gnu)
compiled by GNU C version 4.7.2 20120908 (prerelease), GMP version 5.0.2,
MPFR version 3.1.0, MPC version 0.8.2
test.cpp: In function ‘int main()’:
test.cpp:23:17: error: use of deleted function ‘B::B(const B)’
test.cpp:15:12: note: ‘B::B(const B)’ is implicitly deleted because the
default definition would be ill-formed:
test.cpp:15:12: error: use of deleted function ‘constexpr Aint::A(const
Aint)’
test.cpp:2:16: note: ‘constexpr Aint::A(const Aint)’ is implicitly
declared as deleted because ‘Aint’ declares a move constructor or move
assignment operator
test.cpp:24:15: error: use of deleted function ‘B B::operator=(const B)’
test.cpp:15:12: note: ‘B B::operator=(const B)’ is implicitly deleted because
the default definition would be ill-formed:
test.cpp:15:12: error: use of deleted function ‘Aint Aint::operator=(const
Aint)’
test.cpp:2:16: note: ‘Aint Aint::operator=(const Aint)’ is implicitly
declared as deleted because ‘Aint’ declares a move constructor or move
assignment operator
[Bug tree-optimization/54505] RFE: Inline function tables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54505 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||steven at gcc dot gnu.org Resolution||WORKSFORME --- Comment #5 from Steven Bosscher steven at gcc dot gnu.org 2012-09-09 21:27:30 UTC --- gcc should make the transformation when it improves the code (like all other transformations). And how is gcc supposed to tell when this is an improvement? Your like all other transformations makes no sense, this is not something simple like constant propagation or redundancy elimination that's almost always a win. gcc often transforms a switch to a dispatch table, Yes, an existing switch, that someone wrote or generated deliberately as a switch. gcc should allow the programmer to write the code in the cleanest way, and transform it to the most performing way. Kicking in open doors doesn't help. A compiler is not an omniscient, omnipotent translator. If the compiler can't tell whether the transformation is profitable, it has to use some heuristics to make a best guess. In this case, the trade-off is expanding a compact indirect call to a large body of a switch statement. This might increase the number of branches (e.g. if the switch is lowered as a decision tree), it could ruin icache, and it may go against the intent of the programmer. There are no immediately obvious benefits visible to the compiler. With -fprofile-use GCC already performs inlining of the most frequently called callee of an indirect function calls table. It's the only situation where GCC can be sure that the transformation is profitable. If you want a switch, write a switch.
[Bug c++/54506] Defaulted move constructors and move assignment operators are erroneously defined as deleted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54506
--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-09-09
21:36:40 UTC ---
The example can be simplified to
struct A
{
A() {}
A(A ) = delete;
A operator =(A ) = delete;
};
struct B
{
A a;
B() = default;
};
int main()
{
B b = B();
b = B();
}
I think this is ill-formed, so G++ is right to reject it.
struct A cannot be moved because its move operations are deleted, and cannot be
copied because the implicit-declared copy operations are defined as deleted,
see [class.copy]/7. Therefore struct B cannot be moved or copied either.
[Bug c++/54506] Defaulted move constructors and move assignment operators are erroneously defined as deleted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54506
--- Comment #5 from Nikolka tsoae at mail dot ru 2012-09-09 22:42:03 UTC ---
(In reply to comment #4)
These examples aren't similar. An implicitly defined move constructor performs
direct-initialization of non-static data members with the corresponding members
of the argument, which is interpreted as xvalue (12.8/15). In every such a
direct-initialization all constructors are considered (13.3.1.3), including
constructor templates. Template argument for the parameter U can be deduced as
int, and the produced specialization of the constructor template will have
better match than both copy and move constructors.
Similarly for assignment operators.
struct A cannot be moved because its move operations are deleted
This is not so in my example, and g++ correctly handles the following case:
template class T
struct A
{
A() {}
A(A const volatile ) = delete;
A operator =(A const volatile ) = delete;
template class U
A(AU ) {}
template class U
A operator =(AU ) { return *this; }
};
int main()
{
Aint a = Aint(); // OK
a = Aint(); // OK
}
[Bug c++/54506] Defaulted move constructors and move assignment operators are erroneously defined as deleted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54506 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW CC||jason at gcc dot gnu.org --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2012-09-09 22:59:01 UTC --- (In reply to comment #5) These examples aren't similar. You're right I reduced it too far, sorry. I'll confirm this then and CC Jason to look at it.
[Bug libstdc++/43852] Embedded systems friendly libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43852 --- Comment #20 from Jonathan Wakely redi at gcc dot gnu.org 2012-09-09 23:08:54 UTC --- Author: redi Date: Sun Sep 9 23:08:48 2012 New Revision: 191121 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191121 Log: 2012-09-10 Sebastian Huber sebastian.hu...@embedded-brains.de Jonathan Wakely jwakely@gmail.com PR libstdc++/43852 * acinclude.m4 (GLIBCXX_ENABLE_VERBOSE): Define. * configure.ac (GLIBCXX_ENABLE_VERBOSE): Use it. * config.h.in: Regenerate. * configure: Likewise. * libsupc++/eh_term_handler.cc (_GLIBCXX_VERBOSE): Check new macro. * libsupc++/pure.cc (_GLIBCXX_VERBOSE): Likewise. * doc/xml/manual/configure.xml (--disable-libstdcxx-verbose): Document. * doc/html/manual/configure.html: Regenerate. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/config.h.in trunk/libstdc++-v3/configure trunk/libstdc++-v3/configure.ac trunk/libstdc++-v3/doc/html/manual/configure.html trunk/libstdc++-v3/doc/xml/manual/configure.xml trunk/libstdc++-v3/libsupc++/eh_term_handler.cc trunk/libstdc++-v3/libsupc++/pure.cc
[Bug libstdc++/43852] Embedded systems friendly libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43852 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #21 from Jonathan Wakely redi at gcc dot gnu.org 2012-09-09 23:09:53 UTC --- Done for 4.8.0
[Bug web/54539] New: pdf docs on web site are bzipped: unusable on Apple Ipad
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54539 Bug #: 54539 Summary: pdf docs on web site are bzipped: unusable on Apple Ipad Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web AssignedTo: unassig...@gcc.gnu.org ReportedBy: tom.brow...@gmail.com pdf docs (gcc and libstdc++ manuals) are bzipped (saving little space) which cannot be downloaded on Apple Ipad 3.
[Bug web/54539] pdf docs on web site are bzipped: unusable on Apple Ipad
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54539 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-09-09 23:25:39 UTC --- Complain to Apple then as they work for me with Adobe reader and many other pdf readers.
[Bug c++/54506] Defaulted move constructors and move assignment operators are erroneously defined as deleted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54506 --- Comment #7 from Jason Merrill jason at gcc dot gnu.org 2012-09-10 02:09:26 UTC --- (In reply to comment #3) g++ v4.7.2 20120908 (prerelease) compiles the original example successfully, but it fails to compile the following code: G++ is following the proposed resolution of DR 1402 here; Aint does not have a move constructor and it is not trivially copyable, so the B move constructor is not implicitly declared. This seems like a flaw in the 1402 drafting; the template constructor should count.
[Bug lto/51432] [4.6 regression] ICE in -flto -std=c++0x -g with cross-compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51432 Michael Hope michael.hope at linaro dot org changed: What|Removed |Added CC||michael.hope at linaro dot ||org --- Comment #3 from Michael Hope michael.hope at linaro dot org 2012-09-10 03:59:49 UTC --- The fault also happens natively: cbuild@ursa2:~$ g++ -flto -std=c++0x -g -xc++ /dev/null -include functional In file included from /usr/include/c++/4.6/functional:59:0, from command-line:0: /usr/include/c++/4.6/bits/functional_hash.h: In instantiation of 'std::size_t std::hash_Tp::operator()(_Tp) const [with _Tp = long double, std::size_t = unsigned int]': /usr/include/c++/4.6/functional:2267:1: instantiated from here /usr/include/c++/4.6/bits/functional_hash.h:184:5: internal compiler error: in write_builtin_type, at cp/mangle.c:2168 cbuild@ursa2:~$ gcc --version gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 This isn't FSF 4.6.3 but is pretty close.
[Bug libstdc++/54172] [4.7 Regression] __cxa_guard_acquire thread-safety issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54172 --- Comment #14 from Benjamin Kosnik bkoz at gcc dot gnu.org 2012-09-10 05:08:15 UTC --- Author: bkoz Date: Mon Sep 10 05:08:07 2012 New Revision: 191125 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191125 Log: 2012-09-09 Thiago Macieira thiago.macie...@intel.com PR libstdc++/54172 * libsupc++/guard.cc (__cxa_guard_acquire): Exit the loop earlier if we detect that another thread has had success. Don't compare_exchange from a finished state back to a waiting state. Comment. Modified: branches/gcc-4_7-branch/libstdc++-v3/ChangeLog branches/gcc-4_7-branch/libstdc++-v3/libsupc++/guard.cc
[Bug libstdc++/54172] [4.7 Regression] __cxa_guard_acquire thread-safety issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54172 --- Comment #14 from Benjamin Kosnik bkoz at gcc dot gnu.org 2012-09-10 05:08:15 UTC --- Author: bkoz Date: Mon Sep 10 05:08:07 2012 New Revision: 191125 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191125 Log: 2012-09-09 Thiago Macieira thiago.macie...@intel.com PR libstdc++/54172 * libsupc++/guard.cc (__cxa_guard_acquire): Exit the loop earlier if we detect that another thread has had success. Don't compare_exchange from a finished state back to a waiting state. Comment. Modified: branches/gcc-4_7-branch/libstdc++-v3/ChangeLog branches/gcc-4_7-branch/libstdc++-v3/libsupc++/guard.cc --- Comment #15 from Benjamin Kosnik bkoz at gcc dot gnu.org 2012-09-10 05:08:51 UTC --- In 4.7-branch
[Bug libstdc++/54172] [4.7 Regression] __cxa_guard_acquire thread-safety issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54172 --- Comment #15 from Benjamin Kosnik bkoz at gcc dot gnu.org 2012-09-10 05:08:51 UTC --- In 4.7-branch
