[Bug tree-optimization/61493] New: Bug exposed by speculative devirtualizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61493 Bug ID: 61493 Summary: Bug exposed by speculative devirtualizing Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: wmi at google dot com 1.cxx is attached. $~/workarea/gcc-r211604/build/install/bin/g++ -v Using built-in specs. COLLECT_GCC=/usr/local/google/home/wmi/workarea/gcc-r211604/build/install/bin/g++ COLLECT_LTO_WRAPPER=/usr/local/google/home/wmi/workarea/gcc-r211604/build/install/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../src/configure --enable-languages=c,c++ --disable-bootstrap --prefix=/usr/local/google/home/wmi/workarea/gcc-r211604/build/install Thread model: posix gcc version 4.10.0 20140613 (experimental) (GCC) $~/workarea/gcc-r211604/build/install/bin/g++ -O2 1.cxx $./a.out not equal $~/workarea/gcc-r211604/build/install/bin/g++ -O2 1.cxx $./a.out equal $~/workarea/gcc-r211604/build/install/bin/g++ -O2 -fno-devirtualize-speculatively 1.cxx $./a.out equal Google ref b/15521306
[Bug tree-optimization/61493] Bug exposed by speculative devirtualizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61493 --- Comment #1 from wmi at google dot com --- Created attachment 32931 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32931action=edit testcase
[Bug c/61285] GCC version 4.7.x 4.8.x 4.9.x does not compile working ARM code for the AT24 EEPROM driver under Linux 3.6.x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61285 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Feedback not coming.
[Bug middle-end/58670] asm goto miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #7 from Kai Tietz ktietz at gcc dot gnu.org --- Hmm, recent tests with trunk (4.10) doesn't show the issues described in comment #5.
[Bug c++/61489] Wrong warning with -Wmissing-field-initializers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61489
--- Comment #3 from Deniz Bahadir D.Bahadir at GMX dot de ---
Thanks for the comment.
So, at least we aggree that the cases for addr2 and addr6 should not warn (in
C++11) as it initializes all values. Possibly this holds true for addr9, too?
I always thought that the cases for addr3 and addr7 (and maybe also addr4 and
addr8) should initialize the entire struct with zeros. (This is for example
mentioned in that explanation:
http://www.codeguru.com/cpp/cpp/article.php/c19081/C-2011-Uniform-Initialization.htm)
By a quick look through the C++11 standard I was not able to find the section
which states that.
However, I found something similar in section 8.5.1 Aggregates, paragraph 7:
If there are fewer initializer-clauses in the list than there are members in
the aggregate, then each member not explicitly initialized shall be initialized
from an empty initializer list (8.5.4). [ Example:
struct S { int a; const char* b; int c; };
S ss = { 1, asdf };
initializes ss.a with 1, ss.b with asdf, and ss.c with the value of an
expression of the form int(), that is, 0. —end example ]
So, I am unsure if the compiler should warn about that or not.
Could maybe someone clarify if the statement from the link above about the
cases addr3 and addr7 is correct?
[Bug target/61494] New: -fsignaling-nans not taken into account for x - 0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61494 Bug ID: 61494 Summary: -fsignaling-nans not taken into account for x - 0.0 Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: vincent-gcc at vinc17 dot net Created attachment 32932 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32932action=edit testcase On x86_64, x - 0.0 is optimized to x in the asm code when compiling with -O -fsignaling-nans. This yields an incorrect behavior when x is a signaling NaN. Note that -fdump-tree-all shows that -fsignaling-nans is taken into account when the usual optimization is considered; even transf.c.170t.optimized still has _2 = x_1(D) - 0.0; as expected (I suppose). On PowerPC, the same x - 0.0 optimization is done with GCC 4.7.2 at least. I've attached a program that triggers the bug (it also does other tests). $ gcc -O transf.c -o transf -fsignaling-nans -lm $ ./transf 0x7ff1 x = [0x7ff1] = nan (signaling) Error for x_sub_zero in FE_TONEAREST: y0 = [0x7ff1] = nan (signaling) y1 = [0x7ff80001] = nan Error for x_sub_zero in FE_TOWARDZERO: y0 = [0x7ff1] = nan (signaling) y1 = [0x7ff80001] = nan Error for x_sub_zero in FE_DOWNWARD: y0 = [0x7ff1] = nan (signaling) y1 = [0x7ff80001] = nan Error for x_sub_zero in FE_UPWARD: y0 = [0x7ff1] = nan (signaling) y1 = [0x7ff80001] = nan
[Bug middle-end/58670] asm goto miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670 --- Comment #8 from David gccbugzilla at limegreensocks dot com --- I can confirm what Kai had to say in comment 7. Using a newer build resolves both the original problem reported by Jakub and the problem I saw in comment 5.
[Bug c++/61489] Wrong warning with -Wmissing-field-initializers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61489
--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Deniz Bahadir from comment #3)
Thanks for the comment.
So, at least we aggree that the cases for addr2 and addr6 should not warn
(in C++11) as it initializes all values.
No, that's not why I said it should not warn. All your examples except addr0
initialize all values, that's not the point. Please read the fine manual, the
warning is explicitly documented to warn when some members are implicitly set
to zero.
The warning is NOT designed to tell you about uninitialized members. It is
designed to tell you about implicitly zero-initialized members. So please stop
claiming it shouldn't warn when all members are zero-initialized, that's
EXACTLY what the warning is for.
(I think {} should not warn in C++11 because it is similar to the addr5 case,
which is explicit value-initialization. Although technically your cases are
still aggregate-initialization not value-initialization even with {})
[Bug rtl-optimization/61494] -fsignaling-nans not taken into account for x - 0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61494
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-06-13
Component|target |rtl-optimization
Ever confirmed|0 |1
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
RTL CSE optimizes x - 0.0 to x. I thought it does nothing for FP ops ...
Confirmed.
static rtx
simplify_binary_operation_1 (enum rtx_code code, enum machine_mode mode,
rtx op0, rtx op1, rtx trueop0, rtx trueop1)
{
...
case PLUS:
/* Maybe simplify x + 0 to x. The two expressions are equivalent
when x is NaN, infinite, or finite and nonzero. They aren't
when x is -0 and the rounding mode is not towards -infinity,
since (-0) + 0 is then 0. */
if (!HONOR_SIGNED_ZEROS (mode) trueop1 == CONST0_RTX (mode))
return op0;
...
case MINUS:
/* We can't assume x-x is 0 even with non-IEEE floating point,
but since it is zero except in very strange circumstances, we
will treat it as zero with -ffinite-math-only. */
if (rtx_equal_p (trueop0, trueop1)
! side_effects_p (op0)
(!FLOAT_MODE_P (mode) || !HONOR_NANS (mode)))
return CONST0_RTX (mode);
/* Change subtraction from zero into negation. (0 - x) is the
same as -x when x is NaN, infinite, or finite and nonzero.
But if the mode has signed zeros, and does not round towards
-infinity, then 0 - 0 is 0, not -0. */
if (!HONOR_SIGNED_ZEROS (mode) trueop0 == CONST0_RTX (mode))
return simplify_gen_unary (NEG, mode, op1, mode);
[Bug tree-optimization/61493] [4.10 Regression] Bug exposed by speculative devirtualizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61493 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code CC||hubicka at gcc dot gnu.org Target Milestone|--- |4.10.0 Summary|Bug exposed by speculative |[4.10 Regression] Bug |devirtualizing |exposed by speculative ||devirtualizing
[Bug lto/61487] LTO breaks on mips with wireless-tools 0.29
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61487 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||lto Target||mips --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Maybe you can check if it is fixed with GCC 4.9.0? What mips target triplet exactly?
[Bug target/61360] [4.10 Regression] ICE: in lra_update_insn_recog_data, at lra.c:1363 with -mtune=bdver4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61360 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-06-13 CC||trippels at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Confirmed. Also happens when building Firefox with -march=amdfam10. Vladimir?
[Bug lto/61487] LTO breaks on mips with wireless-tools 0.29
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61487 --- Comment #4 from Rose Garcia rose.garcia-eggl2fk at yopmail dot com --- (In reply to Richard Biener from comment #3) What mips target triplet exactly? mips-linux-musl (using the patches/buildscripts from https://bitbucket.org/GregorR/musl-cross, as musl support has still not been merged into gcc) but i suspect the bug affects mips-linux-* or even mips-*
[Bug middle-end/58670] asm goto miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Kai Tietz ktietz at gcc dot gnu.org --- I've tested additional the 4.8.x branch, and it is fixed there too. So issue seems to be fixed on all open branches. Therefore close as fixed.
[Bug go/51874] Many libgo testsuite failures on IRIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51874 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |WONTFIX --- Comment #19 from Rainer Orth ro at gcc dot gnu.org --- 4.7 branch closed.
[Bug target/50580] gcc.target/mips/interrupt_handler-[23].c FAIL on IRIX 6.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50580 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #4 from Rainer Orth ro at gcc dot gnu.org --- 4.7 branch closed.
[Bug libgcj/49456] getstacktrace and getallthreads tests timeout on IRIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49456 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Rainer Orth ro at gcc dot gnu.org --- 4.7 branch closed.
[Bug libgcj/49455] Thread_Interrupt Looper subtest FAILs on IRIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49455 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Rainer Orth ro at gcc dot gnu.org --- 4.7 branch closed.
[Bug tree-optimization/48321] gcc.dg/graphite/id-pr46845.c FAILs on IRIX 6.5: ICE in commit_one_edge_insertion, at cfgrtl.c:1566
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48321 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Rainer Orth ro at gcc dot gnu.org --- 4.7 branch closed.
[Bug libstdc++/48340] Several wchar_t tests FAIL on IRIX 6.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48340 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #15 from Rainer Orth ro at gcc dot gnu.org --- 4.7 branch closed.
[Bug rtl-optimization/59535] [4.9 regression] -Os code size regressions for Thumb1/Thumb2 with LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59535 --- Comment #19 from ramana.radhakrishnan at arm dot com ramana.radhakrishnan at arm dot com --- On 06/12/14 08:46, fredrik.hederstie...@securitas-direct.com wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59535 Fredrik Hederstierna fredrik.hederstie...@securitas-direct.com changed: What|Removed |Added CC||fredrik.hederstierna@securi ||tas-direct.com --- Comment #18 from Fredrik Hederstierna fredrik.hederstie...@securitas-direct.com --- I compared GCC 4.8.3 and GCC 4.9.0 for arm-none-eabi, and I still see a code size increase for thumb1 (and thumb2) for both my arm966e and my cortex-m4 targets. GCC 4.8.3 RAM used 93812 Flash used 515968 GCC 4.9.0 RAM used 93812 (same) Flash used 522608 (+1.3%) Then I tried to disable LRA and results got better: GCC 4.9.0 : added flag -mno-lra RAM used 93812 (same) Flash used 519624 (+0.7%) Flags used are otherwise identical for both tests: -Os -g3 -ggdb3 -gdwarf-4 -fvar-tracking-assignments -fverbose-asm -fno-common -ffunction-sections -fdata-sections -fno-exceptions -fno-asynchronous-unwind-tables -fno-unwind-tables -mthumb -mcpu=arm966e-s -msoft-float -mno-unaligned-access Generally GCC 4.9.0 seems to produce larger code, I tried to experiement with LTO (-flto -flto-fat-objects), but then code size increased even more for both GCC 4.8.3 and GCC 4.9.0, I was expecting a code decrease though. Sorry I cannot share exact sources used for compilation here, I can share toolchain build script though on request, or try to setup a small test case. I first just wanted to confirm that this bug really is fixed and resolved, so its not a new bug or another known issue. It might be another issue or it may well be an issue with LRA not many could tell for certain unless we could get a small testcase to look at. What we'd like is a small testcase that shows the problem compared with gcc 4.8.3 to progress this further. Please file a new bug report following the instructions in https://gcc.gnu.org/bugs/#report in this particular case we'd be interested in all command line options that were used. regards Ramana BR /Fredrik
[Bug target/47683] g++.dg/tree-prof/partition[12].C FAIL on IRIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47683 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Rainer Orth ro at gcc dot gnu.org --- 4.7 branch closed.
[Bug middle-end/47406] gcc.dg/torture/builtin-modf-1.c FAILs on IRIX 6.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47406 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #5 from Rainer Orth ro at gcc dot gnu.org --- 4.7 branch closed.
[Bug middle-end/47405] gcc.dg/torture/20090618-1.c FAILs on IRIX 6.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47405 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #6 from Rainer Orth ro at gcc dot gnu.org --- 4.7 branch closed.
[Bug libffi/46660] cls_double_va.c, cls_longdouble_va.c FAIL on IRIX 6.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46660 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #6 from Rainer Orth ro at gcc dot gnu.org --- 4.7 branch closed.
[Bug target/46610] gcc.target/mips/save-restore-?.c ICEs on IRIX 6.5: unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46610 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #4 from Rainer Orth ro at gcc dot gnu.org --- 4.7 branch closed.
[Bug target/22006] New IRIX 6.5 testsuite failures with gas: .space repeat count is zero, ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22006 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED CC||ro at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #7 from Rainer Orth ro at gcc dot gnu.org --- 4.7 branch closed.
[Bug libstdc++/54448] many failures with /sbin/loader: Error: libstdc++.so.6: symbol __pthread_mutex_init unresolved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54448 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ro at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #7 from Rainer Orth ro at gcc dot gnu.org --- 4.7 branch closed.
[Bug gcov-profile/50631] g++.dg/bprob/g++-bprob-2.C -fbranch-probabilities FAILs on Tru64 UNIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50631 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Rainer Orth ro at gcc dot gnu.org --- 4.7 branch closed.
[Bug testsuite/48251] guality_check hangs indefinitely on Tru64 UNIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48251 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #10 from Rainer Orth ro at gcc dot gnu.org --- 4.7 branch closed.
[Bug bootstrap/44424] problem related to awk on alpha-dec-osf5.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44424 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Rainer Orth ro at gcc dot gnu.org --- 4.7 branch closed.
[Bug other/39951] Dangling symlink .../include-fixed/mach created on install
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39951 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Rainer Orth ro at gcc dot gnu.org --- 4.7 branch closed.
[Bug bootstrap/35211] Dist tarball is missing (Bison-generated) java/parse-scan.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35211 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ro at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #5 from Rainer Orth ro at gcc dot gnu.org --- 4.7 branch closed.
[Bug other/34520] fixincludes adjusts assert.h in such a way that it stays omnipotent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34520 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ro at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #3 from Rainer Orth ro at gcc dot gnu.org --- 4.7 branch closed.
[Bug libstdc++/61269] type_traits includes cstdint inside std namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61269 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Fri Jun 13 11:59:22 2014 New Revision: 211636 URL: https://gcc.gnu.org/viewcvs?rev=211636root=gccview=rev Log: 2014-06-13 Jonathan Wakely jwak...@redhat.com Backport from mainline PR libstdc++/60326 * include/std/type_traits (__make_unsigned, __make_signed): Define specializations for wchar_t, char16_t and char32_t. * testsuite/20_util/make_signed/requirements/typedefs-4.cc: New. * testsuite/20_util/make_unsigned/requirements/typedefs-1.cc: Correct test for make_unsignedvolatile wchar_t. * testsuite/20_util/make_unsigned/requirements/typedefs-2.cc: Likewise. * testsuite/20_util/declval/requirements/1_neg.cc: Adjust dg-error line number. * testsuite/20_util/make_signed/requirements/typedefs_neg.cc: Likewise. * testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc: Likewise. Backport from mainline PR libstdc++/61269 * include/std/type_traits: Move include outside namespace std. * testsuite/20_util/declval/requirements/1_neg.cc: Adjust dg-error. * testsuite/20_util/make_signed/requirements/typedefs_neg.cc: Likewise. * testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc: Likewise. Added: branches/gcc-4_9-branch/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs-4.cc - copied, changed from r211602, branches/gcc-4_9-branch/libstdc++-v3/testsuite/20_util/declval/requirements/1_neg.cc Modified: branches/gcc-4_9-branch/libstdc++-v3/ChangeLog branches/gcc-4_9-branch/libstdc++-v3/include/std/type_traits branches/gcc-4_9-branch/libstdc++-v3/testsuite/20_util/declval/requirements/1_neg.cc branches/gcc-4_9-branch/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs_neg.cc branches/gcc-4_9-branch/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs-1.cc branches/gcc-4_9-branch/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs-2.cc branches/gcc-4_9-branch/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc
[Bug libstdc++/60326] Incorrect type from std::make_unsignedwchar_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60326 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Fri Jun 13 11:59:22 2014 New Revision: 211636 URL: https://gcc.gnu.org/viewcvs?rev=211636root=gccview=rev Log: 2014-06-13 Jonathan Wakely jwak...@redhat.com Backport from mainline PR libstdc++/60326 * include/std/type_traits (__make_unsigned, __make_signed): Define specializations for wchar_t, char16_t and char32_t. * testsuite/20_util/make_signed/requirements/typedefs-4.cc: New. * testsuite/20_util/make_unsigned/requirements/typedefs-1.cc: Correct test for make_unsignedvolatile wchar_t. * testsuite/20_util/make_unsigned/requirements/typedefs-2.cc: Likewise. * testsuite/20_util/declval/requirements/1_neg.cc: Adjust dg-error line number. * testsuite/20_util/make_signed/requirements/typedefs_neg.cc: Likewise. * testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc: Likewise. Backport from mainline PR libstdc++/61269 * include/std/type_traits: Move include outside namespace std. * testsuite/20_util/declval/requirements/1_neg.cc: Adjust dg-error. * testsuite/20_util/make_signed/requirements/typedefs_neg.cc: Likewise. * testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc: Likewise. Added: branches/gcc-4_9-branch/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs-4.cc - copied, changed from r211602, branches/gcc-4_9-branch/libstdc++-v3/testsuite/20_util/declval/requirements/1_neg.cc Modified: branches/gcc-4_9-branch/libstdc++-v3/ChangeLog branches/gcc-4_9-branch/libstdc++-v3/include/std/type_traits branches/gcc-4_9-branch/libstdc++-v3/testsuite/20_util/declval/requirements/1_neg.cc branches/gcc-4_9-branch/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs_neg.cc branches/gcc-4_9-branch/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs-1.cc branches/gcc-4_9-branch/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs-2.cc branches/gcc-4_9-branch/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc
[Bug libstdc++/60326] Incorrect type from std::make_unsignedwchar_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60326 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.1 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- Fixed for 4.9.1
[Bug ipa/61495] [4.10 regression] Many Go tests FAIL with fatal error: runtime.SetFinalizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61495 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.10.0
[Bug ipa/61495] New: [4.10 regression] Many Go tests FAIL with fatal error: runtime.SetFinalizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61495 Bug ID: 61495 Summary: [4.10 regression] Many Go tests FAIL with fatal error: runtime.SetFinalizer Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: hubicka at gcc dot gnu.org, iant at google dot com Host: *-*-solaris2.11 Target: *-*-solaris2.11 Build: *-*-solaris2.11 Between 20140516 (r210514) and 20140520 (r210655), many Go tests started to FAIL on Solaris 11 when using gas with /bin/ld, both SPARC and x86, 32 and 64-bit: runtime.SetFinalizer: cannot pass * os os.file to finalizer func(* os os.file) error fatal error: runtime.SetFinalizer A reghunt revealed that this patch 2014-05-17 Jan Hubicka hubi...@ucw.cz * tree-pass.h (make_pass_ipa_comdats): New pass. * timevar.def (TV_IPA_COMDATS): New timevar. * passes.def (pass_ipa_comdats): Add. * Makefile.in (OBJS): Add ipa-comdats.o * ipa-comdats.c: New file. Is the culprit. This is not seen with as/ld (as requires different comdat syntax), gas/gld, nor on Solaris 10 (where the necessary support to deal with comdat as emitted by gas is not yet present). When linking libgo.so.5, I see many ld warnings like ld: warning: relocation warning: R_386_32: file .libs/bytes.o: section [149].rel.data.rel.ro.__go_td_FppN12_bytes.ReadererN5_uint8N5_erroree: symbol C217: relocation against discarded COMDAT section [152].data.rel.C217: symbol not found, relocation ignored The strange thing is: if I link the objects generated by a gcc configured to use gas/gld with ld, the resulting libgo.so.5 and the actual testcases work fine: linking gld objects with gldok gld ldok ld ldbad ld gldok Rainer Rainer
[Bug go/61496] New: [4.10 regression] Many Go tests FAIL with ld warning about go$zerovalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61496 Bug ID: 61496 Summary: [4.10 regression] Many Go tests FAIL with ld warning about go$zerovalue Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: ro at gcc dot gnu.org CC: cmang at google dot com Host: *-*-solaris2.* Target: *-*-solaris2.* Build: *-*-solaris2.* As initially reported https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00589.html many Go tests now FAIL with ld warnings like FAIL: go.test/test/bom.go -O (test for excess errors) ld: warning: symbol 'go$zerovalue' has differing sizes: (file bom.o value=0x8; file /var/gcc/regression/trunk/11-gcc/build/i386-pc-solaris2.11/./libgo/.libs/libgo.so value=0x800); bom.o definition taken and updated with larger size When using /bin/ld on Solaris. This can be worked around by linking with -t. Rainer
[Bug go/61496] [4.10 regression] Many Go tests FAIL with ld warning about go$zerovalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61496 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.10.0
[Bug go/61497] New: [4.10 regression] Many Go tests FAIL with fatal error: all goroutines are asleep - deadlock!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61497 Bug ID: 61497 Summary: [4.10 regression] Many Go tests FAIL with fatal error: all goroutines are asleep - deadlock! Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: ro at gcc dot gnu.org CC: cmang at google dot com Host: i386-pc-solaris2.11 Target: i386-pc-solaris2.11 Build: i386-pc-solaris2.11 Since this patch The first bad revision is: changeset: 14850:db4fd4f0c230 user:ian@138bc75d-0d04-0410-961f-82ee72b054a4 date:Fri Jun 06 22:37:27 2014 + summary: libgo: Merge to master revision 19184. many 64-bit Go tests FAIL on Solaris 11/x86 (no Solaris 10 results yet) with FAIL: go.go-torture/execute/chan-1.go execution, -O0 fatal error: all goroutines are asleep - deadlock! goroutine 16 [chan send]: created by main /vol/gcc/src/hg/trunk/local/libgo/runtime/go-main.c:42 I haven't yet started investigating in more detail. Rainer
[Bug go/61497] [4.10 regression] Many Go tests FAIL with fatal error: all goroutines are asleep - deadlock!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61497 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.10.0
[Bug go/61498] [4.10 regression] Many 64-bit Go tests SEGV in scanblock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61498 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.10.0
[Bug go/61498] New: [4.10 regression] Many 64-bit Go tests SEGV in scanblock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61498 Bug ID: 61498 Summary: [4.10 regression] Many 64-bit Go tests SEGV in scanblock Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: ro at gcc dot gnu.org CC: cmang at google dot com Host: sparc-sun-solaris2.11 Target: sparc-sun-solaris2.9 Build: sparc-sun-solaris2.11 Between 20140606 (r211315) and 20140612 (r211522), many 64-bit Go tests started to FAIL on 64-bit Solaris 11/SPARC: FAIL: go.go-torture/execute/array-2.go execution, -O0 unexpected fault address 0xc208213b0c fatal error: fault [signal 0xa code=0x1 addr=0xc208213b0c] runtime stack: runtime_dopanic /vol/gcc/src/hg/trunk/local/libgo/runtime/panic.c:133 runtime_throw /vol/gcc/src/hg/trunk/local/libgo/runtime/panic.c:167 sig_panic_info_handler /vol/gcc/src/hg/trunk/local/libgo/runtime/go-signal.c:294 :0 scanblock /vol/gcc/src/hg/trunk/local/libgo/runtime/mgc0.c:1048 markroot /vol/gcc/src/hg/trunk/local/libgo/runtime/mgc0.c:1405 runtime.parfordo /vol/gcc/src/hg/trunk/local/libgo/runtime/parfor.c:112 gc /vol/gcc/src/hg/trunk/local/libgo/runtime/mgc0.c:2282 mgc /vol/gcc/src/hg/trunk/local/libgo/runtime/mgc0.c:2225 runtime_mstart /vol/gcc/src/hg/trunk/local/libgo/runtime/proc.c:1026 main /vol/gcc/src/hg/trunk/local/libgo/runtime/go-main.c:43 :0 goroutine 16 [garbage collection]: created by main /vol/gcc/src/hg/trunk/local/libgo/runtime/go-main.c:42 goroutine 17 [runnable]:created by runtime_main /vol/gcc/src/hg/trunk/local/libgo/runtime/proc.c:561 Running it under gdb reveals Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] scanblock (wbuf=optimized out, keepworking=keepworking@entry=0 '\000') at /vol/gcc/src/hg/trunk/local/libgo/runtime/mgc0.c:1048 1048obj = *(byte**)stack_top.b; 1: x/i $pc = 0xfffb998a230c scanblock+348: ldx [ %i5 ], %g1 (gdb) where #0 scanblock (wbuf=optimized out, keepworking=keepworking@entry=0 '\000') at /vol/gcc/src/hg/trunk/local/libgo/runtime/mgc0.c:1048 #1 0xfffb998a2cf4 in markroot (desc=optimized out, i=optimized out) at /vol/gcc/src/hg/trunk/local/libgo/runtime/mgc0.c:1405 #2 0xfffb998a7d98 in runtime.parfordo (desc=0xc208428000) at /vol/gcc/src/hg/trunk/local/libgo/runtime/parfor.c:112 #3 0xfffb998a4a68 in gc (args=optimized out) at /vol/gcc/src/hg/trunk/local/libgo/runtime/mgc0.c:2282 #4 mgc (gp=0xc208002800) at /vol/gcc/src/hg/trunk/local/libgo/runtime/mgc0.c:2225 #5 0xfffb998ac120 in runtime_mstart (mp=0xfffb9a007290 runtime_m0) at /vol/gcc/src/hg/trunk/local/libgo/runtime/proc.c:1026 #6 0x00011784 in main (argc=optimized out, argv=0x72f8) at /vol/gcc/src/hg/trunk/local/libgo/runtime/go-main.c:43 #7 0x0001121c in _start () and truss shows that it's an address alignment error: /1: Incurred fault #5, FLTACCESS %pc = 0xFFFB998A230C /1: siginfo: SIGBUS BUS_ADRALN addr=0xC208213B0C /1: Received signal #10, SIGBUS [caught] /1: siginfo: SIGBUS BUS_ADRALN addr=0xC208213B0C Rainer
[Bug go/61498] [4.10 regression] Many 64-bit Go tests SEGV in scanblock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61498 --- Comment #1 from ian at gcc dot gnu.org ian at gcc dot gnu.org --- Author: ian Date: Fri Jun 13 13:50:13 2014 New Revision: 211639 URL: https://gcc.gnu.org/viewcvs?rev=211639root=gccview=rev Log: PR go/61498 runtime: Always set gcnext_sp to pointer-aligned address. The gcnext_sp field is only used on systems that do not use split stacks. It marks the bottom of the stack for the garbage collector. This change makes sure that the stack bottom is always aligned to a pointer value. Previously the garbage collector would align all the addresses that it scanned, but it now expects them to be aligned before scanning. Modified: trunk/libgo/runtime/proc.c
[Bug go/52583] Several new go testsuite failues on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583 --- Comment #29 from ian at gcc dot gnu.org ian at gcc dot gnu.org --- Author: ian Date: Fri Jun 13 13:56:14 2014 New Revision: 211640 URL: https://gcc.gnu.org/viewcvs?rev=211640root=gccview=rev Log: PR go/52583 runtime: Stop backtrace at a few recognized functions. On x86_64 Solaris the makecontext function does not properly indicate that it is at the top of the stack. Attempting to unwind the stack past a call to makecontext tends to crash. This patch changes libgo to look for certain functions that are always found at the top of the stack, and to stop unwinding when it reaches one of those functions. There is never anything interesting past these functions--that is, there is never any code written by the user. Modified: trunk/libgo/runtime/go-callers.c
[Bug go/61498] [4.10 regression] Many 64-bit Go tests SEGV in scanblock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61498 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Ian Lance Taylor ian at airs dot com --- Should be fixed now, I hope.
[Bug go/52583] Several new go testsuite failues on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added Status|SUSPENDED |RESOLVED Resolution|--- |FIXED --- Comment #30 from Ian Lance Taylor ian at airs dot com --- This should be fixed now on mainline (the future 4.10).
[Bug middle-end/53696] [4.8/4.9/4.10 Regression] ICE: SIGSEGV in gimplify_decl_expr (gimplify.c:1454) with -fkeep-inline-functions on invalid use of lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53696 --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com --- By the way, in mainline I can't reproduce this anymore.
[Bug ipa/61186] ./g++.dg/ipa/pr52939.C valgrind pointer_set_insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61186 --- Comment #2 from Martin Jambor jamborm at gcc dot gnu.org --- Author: jamborm Date: Fri Jun 13 14:26:51 2014 New Revision: 211641 URL: https://gcc.gnu.org/viewcvs?rev=211641root=gccview=rev Log: 2014-06-13 Martin Jambor mjam...@suse.cz PR ipa/61186 * ipa-devirt.c (possible_polymorphic_call_targets): Store NULL to cache_token if returning early. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-devirt.c
[Bug ipa/61186] ./g++.dg/ipa/pr52939.C valgrind pointer_set_insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61186 --- Comment #3 from Martin Jambor jamborm at gcc dot gnu.org --- Author: jamborm Date: Fri Jun 13 14:34:14 2014 New Revision: 211646 URL: https://gcc.gnu.org/viewcvs?rev=211646root=gccview=rev Log: 2014-06-13 Martin Jambor mjam...@suse.cz PR ipa/61186 * ipa-devirt.c (possible_polymorphic_call_targets): Store NULL to cache_token if returning early. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/ipa-devirt.c
[Bug ipa/61186] ./g++.dg/ipa/pr52939.C valgrind pointer_set_insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61186 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Jambor jamborm at gcc dot gnu.org --- Fixed.
[Bug libfortran/61499] New: Internal read of negative integer broken in 4.9.0 on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61499 Bug ID: 61499 Summary: Internal read of negative integer broken in 4.9.0 on Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: krefson at gmail dot com Created attachment 32933 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32933action=edit Source for testcase The attached file compiles bug gives erroneous results with fortran 4.9.0 and 4.9.1 gfortran -static-libgfortran -o internal2 internal2.f90 /usr/bin/ld: warning: -z ignore ignored. /usr/bin/ld: warning: -z record ignored. [kr@kohn gfortran-4.9.1]$ ./internal2 Error: Bad integer for item 2 in list input [kr@kohn gfortran-4.9.1]$ gfortran --version GNU Fortran (GCC) 4.9.1 20140611 (prerelease) Expected output (4.8.2) ./internal2.4.8.2 1 1 -1 1 -1 1 Note that this is closely related to bug #61173. That bug is fixed in the above version, but internal reads of integer data are still failing as in this case.
[Bug target/58067] ICE in GFortran recog.c:2158
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58067 Teresa Johnson tejohnson at google dot com changed: What|Removed |Added CC||tejohnson at google dot com --- Comment #11 from Teresa Johnson tejohnson at google dot com --- Is this issue fixed on trunk? The bug is still in state UNCONFIRMED. Just hit this on the google/4_8 branch, since the last fix (r202055) wasn't backported to gcc-4_8. I am going to backport r202055 to google/4_8 as that seems to fix the problem. Google ref b/15576865. Thanks, Teresa
[Bug c++/61500] New: [C++11] [4.8/4.9 Regression] Can't take pointer to member referenced via member pointer template parameter.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61500
Bug ID: 61500
Summary: [C++11] [4.8/4.9 Regression] Can't take pointer to
member referenced via member pointer template
parameter.
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vmarko at google dot com
struct X {
int i;
int j;
int foo(int X::* ptr);
template int X::* ptr
int bar();
};
int X::foo(int X::* ptr) {
int* p = (this-*ptr); // OK.
return *p;
}
template int X::* ptr
int X::bar() {
int* p = (this-*ptr); // gcc 4.9.0: OK in C++98 mode, fails in C++11 mode.
return *p;
}
gcc 4.9.0, C++11:
test.cc:18:24: error: lvalue required as unary '' operand
Reproduced with gcc 4.9.0 from AOSP prebuilts (aarch64-linux-android) and gcc
4.8.0 from AOSP prebuilts (x86_64-linux-android). Works fine with gcc 4.6.3 on
host (x86_64-linux-gnu).
[Bug tree-optimization/61493] [4.10 Regression] Bug exposed by speculative devirtualizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61493 Paul Pluzhnikov ppluzhnikov at google dot com changed: What|Removed |Added CC||ppluzhnikov at google dot com --- Comment #2 from Paul Pluzhnikov ppluzhnikov at google dot com --- Also broken in 4.9
[Bug c++/61501] New: spurious conversion warning with -Wconversion when calling isnan(double x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61501
Bug ID: 61501
Summary: spurious conversion warning with -Wconversion when
calling isnan(double x)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: niemayer at isg dot de
When compiling:
--
#include math.h
int test(double x) {
return isnan(x);
}
--
with
gcc-4.9.0 -Wconversion -c /tmp/conversion_warn.cxx
a spurious warning is emitted:
/tmp/conversion_warn.cxx: In function 'int test(double)':
/tmp/conversion_warn.cxx:4:9: warning: conversion to 'float' from 'double' may
alter its value [-Wfloat-conversion]
return isnan(x);
^
This is what the output of compiling with -E of the above sample looks (with
includes from glibc 2.5.1):
-
int test(double x) {
return (sizeof (x) == sizeof (float) ? __isnanf (x) : sizeof (x) == sizeof
(double) ? __isnan (x) : __isnanl (x));
}
-
(This looks a little like Bug 51294, but that was reported fixed a long time
ago.)
[Bug target/51980] ARM - Neon code polluted by useless stores to the stack with vuzpq / vzipq / vtrnq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51980
christophe.lyon at st dot com changed:
What|Removed |Added
CC||christophe.lyon at st dot com
--- Comment #14 from christophe.lyon at st dot com ---
As of current trunk the softfp case looks like this:
sqrlen4D_16u8:
vmovd16, r0, r1 @ v16qi
vmovd17, r2, r3
vld1.64 {d18-d19}, [sp:64]
vabd.u8 q9, q8, q9
vmull.u8q8, d18, d18
vmull.u8q9, d19, d19
vuzp.32 q8, q9
vpaddl.u16 q8, q8
vpadal.u16 q8, q9
vmovr0, r1, d16 @ v4si
vmovr2, r3, d17
bx lr
which looks quite good.
[Bug c/61502] New: == comparison on one-past pointer gives wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
Bug ID: 61502
Summary: == comparison on one-past pointer gives wrong result
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: Peter.Sewell at cl dot cam.ac.uk
Created attachment 32934
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32934action=edit
C code as pasted into bug report
The following code can produce a pointer to one-past the x object. When it
does, according to the C11 standard text, the result of the pointer comparison
should be true, but gcc gives false.
#include stdio.h
int y = 2, x=1;
int main()
{
int *p;
p = x +1 ;
printf(x=%p y=%p p=%p\n,(void*)x, (void*)y, (void*)p);
_Bool b1 = (p==y);
printf((p==y) = %s\n, b1?true:false);
return 0;
}
gcc-4.8 -std=c11 -pedantic -Wall -Wextra -O2 -o a.out
pointer_representation_1e.c ./a.out
x=0x601020 y=0x601024 p=0x601024
(p==y) = false
gcc-4.8 --version
gcc-4.8 (Ubuntu 4.8.1-2ubuntu1~12.04) 4.8.1
The pointer addition is licensed by 6.5.6 Additive operators, where:
6.5.6p7 says For the purposes of these operators, a pointer to an object that
is not an element of an array behaves the same as a pointer to the first
element of an array of length one with the type of the object as its element
type., and
6.5.6p8 says [...] Moreover, if the expression P points to the last element of
an array object, the expression (P)+1 points one past the last element of the
array object [...].
The pointer comparison is licensed by 6.5.9 Equality operators, where:
6.5.9p7 says For the purposes of these operators, a pointer to an object that
is not an element of an array behaves the same as a pointer to the first
element of an array of length one with the type of the object as its element
type.,
6.5.9p6 says Two pointers compare equal if and only if [...] or one is a
pointer to one past the end of one array object and the other is a pointer to
the start of a different array object that happens to immediately follow the
first array object in the address space.109), and
Footnote 109 says Two objects may be adjacent in memory because they are
adjacent elements of a larger array or adjacent members of a structure with no
padding between them, or because the implementation chose to place them so,
even though they are unrelated. [...].
[Bug libstdc++/54173] -D_GLIBCXX_DEBUG breaks string::_Rep::_S_empty_rep_storage weak binding.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54173 Pawel Sikora pluto at agmk dot net changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #4 from Pawel Sikora pluto at agmk dot net --- currently i'm using a gcc configured with --disable-gnu-unique-object, --disable-initfini-array (not supported by ld.so on older *enterprise* redhat/suse distros) and --with-linker-hash-style=both (.gnu.hash section w/o sysv .hash causes divide by 0 inside older ld.so). finally, i'm building my application with -fms-compat-visiblity and explicite __attribute__((visibility(default))) exports instead of tricky linker scripts. such options give me pretty portable binaries (works well on rhel5, rhel6, suse11).
[Bug c++/60731] [4.7/4.8/4.9 Regression] dynamic library not getting reinitialized on multiple calls to dlopen()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60731 --- Comment #12 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Dave Johansen from comment #11) Can this please be reopened? It was determined in the glibc bugzilla that this is a gcc problem because of the incorrect setting of unique flag. The setting is not incorrect, nor is it an optimization; it is necessary to fix the behavior of RTLD_LOCAL with multiple loaded objects depending on the same library, since the glibc developers rejected the other approach that I suggested (https://www.sourceware.org/ml/libc-alpha/2002-05/msg00222.html). If you don't need this handling, in 4.9 you can use -fno-gnu-unique to disable it. I'll go ahead and backport that switch to 4.8 as well.
[Bug tree-optimization/61493] [4.10 Regression] Bug exposed by speculative devirtualizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61493 --- Comment #3 from wmi at google dot com --- Fix a typo in the first post. $~/workarea/gcc-r211604/build/install/bin/g++ -O2 1.cxx $./a.out not equal $~/workarea/gcc-r211604/build/install/bin/g++ -O0 1.cxx $./a.out equal $~/workarea/gcc-r211604/build/install/bin/g++ -O2 -fno-devirtualize-speculatively 1.cxx $./a.out equal
[Bug c++/60731] [4.7/4.8/4.9 Regression] dynamic library not getting reinitialized on multiple calls to dlopen()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60731 --- Comment #13 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Fri Jun 13 16:39:37 2014 New Revision: 211648 URL: https://gcc.gnu.org/viewcvs?rev=211648root=gccview=rev Log: PR c++/60731 * common.opt (-fno-gnu-unique): Add. * config/elfos.h (USE_GNU_UNIQUE_OBJECT): Check it. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/common.opt branches/gcc-4_8-branch/gcc/config/elfos.h branches/gcc-4_8-branch/gcc/doc/invoke.texi
[Bug rtl-optimization/61094] [4.9 Regression] -O3 insn Internal compiler error in copyprop_hardreg_forward_1, at regcprop.c:775
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61094 --- Comment #16 from Jeffrey A. Law law at gcc dot gnu.org --- Author: law Date: Fri Jun 13 16:40:48 2014 New Revision: 211649 URL: https://gcc.gnu.org/viewcvs?rev=211649root=gccview=rev Log: 2014-06-13 Jeff Law l...@redhat.com PR rtl-optimization/61094 PR rtl-optimization/61446 * ree.c (combine_reaching_defs): Get the mode for the copy from the extension insn rather than the defining insn. 2014-06-13 Ilya Enkovich ilya.enkov...@intel.com PR rtl-optimization/61094 PR rtl-optimization/61446 * gcc.target/i386/pr61446.c : New. Added: trunk/gcc/testsuite/gcc.target/i386/pr61446.c Modified: trunk/gcc/ChangeLog trunk/gcc/ree.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/61446] [4.10 Regression]: ICE in copyprop_hardreg_forward_1, at regcprop.c with -O2 -m32 -march=corei7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61446 --- Comment #7 from Jeffrey A. Law law at gcc dot gnu.org --- Author: law Date: Fri Jun 13 16:40:48 2014 New Revision: 211649 URL: https://gcc.gnu.org/viewcvs?rev=211649root=gccview=rev Log: 2014-06-13 Jeff Law l...@redhat.com PR rtl-optimization/61094 PR rtl-optimization/61446 * ree.c (combine_reaching_defs): Get the mode for the copy from the extension insn rather than the defining insn. 2014-06-13 Ilya Enkovich ilya.enkov...@intel.com PR rtl-optimization/61094 PR rtl-optimization/61446 * gcc.target/i386/pr61446.c : New. Added: trunk/gcc/testsuite/gcc.target/i386/pr61446.c Modified: trunk/gcc/ChangeLog trunk/gcc/ree.c trunk/gcc/testsuite/ChangeLog
[Bug target/61423] Incorrect conversion from unsigned int to floating point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61423 Bug 61423 depends on bug 61446, which changed state. Bug 61446 Summary: [4.10 Regression]: ICE in copyprop_hardreg_forward_1, at regcprop.c with -O2 -m32 -march=corei7 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61446 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug rtl-optimization/61446] [4.10 Regression]: ICE in copyprop_hardreg_forward_1, at regcprop.c with -O2 -m32 -march=corei7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61446 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #8 from Jeffrey A. Law law at redhat dot com --- Should be fixed on the trunk with most recent checkin.
[Bug target/61503] New: RTL representation of i386 shrdl instruction is incorrect?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61503
Bug ID: 61503
Summary: RTL representation of i386 shrdl instruction is
incorrect?
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nirhasabnis at gmail dot com
Hello,
I was studying i386 machine description for my research purpose,
and I stumbled upon following MD entry for 'shrdl' x86 instruction.
It is obtained from the most recent i386.md file.
(define_insn x86_shrd
[(set (match_operand:SI 0 nonimmediate_operand +r*m)
(ior:SI (ashiftrt:SI (match_dup 0)
(match_operand:QI 2 nonmemory_operand Ic))
(ashift:SI (match_operand:SI 1 register_operand r)
(minus:QI (const_int 32) (match_dup 2)
(clobber (reg:CC FLAGS_REG))]
shrd{l}\t{%s2%1, %0|%0, %1, %2}
[(set_attr type ishift)
(set_attr prefix_0f 1)
(set_attr mode SI)
(set_attr pent_pair np)
(set_attr athlon_decode vector)
(set_attr amdfam10_decode vector)
(set_attr bdver1_decode vector)])
It seems to me that the RTL representation for 'shrdl' is incorrect.
Semantics of shrdl instruction as per Intel manual is:
The instruction shifts the first operand (destination operand) to the right
the number of bits specified by the third operand (count operand).
The second operand (source operand) provides bits to shift in from the
left (starting with the most significant bit of the destination operand).
And the way RTL does it is by inclusive-or of arithmetically
right-shifted destination and left-shifted source operand.
But the problem is that: in case of a destination (reg/mem) containing
negative value, arithmetically right-shifted destination will have top bits
set to 1. Inclusive-or with such a value is going to generate a
result with top bits set to 1 instead of moving contents of source
into top bits of destination.
E.g., when ebx = b72f60d0, ebp = bfcbd2c8
shrdl $16, %ebp, %ebx (ebx is dest, ebp is src)
produces 0xd2c8b72f in ebx.
But the corresponding RTL produces 0xb72f in ebx.
So it seems to me that instead of 'ashiftrt', RTL should have 'lshiftrt'.
Filing a bug as per the discussion at
https://gcc.gnu.org/ml/gcc/2014-06/msg00070.html
[Bug rtl-optimization/61094] [4.9 Regression] -O3 insn Internal compiler error in copyprop_hardreg_forward_1, at regcprop.c:775
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61094 --- Comment #18 from Jeffrey A. Law law at gcc dot gnu.org --- Author: law Date: Fri Jun 13 16:50:10 2014 New Revision: 211652 URL: https://gcc.gnu.org/viewcvs?rev=211652root=gccview=rev Log: 2014-06-13 Jeff Law l...@redhat.com PR rtl-optimization/61094 PR rtl-optimization/61446 * ree.c (combine_reaching_defs): Get the mode for the copy from the extension insn rather than the defining insn. 2014-06-13 Ilya Enkovich ilya.enkov...@intel.com PR rtl-optimization/61094 PR rtl-optimization/61446 * gcc.target/i386/pr61446.c : New. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/pr61446.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/ree.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/61094] [4.9 Regression] -O3 insn Internal compiler error in copyprop_hardreg_forward_1, at regcprop.c:775
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61094 --- Comment #17 from Jeffrey A. Law law at gcc dot gnu.org --- Author: law Date: Fri Jun 13 16:50:01 2014 New Revision: 211651 URL: https://gcc.gnu.org/viewcvs?rev=211651root=gccview=rev Log: PR rtl-optimization/61094 * ree.c (combine_reaching_defs): Do not reextend an insn if it was marked as do_no_reextend. If a copy is needed to eliminate an extension, then mark it as do_not_reextend. PR rtl-optimization/61094 * g++.dg/pr61094: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/pr61094.C Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/ree.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/61446] [4.10 Regression]: ICE in copyprop_hardreg_forward_1, at regcprop.c with -O2 -m32 -march=corei7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61446 --- Comment #9 from Jeffrey A. Law law at gcc dot gnu.org --- Author: law Date: Fri Jun 13 16:50:10 2014 New Revision: 211652 URL: https://gcc.gnu.org/viewcvs?rev=211652root=gccview=rev Log: 2014-06-13 Jeff Law l...@redhat.com PR rtl-optimization/61094 PR rtl-optimization/61446 * ree.c (combine_reaching_defs): Get the mode for the copy from the extension insn rather than the defining insn. 2014-06-13 Ilya Enkovich ilya.enkov...@intel.com PR rtl-optimization/61094 PR rtl-optimization/61446 * gcc.target/i386/pr61446.c : New. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/pr61446.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/ree.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/61094] [4.9 Regression] -O3 insn Internal compiler error in copyprop_hardreg_forward_1, at regcprop.c:775
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61094 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #19 from Jeffrey A. Law law at redhat dot com --- Resolved on branch trunk.
[Bug target/61360] [4.10 Regression] ICE: in lra_update_insn_recog_data, at lra.c:1363 with -mtune=bdver4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61360 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Started with r210964 (doesn't compile) or r210965.
[Bug libfortran/61499] [4.9/410 Regression] Internal read of negative integer broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61499 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-06-13 CC||jvdelisle at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org Summary|Internal read of negative |[4.9/410 Regression] |integer broken in 4.9.0 on |Internal read of negative ||integer broken Ever confirmed|0 |1 Severity|major |normal --- Comment #1 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Confirmed. Regression
[Bug c++/61504] New: Move elision after cast to rvalue reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61504
Bug ID: 61504
Summary: Move elision after cast to rvalue reference
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dyp-cpp at gmx dot net
Created attachment 32935
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32935action=edit
Test case as in description.
Move elision is applied even though the object has been bound to a reference
(see [class.copy]/31). Test case:
---
#include iostream
struct loud
{
loud(){ std::cout default\n; }
loud(loud ) { std::cout move\n; }
~loud() { std::cout dtor\n; }
};
int main()
{
loud l1{ static_castloud(loud{}) };
}
--
Expected output (also, recent clang++):
default
move
dtor
dtor
Output produced by g++ -std=c++11 -Wall -Wextra -pedantic 4.10.0 20140611:
default
dtor
Possibly related:
http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_defects.html#1376
[Bug ada/61505] New: [4.10 Regression] bootstrap broken by ada/gnat_rm.texi after r211448
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61505 Bug ID: 61505 Summary: [4.10 Regression] bootstrap broken by ada/gnat_rm.texi after r211448 Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: charlet at adacore dot com, ebotcazou at libertysufr dot fr On x86_64-apple-darwin13 bootstrap is broken when processing ada/gnat_rm.texi after r211448 (makeinfo is makeinfo (GNU texinfo) 5.2., bootstrapping compilers are from gcc 211652, built with an older version of ada/gnat_rm.texi): if [ xinfo = xinfo ]; then \ rm -f doc/gnat_rm.info*; \ makeinfo --split-size=500 --split-size=500 --split-size=500 --no-split -I../../_clean/gcc/doc/include \ -I../../_clean/gcc/ada -o doc/gnat_rm.info ../../_clean/gcc/ada/gnat_rm.texi; \ else true; fi ../../_clean/gcc/ada/gnat_rm.texi:4107: warning: @itemize has text but no @item ../../_clean/gcc/ada/gnat_rm.texi:12057: @item outside of table or list ../../_clean/gcc/ada/gnat_rm.texi:12068: @item outside of table or list ... ../../_clean/gcc/ada/gnat_rm.texi:13938: @item outside of table or list ../../_clean/gcc/ada/gnat_rm.texi:12053: warning: @itemize has text but no @item ../../_clean/gcc/ada/gnat_rm.texi:728: warning: node `Index' is prev for `What This Reference Manual Contains' in menu but not in sectioning ../../_clean/gcc/ada/gnat_rm.texi:864: warning: node `Pragma Abort_Defer' is next for `Related Information' in menu but not in sectioning ../../_clean/gcc/ada/gnat_rm.texi:1109: warning: node `Related Information' is prev for `Pragma Abort_Defer' in menu but not in sectioning ../../_clean/gcc/ada/gnat_rm.texi:1563: warning: node next `Pragma Assume_No_Invalid_Values' in menu `Pragma Attribute_Definition' and in sectioning `Pragma Ast_Entry' differ ../../_clean/gcc/ada/gnat_rm.texi:1614: warning: node next `Pragma Ast_Entry' in menu `Pragma C_Pass_By_Copy' and in sectioning `Pragma Attribute_Definition' differ ../../_clean/gcc/ada/gnat_rm.texi:1614: warning: node prev `Pragma Ast_Entry' in menu `Pragma Attribute_Definition' and in sectioning `Pragma Assume_No_Invalid_Values' differ ../../_clean/gcc/ada/gnat_rm.texi:1636: warning: node next `Pragma Attribute_Definition' in menu `Pragma Ast_Entry' and in sectioning `Pragma C_Pass_By_Copy' differ ../../_clean/gcc/ada/gnat_rm.texi:1636: warning: node prev `Pragma Attribute_Definition' in menu `Pragma Assume_No_Invalid_Values' and in sectioning `Pragma Ast_Entry' differ ../../_clean/gcc/ada/gnat_rm.texi:1661: warning: node prev `Pragma C_Pass_By_Copy' in menu `Pragma Ast_Entry' and in sectioning `Pragma Attribute_Definition' differ ../../_clean/gcc/ada/gnat_rm.texi:7738: warning: node `Aspect Abstract_State' is next for `Pragma Wide_Character_Encoding' in menu but not in sectioning ../../_clean/gcc/ada/gnat_rm.texi:7858: warning: node `Pragma Wide_Character_Encoding' is prev for `Aspect Abstract_State' in menu but not in sectioning ../../_clean/gcc/ada/gnat_rm.texi:8150: warning: node `Attribute Abort_Signal' is next for `Aspect Warnings' in menu but not in sectioning ../../_clean/gcc/ada/gnat_rm.texi:8246: warning: node `Aspect Warnings' is prev for `Attribute Abort_Signal' in menu but not in sectioning ../../_clean/gcc/ada/gnat_rm.texi:9552: warning: node `Partition-Wide Restrictions' is next for `Attribute Word_Size' in menu but not in sectioning ../../_clean/gcc/ada/gnat_rm.texi:9579: warning: node `Attribute Word_Size' is prev for `Partition-Wide Restrictions' in menu but not in sectioning ../../_clean/gcc/ada/gnat_rm.texi:9656: warning: node `Program Unit Level Restrictions' is prev for `Immediate_Reclamation' in menu but not in sectioning ../../_clean/gcc/ada/gnat_rm.texi:10266: warning: node `No_Elaboration_Code' is next for `Static_Storage_Size' in menu but not in sectioning ../../_clean/gcc/ada/gnat_rm.texi:10272: warning: node `Immediate_Reclamation' is next for `Program Unit Level Restrictions' in menu but not in sectioning ../../_clean/gcc/ada/gnat_rm.texi:10297: warning: node `Static_Storage_Size' is prev for `No_Elaboration_Code' in menu but not in sectioning ../../_clean/gcc/ada/gnat_rm.texi:10424: warning: node `Standard I/O Packages' is next for `SPARK_05' in menu but not in sectioning ../../_clean/gcc/ada/gnat_rm.texi:16915: warning: node `SPARK_05' is prev for `Standard I/O Packages' in menu but not in sectioning ../../_clean/gcc/ada/gnat_rm.texi:17164: warning: node `System.Wch_Con (s-wchcon.ads)' is prev for `Text_IO Stream Pointer Positioning' in menu but not in sectioning ../../_clean/gcc/ada/gnat_rm.texi:17299: warning: node `Wide_Text_IO Stream Pointer Positioning' is next for `Text_IO Facilities for Unbounded Strings' in menu but not in sectioning ../../_clean/gcc/ada/gnat_rm.texi:17516: warning: node `Text_IO
[Bug middle-end/53696] [4.8/4.9/4.10 Regression] ICE: SIGSEGV in gimplify_decl_expr (gimplify.c:1454) with -fkeep-inline-functions on invalid use of lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53696 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Jason Merrill jason at gcc dot gnu.org --- Can't reproduce on the current 4.8 or 4.9 branch either. Closing.
[Bug testsuite/61415] PowerPC test gcc.target/powerpc/tfmode_off.c fails if -mlong-double-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61415 --- Comment #2 from Peter Bergner bergner at gcc dot gnu.org --- Author: bergner Date: Fri Jun 13 18:42:53 2014 New Revision: 211653 URL: https://gcc.gnu.org/viewcvs?rev=211653root=gccview=rev Log: gcc/ PR target/61415 * config/rs6000/rs6000-builtin.def (BU_MISC_1): Delete. (BU_MISC_2): Rename to ... (BU_LDBL128_2): ... this. * config/rs6000/rs6000.h (RS6000_BTM_LDBL128): New define. (RS6000_BTM_COMMON): Add RS6000_BTM_LDBL128. * config/rs6000/rs6000.c (rs6000_builtin_mask_calculate): Handle RS6000_BTM_LDBL128. (rs6000_invalid_builtin): Add long double 128-bit builtin support. (rs6000_builtin_mask_names): Add RS6000_BTM_LDBL128. * config/rs6000/rs6000.md (unpacktf_0): Remove define)expand. (unpacktf_1): Likewise. * doc/extend.texi (__builtin_longdouble_dw0): Remove documentation. (__builtin_longdouble_dw1): Likewise. * doc/sourcebuild.texi (longdouble128): Document. gcc/testsuite/ PR target/61415 * lib/target-supports.exp (check_effective_target_longdouble128): New. * gcc.target/powerpc/pack02.c: Use it. * gcc.target/powerpc/tfmode_off.c: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000-builtin.def trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/rs6000/rs6000.h trunk/gcc/config/rs6000/rs6000.md trunk/gcc/doc/extend.texi trunk/gcc/doc/sourcebuild.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/powerpc/pack02.c trunk/gcc/testsuite/gcc.target/powerpc/tfmode_off.c trunk/gcc/testsuite/lib/target-supports.exp
[Bug ada/61505] [4.10 Regression] bootstrap broken by ada/gnat_rm.texi after r211448
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61505 Arnaud Charlet charlet at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||charlet at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |4.10.0 --- Comment #1 from Arnaud Charlet charlet at gcc dot gnu.org --- This was an oversight, fixed right after.
[Bug c++/61500] [C++11] [4.8/4.9 Regression] Can't take pointer to member referenced via member pointer template parameter.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61500 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-06-13 CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/61488] Regression in template argument substitution in 4.9+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61488 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-06-13 CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug c/61502] == comparison on one-past pointer gives wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot com --- Just because two pointers print the same and have the same bit-pattern doesn't mean they need to compare equal (see the response to DR#260, which may be presumed to apply to C11 in the absence of relevant textual changes to make it not apply).
[Bug ada/61505] [4.10 Regression] bootstrap broken by ada/gnat_rm.texi after r211448
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61505 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- This was an oversight, fixed right after. Fixed by what? bootstrapping r211652 with Ada is failing.
[Bug ada/61505] [4.10 Regression] bootstrap broken by ada/gnat_rm.texi after r211448
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61505 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2014-06-13 Resolution|FIXED |--- Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- I am at stage 2 now after using makeinfo (GNU texinfo) 4.8 instead of 5.2.
[Bug c++/57573] [C++1y] bogus taking address of temporary error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57573 Richard Smith richard-gccbugzilla at metafoo dot co.uk changed: What|Removed |Added CC||richard-gccbugzilla@metafoo ||.co.uk --- Comment #1 from Richard Smith richard-gccbugzilla at metafoo dot co.uk --- This seems to work with GCC trunk.
[Bug c++/57644] [C++1y] Cannot bind bitfield to lvalue reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57644 Richard Smith richard-gccbugzilla at metafoo dot co.uk changed: What|Removed |Added CC||richard-gccbugzilla@metafoo ||.co.uk --- Comment #2 from Richard Smith richard-gccbugzilla at metafoo dot co.uk --- Seems to work with GCC trunk.
[Bug c++/61402] [C++1y] Init-capture with side effect not working for some types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61402 Richard Smith richard-gccbugzilla at metafoo dot co.uk changed: What|Removed |Added CC||richard-gccbugzilla@metafoo ||.co.uk --- Comment #2 from Richard Smith richard-gccbugzilla at metafoo dot co.uk --- Your testcase has undefined behavior: [ i = ++t ] /*...*/ (t); The increment and load of 't' are unsequenced.
[Bug bootstrap/61388] [4.8 Regression] linux/microblaze fails to build: undefined machine-specific constraint at this point: Q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61388 --- Comment #3 from Michael Eager eager at eagercon dot com --- What sources are you building? When I build --target=microblaze-xilinx-elf from the current sources, I see the same warning message for microblaze.md that you list. I do not see the other errors. Constraint Q is defined in constraints.md.
[Bug c++/61484] [C++11] [constexpr] can't initialize constexpr multi-dimentional array of a literal type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61484 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #2 from Daniel Krügler daniel.kruegler at googlemail dot com --- The same error exists in 4.10.0 20140612 (experimental)
[Bug c++/61488] [4.9/4.10 regression] Regression in template argument substitution in 4.9+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61488 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com --- The error also occurs for 4.10.0 20140612 (experimental)
[Bug c++/61500] [C++11] [4.8/4.9 Regression] Can't take pointer to member referenced via member pointer template parameter.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61500 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com --- The same problem exists in 4.10.0 20140612 (experimental)
[Bug c/61502] == comparison on one-past pointer gives wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 Harald van Dijk harald at gigawatt dot nl changed: What|Removed |Added CC||harald at gigawatt dot nl --- Comment #2 from Harald van Dijk harald at gigawatt dot nl --- DR#260 applies when using *p as if it is y, just because it happens to compare equal to it. For example, attempting to use it to read the value of y is not permitted, even if guarded by an if (p == y) condition. But that isn't the case here: the pointer value x + 1 is used in a way described in the standard as the behaviour for the one-past-array values: the standard doesn't just permit them to compare equal to an object immediately following it in memory; what it does (because of the way it is worded) is require them to compare equal to an object immediately following it in memory. (But I cannot even hazard a guess as to whether that is intentional.)
[Bug testsuite/61415] PowerPC test gcc.target/powerpc/tfmode_off.c fails if -mlong-double-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61415 --- Comment #3 from Peter Bergner bergner at gcc dot gnu.org --- Author: bergner Date: Fri Jun 13 21:56:16 2014 New Revision: 211656 URL: https://gcc.gnu.org/viewcvs?rev=211656root=gccview=rev Log: gcc/ Backport from mainline 2014-06-13 Peter Bergner berg...@vnet.ibm.com PR target/61415 * config/rs6000/rs6000-builtin.def (BU_MISC_1): Delete. (BU_MISC_2): Rename to ... (BU_LDBL128_2): ... this. * config/rs6000/rs6000.h (RS6000_BTM_LDBL128): New define. (RS6000_BTM_COMMON): Add RS6000_BTM_LDBL128. * config/rs6000/rs6000.c (rs6000_builtin_mask_calculate): Handle RS6000_BTM_LDBL128. (rs6000_invalid_builtin): Add long double 128-bit builtin support. (rs6000_builtin_mask_names): Add RS6000_BTM_LDBL128. * config/rs6000/rs6000.md (unpacktf_0): Remove define)expand. (unpacktf_1): Likewise. * doc/extend.texi (__builtin_longdouble_dw0): Remove documentation. (__builtin_longdouble_dw1): Likewise. * doc/sourcebuild.texi (longdouble128): Document. gcc/testsuite/ Backport from mainline 2014-06-13 Peter Bergner berg...@vnet.ibm.com PR target/61415 * lib/target-supports.exp (check_effective_target_longdouble128): New. * gcc.target/powerpc/pack02.c: Use it. * gcc.target/powerpc/tfmode_off.c: Likewise. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/rs6000/rs6000-builtin.def branches/gcc-4_9-branch/gcc/config/rs6000/rs6000.c branches/gcc-4_9-branch/gcc/config/rs6000/rs6000.h branches/gcc-4_9-branch/gcc/config/rs6000/rs6000.md branches/gcc-4_9-branch/gcc/doc/extend.texi branches/gcc-4_9-branch/gcc/doc/sourcebuild.texi branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/testsuite/gcc.target/powerpc/pack02.c branches/gcc-4_9-branch/gcc/testsuite/gcc.target/powerpc/tfmode_off.c branches/gcc-4_9-branch/gcc/testsuite/lib/target-supports.exp
[Bug testsuite/61415] PowerPC test gcc.target/powerpc/tfmode_off.c fails if -mlong-double-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61415 --- Comment #4 from Peter Bergner bergner at gcc dot gnu.org --- Author: bergner Date: Fri Jun 13 21:58:49 2014 New Revision: 211657 URL: https://gcc.gnu.org/viewcvs?rev=211657root=gccview=rev Log: gcc/ Backport from mainline 2014-06-13 Peter Bergner berg...@vnet.ibm.com PR target/61415 * config/rs6000/rs6000-builtin.def (BU_MISC_1): Delete. (BU_MISC_2): Rename to ... (BU_LDBL128_2): ... this. * config/rs6000/rs6000.h (RS6000_BTM_LDBL128): New define. (RS6000_BTM_COMMON): Add RS6000_BTM_LDBL128. * config/rs6000/rs6000.c (rs6000_builtin_mask_calculate): Handle RS6000_BTM_LDBL128. (rs6000_invalid_builtin): Add long double 128-bit builtin support. (rs6000_builtin_mask_names): Add RS6000_BTM_LDBL128. * config/rs6000/rs6000.md (unpacktf_0): Remove define)expand. (unpacktf_1): Likewise. * doc/extend.texi (__builtin_longdouble_dw0): Remove documentation. (__builtin_longdouble_dw1): Likewise. * doc/sourcebuild.texi (longdouble128): Document. gcc/testsuite/ Backport from mainline 2014-06-13 Peter Bergner berg...@vnet.ibm.com PR target/61415 * lib/target-supports.exp (check_effective_target_longdouble128): New. * gcc.target/powerpc/pack02.c: Use it. * gcc.target/powerpc/tfmode_off.c: Likewise. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/rs6000/rs6000-builtin.def branches/gcc-4_8-branch/gcc/config/rs6000/rs6000.c branches/gcc-4_8-branch/gcc/config/rs6000/rs6000.h branches/gcc-4_8-branch/gcc/config/rs6000/rs6000.md branches/gcc-4_8-branch/gcc/doc/extend.texi branches/gcc-4_8-branch/gcc/doc/sourcebuild.texi branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/gcc.target/powerpc/pack02.c branches/gcc-4_8-branch/gcc/testsuite/gcc.target/powerpc/tfmode_off.c branches/gcc-4_8-branch/gcc/testsuite/lib/target-supports.exp
[Bug c++/58704] [c++11] ICE initializing array member of template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58704 Paul Pluzhnikov ppluzhnikov at google dot com changed: What|Removed |Added CC||ppluzhnikov at google dot com --- Comment #6 from Paul Pluzhnikov ppluzhnikov at google dot com --- We've hit this in gcc-4.8 and 4.9 as well. Backport? Google ref: b/15616365
[Bug c++/61506] New: ICE [4.10 Regression] triggered by solution to #61446
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61506 Bug ID: 61506 Summary: ICE [4.10 Regression] triggered by solution to #61446 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: juergen.reuter at desy dot de I tried to compile the software package LHAPDF from http://lhapdf.hepforge.org and this triggered this compiler error: PDF.cc: In member function 'virtual void boost::exception_detail::clone_implboost::exception_detail::error_info_injectorboost::bad_lexical_cast ::_ZTv0_n32_NK5boost16exception_detail10clone_implINS0_19error_info_injectorINS_16bad_lexical_cast7rethrowEv() const': PDF.cc:29:1: error: unrecognizable insn: } ^ (call_insn/j 4 3 5 (call (mem/u/c :DI (const:DI (unspec:DI [ (symbol_ref/i:DI (_ZNK5boost16exception_detail10clone_implINS0_19error_info_injectorINS_16bad_lexical_cast7rethrowEv) [flags 0x1] function_decl 0x1104dd700 rethrow) ] UNSPEC_GOTPCREL)) [0 S8 A8]) (const_int 0 [0])) /opt/local/include/boost/exception/exception.hpp:464 -1 (nil) (nil)) PDF.cc:29:1: internal compiler error: in insn_min_length, at config/i386/i386.md:1609 PDF.cc:29:1: internal compiler error: Abort trap: 6 g++: internal compiler error: Abort trap: 6 (program cc1plus) ../libtool: line 1122: 229 Abort trap: 6 g++ -DHAVE_CONFIG_H -I. -I../config -I../include/LHAPDF -I../include -I/usr/local/include -I/opt/local/include -Dunix -flat_namespace -pedantic -Wall -Wno-long-long -g -O2 -MT PDF.lo -MD -MP -MF .deps/PDF.Tpo -c PDF.cc -fno-common -DPIC -o .libs/PDF.o make[2]: *** [PDF.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive] Error 1 Unfortunately this isn't my code, so I cannot reduce this test case.
[Bug c++/61506] ICE [4.10 Regression] triggered by solution to #61446
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61506 Jürgen Reuter juergen.reuter at desy dot de changed: What|Removed |Added CC||juergen.reuter at desy dot de Version|unknown |4.10.0 Severity|normal |blocker
[Bug c++/61506] ICE [4.10 Regression] triggered by solution to #61446
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61506 --- Comment #1 from Jürgen Reuter juergen.reuter at desy dot de --- This is the author of the package: andy.buck...@cern.ch With version 6.1.2 of LHAPDF I get the error.
[Bug go/61496] [4.10 regression] Many Go tests FAIL with ld warning about go$zerovalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61496 --- Comment #1 from ian at gcc dot gnu.org ian at gcc dot gnu.org --- Author: ian Date: Fri Jun 13 22:30:47 2014 New Revision: 211658 URL: https://gcc.gnu.org/viewcvs?rev=211658root=gccview=rev Log: PR go/61496 * gospec.c (lang_specific_driver): On Solaris, when not using GNU ld, add -t option to avoid warning about common symbol changing size. Modified: trunk/gcc/go/ChangeLog trunk/gcc/go/gospec.c
