[Bug c/59801] New: GCC does not warn on unused global variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59801 Bug ID: 59801 Summary: GCC does not warn on unused global variable Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: chengniansun at gmail dot com Created attachment 31829 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31829action=edit the test case to trigger the bug. I used the following command $gcc -Wall -Wextra -pedantic -std=c11 -c unused-var.c And GCC outputs no warnings. However in the source file unused-var.c, the last global variable g_1853 is NOT used. // Start of the source file / /** * compile this program with the following command * * gcc -c -pedantic -std=c11 -Wall -Wextra unused-var.c */ static int g_37 = (-1L); static int *g_187 = g_37; /** * this variable will NOT be reported although it is NOT used. */ static int ** volatile g_1853 = g_187;/* VOLATILE GLOBAL g_1853 */ // End of the source file / The Gcc version is 4.9.0, built on 01/09/2014 gcc (GCC) 4.9.0 20140109 (experimental) Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug ipa/59775] [4.9 Regression] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59775 --- Comment #10 from David Kredba nheghathivhistha at gmail dot com --- After your patch applied it not segfaults any more. Unfortunately it not builds too, link of one module fails: [build MOD] swext S=/var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2 O=$S/solver/unxlngx6.pro W=$S/workdir/unxlngx6.pro mkdir -p $W/Module/ touch $W/Module/swext /var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/workdir/unxlngx6.pro/CxxObject/sc/source/filter/oox/workbookhelper.o: In function `~egmentProgressBar': /var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/include/oox/helper/progressbar.hxx:110: undefined reference to `oox::ISegmentProgresBar::~ISegmentProgressBar()' /var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/include/oox/helper/progressbar.hxx:110: undefined reference to `oox::ISegmentProgresBar::~ISegmentProgressBar()' /var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/include/oox/helper/progressbar.hxx:110: undefined reference to `oox::ISegmentProgresBar::~ISegmentProgressBar()' /var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/workdir/unxlngx6.pro/CxxObject/sc/source/filter/oox/workbookhelper.o: In function `ox::SegmentProgressBar::~SegmentProgressBar()': /var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/include/oox/helper/progressbar.hxx:110: undefined reference to `oox::ISegmentProgresBar::~ISegmentProgressBar()' /var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/workdir/unxlngx6.pro/CxxObject/sc/source/filter/oox/workbookhelper.o: In function `~egmentProgressBar': /var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/include/oox/helper/progressbar.hxx:110: undefined reference to `oox::ISegmentProgresBar::~ISegmentProgressBar()' collect2: error: ld returned 1 exit status Can this be anyhow related to your patch? Or GCC at all? Why it names the function as `~egmentProgressBar' when there is not such? : objdump -x /var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/workdir/unxlngx6.pro/CxxObject/sc/source/filter/oox/workbookheer.o |grep egment 372 .text.unlikely._ZN3oox18SegmentProgressBarD2Ev d3ca 2**1 373 .text._ZN3oox18SegmentProgressBarD2Ev 0025 d3d0 2**4 374 .text.unlikely._ZN3oox18SegmentProgressBarD0Ev d3f6 2**1 375 .text._ZN3oox18SegmentProgressBarD0Ev 002d d400 2**4 ld .text.unlikely._ZN3oox18SegmentProgressBarD2Ev .text.unlikely._ZN3oox18SegmentProgressBarD2Ev ld .text._ZN3oox18SegmentProgressBarD2Ev .text._ZN3oox18SegmentProgressBarD2Ev ld .text.unlikely._ZN3oox18SegmentProgressBarD0Ev .text.unlikely._ZN3oox18SegmentProgressBarD0Ev ld .text._ZN3oox18SegmentProgressBarD0Ev .text._ZN3oox18SegmentProgressBarD0Ev l .group _ZN3oox18SegmentProgressBarD5Ev wF .text._ZN3oox18SegmentProgressBarD2Ev 0025 _ZN3oox18SegmentProgressBarD2Ev *UND* _ZTVN3oox18SegmentProgressBarE *UND* _ZN3oox19ISegmentProgressBarD2Ev wF .text._ZN3oox18SegmentProgressBarD2Ev 0025 _ZN3oox18SegmentProgressBarD1Ev wF .text._ZN3oox18SegmentProgressBarD0Ev 002d _ZN3oox18SegmentProgressBarD0Ev *UND* _ZN3oox18SegmentProgressBarC1ERKN3com3sun4star3uno9ReferenceINS3_4task16XStatusIndicatorEEERKN3rtl8OUStringE 58c1 R_X86_64_GOTPCREL _ZN3oox18SegmentProgressBarD0Ev-0x0004 58ce R_X86_64_GOTPCREL _ZTVN3oox18SegmentProgressBarE-0x0004 58e6 R_X86_64_PLT32 _ZN3oox19ISegmentProgressBarD2Ev-0x0004 69af R_X86_64_PLT32 _ZN3oox18SegmentProgressBarC1ERKN3com3sun4star3uno9ReferenceINS3_4task16XStatusIndicatorEEERKN3rtl8OUStringE-0x0004 69cc R_X86_64_GOTPCREL _ZN3oox18SegmentProgressBarD0Ev-0x0004 69d9 R_X86_64_GOTPCREL _ZTVN3oox18SegmentProgressBarE-0x0004 69f2 R_X86_64_PLT32 _ZN3oox19ISegmentProgressBarD2Ev-0x0004 6ae7 R_X86_64_PLT32 _ZN3oox18SegmentProgressBarC1ERKN3com3sun4star3uno9ReferenceINS3_4task16XStatusIndicatorEEERKN3rtl8OUStringE-0x0004 6b04 R_X86_64_GOTPCREL _ZN3oox18SegmentProgressBarD0Ev-0x0004 6b11 R_X86_64_GOTPCREL _ZTVN3oox18SegmentProgressBarE-0x0004 6b2a R_X86_64_PLT32
[Bug c/59802] New: excessive compile time in loop unswitching
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59802 Bug ID: 59802 Summary: excessive compile time in loop unswitching Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Created attachment 31830 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31830action=edit gzipped C++ source code I just compiled the attached code with gcc trunk 20140112 on a x86_64 box with flag -O3 and it took over eight minutes. Using only -O2 took a more reasonable 2 minutes 38 seconds. For reference, the redhat version of gcc 482 took 2 minutes 32 seconds for -O3 and 2 minutes 11 seconds for -O2. I can see that for -O2, trunk is using about 30 seconds more CPU time, which is fine, but for -O3 over 5 minutes more. I tried flag -ftime-report and here are all the times 1%. Execution times (seconds) phase opt and generate : 465.18 (100%) usr 0.50 (57%) sys 468.04 (100%) wall 130935 kB (59%) ggc loop invariant motion : 22.50 ( 5%) usr 0.01 ( 1%) sys 22.85 ( 5%) wall 2 kB ( 0%) ggc loop unswitching: 302.37 (65%) usr 0.01 ( 1%) sys 303.82 (65%) wall 72 kB ( 0%) ggc CPROP : 85.02 (18%) usr 0.09 (10%) sys 85.52 (18%) wall 4445 kB ( 2%) ggc TOTAL : 466.12 0.88 469.55 221219 kB Suggest code rework for trunk for -O3, maybe in the area of loop unswitching. This bug may be a duplicate of bug 38518
[Bug testsuite/59494] [4.9 Regression] FAIL: gfortran.dg/vect/fast-math-mgrid-resid.f scan-tree-dump-times optimized vect_[^\\n]*\\+ 13
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59494 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Tue Jan 14 09:00:30 2014 New Revision: 206598 URL: http://gcc.gnu.org/viewcvs?rev=206598root=gccview=rev Log: PR testsuite/59494 * gfortran.dg/vect/fast-math-mgrid-resid.f: Change -fdump-tree-optimized to -fdump-tree-pcom-details in dg-options and cleanup-tree-dump from optimized to pcom. Remove scan-tree-dump-times for vect_\[^\\n\]*\\+, add scan-tree-dump-times for no suitable chains and Executing predictive commoning without unrolling. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f
[Bug c/59801] GCC does not warn on unused global variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59801 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Don't mark the variable volatile then. Volatile tells the compiler the variable may be used through means not known to the compiler, so it isn't unused.
[Bug testsuite/59494] [4.9 Regression] FAIL: gfortran.dg/vect/fast-math-mgrid-resid.f scan-tree-dump-times optimized vect_[^\\n]*\\+ 13
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59494 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/59006] [4.9 Regression] internal compiler error: in vect_transform_stmt, at tree-vect-stmts.c:5963
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59006 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue Jan 14 09:04:50 2014 New Revision: 206599 URL: http://gcc.gnu.org/viewcvs?rev=206599root=gccview=rev Log: 2014-01-14 Richard Biener rguent...@suse.de PR tree-optimization/58921 PR tree-optimization/59006 * tree-vect-loop-manip.c (vect_loop_versioning): Remove code hoisting invariant stmts. * tree-vect-stmts.c (vectorizable_load): Insert the splat of invariant loads on the preheader edge if possible. * gcc.dg/torture/pr58921.c: New testcase. * gcc.dg/torture/pr59006.c: Likewise. * gcc.dg/vect/pr58508.c: XFAIL no longer handled cases. Added: trunk/gcc/testsuite/gcc.dg/torture/pr58921.c trunk/gcc/testsuite/gcc.dg/torture/pr59006.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/pr58508.c trunk/gcc/tree-vect-loop-manip.c trunk/gcc/tree-vect-stmts.c
[Bug ipa/59775] [4.9 Regression] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59775 --- Comment #11 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to David Kredba from comment #10) After your patch applied it not segfaults any more. Unfortunately it not builds too, link of one module fails: [build MOD] swext S=/var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2 O=$S/solver/unxlngx6.pro W=$S/workdir/unxlngx6.pro mkdir -p $W/Module/ touch $W/Module/swext /var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/ workdir/unxlngx6.pro/CxxObject/sc/source/filter/oox/workbookhelper.o: In function `~egmentProgressBar': /var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/ include/oox/helper/progressbar.hxx:110: undefined reference to `oox::ISegmentProgresBar::~ISegmentProgressBar()' /var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/ include/oox/helper/progressbar.hxx:110: undefined reference to `oox::ISegmentProgresBar::~ISegmentProgressBar()' /var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/ include/oox/helper/progressbar.hxx:110: undefined reference to `oox::ISegmentProgresBar::~ISegmentProgressBar()' /var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/ workdir/unxlngx6.pro/CxxObject/sc/source/filter/oox/workbookhelper.o: In function `ox::SegmentProgressBar::~SegmentProgressBar()': /var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/ include/oox/helper/progressbar.hxx:110: undefined reference to `oox::ISegmentProgresBar::~ISegmentProgressBar()' /var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/ workdir/unxlngx6.pro/CxxObject/sc/source/filter/oox/workbookhelper.o: In function `~egmentProgressBar': /var/tmp/portage/app-office/libreoffice-4.1.4.2/work/libreoffice-4.1.4.2/ include/oox/helper/progressbar.hxx:110: undefined reference to `oox::ISegmentProgresBar::~ISegmentProgressBar()' collect2: error: ld returned 1 exit status Can this be anyhow related to your patch? Or GCC at all? No. I ran into exactly the same issue a while ago. $W/CxxObject/oox/source/helper/progressbar.o is missing in the list of object files when linking. This is a libreoffice bug.
[Bug tree-optimization/58921] [4.9 Regression] ICE with segfault on valid code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58921 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/59006] [4.9 Regression] internal compiler error: in vect_transform_stmt, at tree-vect-stmts.c:5963
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59006 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/58921] [4.9 Regression] ICE with segfault on valid code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58921 Bug 58921 depends on bug 59006, which changed state. Bug 59006 Summary: [4.9 Regression] internal compiler error: in vect_transform_stmt, at tree-vect-stmts.c:5963 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59006 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/58921] [4.9 Regression] ICE with segfault on valid code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58921 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue Jan 14 09:04:50 2014 New Revision: 206599 URL: http://gcc.gnu.org/viewcvs?rev=206599root=gccview=rev Log: 2014-01-14 Richard Biener rguent...@suse.de PR tree-optimization/58921 PR tree-optimization/59006 * tree-vect-loop-manip.c (vect_loop_versioning): Remove code hoisting invariant stmts. * tree-vect-stmts.c (vectorizable_load): Insert the splat of invariant loads on the preheader edge if possible. * gcc.dg/torture/pr58921.c: New testcase. * gcc.dg/torture/pr59006.c: Likewise. * gcc.dg/vect/pr58508.c: XFAIL no longer handled cases. Added: trunk/gcc/testsuite/gcc.dg/torture/pr58921.c trunk/gcc/testsuite/gcc.dg/torture/pr59006.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/pr58508.c trunk/gcc/tree-vect-loop-manip.c trunk/gcc/tree-vect-stmts.c
[Bug ada/57795] Fail Canadian cross building Ada
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57795 Yaakov (Cygwin Ports) yselkowitz at users dot sourceforge.net changed: What|Removed |Added CC||yselkowitz at users dot sourceforg ||e.net --- Comment #1 from Yaakov (Cygwin Ports) yselkowitz at users dot sourceforge.net --- I also ran into this when cross-compiling a native gcc with Ada (i686-pc-cygwin/x86_64-pc-cygwin/x86_64-pc-cygwin) in the process of porting GNAT to a new platform. In fact, I believe this would happen any time $build != $host (regardless of $target), but NOT with the typical cross-compiler ($build == $host, $host != $target). The root of the problem is RTS_DIR override (immediately prior to gnattools-cross rule) in gnattools/Makefile.in, which calls gnatls (for $build) where IIUC it should be something like $(GNATMAKE:gnatmake=gnatls) (for $host). There is another problem in this situation: in gcc/ada/gcc-interface/Make-lang.in, the xgnatugn rule (part of building doc/projects.texi and doc/gnat_ugn.texi) calls $(GNATMAKE), resulting in a xgnatugn which runs on $host instead of $build; this probably needs to be just gnatmake instead.
[Bug target/58172] ifcvt test failures for armv8-a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58172 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||ktkachov at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from ktkachov at gcc dot gnu.org --- These tests pass with multilib -march=armv8-a flags in current trunk (r206577) The lslc Ld, Ln, #1 is now being caught I believe. Closing as fixed, please reopen if you find them failing in some configuration.
[Bug c/52023] [C11] _Alignof (double) yields wrong value on x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52023 --- Comment #17 from Jan-Benedict Glaw jbg...@lug-owl.de --- (In reply to Marek Polacek from comment #16) tree field = build_decl (UNKNOWN_LOCATION, FIELD_DECL, NULL_TREE, ^ cc1plus: all warnings being treated as errors Should be fixed now. No, not yet. The most recent build for powerpc64-darwin done by my build robot still faces this warning and thus breaks: http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=89063 -- http://toolchain.lug-owl.de/buildbot/deliver_artifact.php?mode=viewid=733877 So what shall we do with this? The macro is called with two arguments, of which one (field) isn't used. Just mark it as unused or (void)-cast it away?
[Bug ada/55946] wrong tools used for build of gnattools [native-cross]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55946 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added CC||alexpux at gmail dot com --- Comment #7 from Eric Botcazou ebotcazou at gcc dot gnu.org --- *** Bug 57795 has been marked as a duplicate of this bug. ***
[Bug ada/57795] Fail Canadian cross building Ada
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57795 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org --- . *** This bug has been marked as a duplicate of bug 55946 ***
[Bug rtl-optimization/59802] excessive compile time in RTL optimizers (loop unswitching, CPROP)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59802 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||compile-time-hog Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-14 Component|c |rtl-optimization Summary|excessive compile time in |excessive compile time in |loop unswitching|RTL optimizers (loop ||unswitching, CPROP) Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- GCC 4.8 shows CPROP : 45.00 (57%) usr 0.02 ( 4%) sys 45.01 (57%) wall 4016 kB ( 2%) ggc TOTAL : 78.48 0.5779.04 213705 kB while GCC 4.9 has loop invariant motion : 10.11 (11%) usr 0.01 ( 2%) sys 10.16 (11%) wall 2 kB ( 0%) ggc loop unswitching: 9.81 (11%) usr 0.00 ( 0%) sys 9.83 (11%) wall 1 kB ( 0%) ggc CPROP : 48.16 (54%) usr 0.04 ( 7%) sys 48.20 (54%) wall kB ( 2%) ggc so I can't really confirm the unswitching slowness (this is r205857 which is somewhat older than your test). Generally I think we should probably consider removing RTL unswitching, there is not a single loop unswitched by RTL for this testcase.
[Bug rtl-optimization/59802] excessive compile time in RTL optimizers (loop unswitching, CPROP)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59802 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Oh, did you configure with --enable-checking=release for 4.9? (I did)
[Bug middle-end/38518] Excessive compile time with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38518 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- With GCC 4.8 we see loop invariant motion : 16.79 (32%) usr 0.02 ( 3%) sys 16.65 (31%) wall 148 kB ( 0%) ggc loop unswitching: 10.43 (20%) usr 0.02 ( 3%) sys 10.42 (20%) wall 0 kB ( 0%) ggc TOTAL : 52.07 0.6753.00 363360 kB which is RTL loop optimizers.
[Bug c/59749] unused warning not emited for unused static struct unles -save-temps is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59749 --- Comment #2 from Martin Husemann martin at netbsd dot org --- Unfortunately I can not reproduce the issue with the .i file generated with -save-temps (but still with the original .c file).
[Bug target/59803] New: [4.8 Regression] s390x -march=z10 reload ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59803
Bug ID: 59803
Summary: [4.8 Regression] s390x -march=z10 reload ICE
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
extern void baz (void) __attribute__ ((__noreturn__));
struct A { int g, h; };
extern struct A a;
struct B { unsigned char i, j, k, l, m; };
int c, d, e;
static int f;
void
foo (void)
{
f = 1;
}
void
bar (struct B *x)
{
x-i = e;
x-k = c;
x-l = d;
x-j = a.h;
x-m = f;
if (x-i != e) baz ();
if (x-k != c) baz ();
if (x-j != a.h) baz ();
}
ICEs with -O2 -march=z10 on 4.8 branch (verified with x86_64-linux -
s390x-linux cross at r206599). Works in 4.6 and works on the trunk, though it
is unclear if it just isn't latent.
Before reload we have:
(insn 10 9 11 2 (set (reg:SI 58 [ d ])
(mem/c:SI (symbol_ref:DI (d) var_decl 0x7f11a63617b8 d) [2 d+0 S4
A32])) rh1052372.ii:19 67 {*movsi_zarch}
(expr_list:REG_EQUIV (mem/c:SI (symbol_ref:DI (d) var_decl
0x7f11a63617b8 d) [2 d+0 S4 A32])
(nil)))
(insn 11 10 13 2 (set (mem:QI (plus:DI (reg/v/f:DI 57 [ x ])
(const_int 3 [0x3])) [0 x_4(D)-l+0 S1 A8])
(subreg:QI (reg:SI 58 [ d ]) 3)) rh1052372.ii:19 74 {*movqi}
(expr_list:REG_DEAD (reg:SI 58 [ d ])
(nil)))
and the ICE is about unrecognized instruction:
(insn 61 10 11 2 (set (reg:DI 12 %r12)
(const:DI (plus:DI (symbol_ref:DI (d) var_decl 0x7fbc425267b8 d)
(const_int 3 [0x3] rh1052372.ii:19 -1
(nil))
If I look at trunk dumps, it seems the difference there is already at expansion
time, while on the trunk *.expand has separate insns to set (symbol_ref:DI
(d)
to a pseudo and load (mem:SI (that pseudo)), 4.8 branch uses movsi_zarch insn
which is load from (mem:SI (symbol_ref:DI (d))). Then, at combine time
trunk combines the store with the load (and not symbol_ref larl), while 4.8
fails to combine the store with the load because I suppose lowest bit in larl
loaded value can't be set?
[Bug target/59803] [4.8 Regression] s390x -march=z10 reload ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59803 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||krebbel at gcc dot gnu.org Target Milestone|--- |4.8.3
[Bug c/52023] [C11] _Alignof (double) yields wrong value on x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52023 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #18 from Jakub Jelinek jakub at gcc dot gnu.org --- (void) cast it away in the Darwin macro. But that is tracked already in PR59496.
[Bug middle-end/28865] Structures with a flexible arrray member have wrong .size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28865 --- Comment #24 from Alan Modra amodra at gmail dot com --- Nick's latest patch passes bootstrap and regression testing powerpc64-linux.
[Bug c++/59791] [4.9 Regression] ICE: Error reporting routines re-entered. with -fcompare-debug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59791 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug rtl-optimization/59802] excessive compile time in RTL optimizers (loop unswitching, CPROP)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59802 --- Comment #3 from David Binderman dcb314 at hotmail dot com --- (In reply to Richard Biener from comment #2) Oh, did you configure with --enable-checking=release for 4.9? (I did) No, I used --enable-checking=yes.
[Bug c++/59800] Compilation with g++ fails when -Ofast -flto is used to compile code using some random distribution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59800 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-01-14 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- That's not an error but a warning?! Anyway, it's triggered by -Wmaybe-uninitialized. Also happens on trunk.
[Bug target/59803] [4.8 Regression] s390x -march=z10 reload ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59803 Andreas Krebbel krebbel at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-01-14 Assignee|unassigned at gcc dot gnu.org |krebbel at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Andreas Krebbel krebbel at gcc dot gnu.org --- There is a secondary reload which is supposed to handle that case. I'll try to figure out what went wrong here. Due to LRA being enabled by default on S/390 the situation on trunk is probably not comparable.
[Bug target/59797] GCC doesn't warn AVX-512 ABI change
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59797
--- Comment #2 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to Yukhin Kirill from comment #1)
Sorry, didn't get the problem.
According to output you provided - GCC warns ABI changes
Here is analogue for AVX2:
$ cat 2.c
typedef long long __m256i __attribute__ ((__vector_size__ (32),
__may_alias__));
__m256i
f1(__m256i x, __m256i y)
{
return y;
}
$ gcc -S 2.c
2.c: In function ‘f1’:
2.c:4:1: note: The ABI for passing parameters with 32-byte alignment has
changed in GCC 4.6
This isn't a ABI change warning. It just informs users
that GCC has changed ABI in GCC 4.6.
f1(__m256i x, __m256i y)
^
2.c:4:1: warning: AVX vector argument without AVX enabled changes the ABI
[enabled by default]
This is the ABI change warning for __m256i when AVX is disabled.
Difference is that AVX[2] warns about using data types without enabling
AVX2. Is that the case
We need a similar warning for __m512i when AVX-512 is disabled.
[Bug c++/59800] Compilation with g++ fails when -Ofast -flto is used to compile code using some random distribution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59800 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- And looking at the libstdc++ code, it indeed has _M_saved initially uninitialized, and all reads of it guarded by _M_saved_available flag. Supposedly predicate aware unitialized warning pass isn't able to figure that out.
[Bug target/59794] [4.7/4.8/4.9 Regression] i386 backend fails to detect MMX/SSE/AVX return value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59794
--- Comment #6 from H.J. Lu hjl.tools at gmail dot com ---
[hjl@gnu-17 tmp]$ cat /tmp/f.i
typedef int __v4si __attribute__ ((__vector_size__ (16)));
typedef long long __m128i __attribute__ ((__vector_size__ (16),
__may_alias__));
__m128i
f1(void)
{
return __extension__ (__m128i)(__v4si){ 0, 0, 0, 0 };
}
[hjl@gnu-17 tmp]$
/export/gnu/import/git/gcc-regression/gcc-4_0-branch/83189/usr/bin/gcc -S -O
/tmp/f.i -mno-sse -m32
/tmp/f.i: In function `f1':
/tmp/f.i:6: warning: SSE vector return without SSE enabled changes the ABI
[hjl@gnu-17 tmp]$
/export/gnu/import/git/gcc-regression/gcc-4_0-branch/83189/usr/bin/gcc -v
Reading specs from
/export/gnu/import/git/gcc-regression/gcc-4_0-branch/83189/usr/lib/gcc/x86_64-unknown-linux-gnu/3.5.0/specs
Configured with: ../../../gcc/configure
--prefix=/export/gnu/import/git/gcc-regression/gcc-4_0-branch/83189/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--enable-languages=c,c++ --disable-bootstrap
Thread model: posix
gcc version 3.5.0 20040615 (experimental)
[hjl@gnu-17 tmp]$
/export/gnu/import/git/gcc-regression/gcc-4_0-branch/85148/usr/bin/gcc -S -O
/tmp/f.i -mno-sse -m32
[hjl@gnu-17 tmp]$
/export/gnu/import/git/gcc-regression/gcc-4_0-branch/85148/usr/bin/gcc -v
Reading specs from
/export/gnu/import/git/gcc-regression/gcc-4_0-branch/85148/usr/lib/gcc/x86_64-unknown-linux-gnu/3.5.0/specs
Configured with: ../../../gcc/configure
--prefix=/export/gnu/import/git/gcc-regression/gcc-4_0-branch/85148/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--enable-languages=c,c++ --disable-bootstrap
Thread model: posix
gcc version 3.5.0 20040725 (experimental)
[hjl@gnu-17 tmp]$
[Bug rtl-optimization/59802] excessive compile time in RTL optimizers (loop unswitching, CPROP)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59802 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to David Binderman from comment #3) (In reply to Richard Biener from comment #2) Oh, did you configure with --enable-checking=release for 4.9? (I did) No, I used --enable-checking=yes. That makes the comparison to 4.8 invalid (uses --enable-checking=release by default). Btw, callgrind shows that compile-time is dominated by bitmap_intersection_of_preds (and bitmap_ior_and_compl), called from lcm.c:compute_available. LCM works with sbitmaps which can be very expensive for large functions. tree PRE uses regular bitmaps, but it seems that LCM can end up using the full bitmap via returning bitmap_ones from bitmap_intersection_of_preds (for a block with no preds). It seems compute_available doesn't use optimal iteration order and that explicitely representing the maximum set instead of handling unvisited preds makes things more expensive (need to use sbitmaps). Iterating in inverted postorder gets me CPROP : 2.13 ( 5%) usr 0.06 (10%) sys 2.20 ( 5%) wall kB ( 2%) ggc with no changes in generated code ...
[Bug c++/59804] New: C++ front-end checking ends in an infinite loop on erroneous code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59804 Bug ID: 59804 Summary: C++ front-end checking ends in an infinite loop on erroneous code Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jamborm at gcc dot gnu.org Created attachment 31831 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31831action=edit Testcase I discovered this problem when multidelta-reducing a different PR. Multidelta produced this invalid source that however causes the c++ front-end of an checking-enabled compiler to end up in an infinite loop (or just takes incredible time to finish but I doubt that). Release-checking g++ compains about errors and exits normally. x86_64-linux, no compiler options necessary.
[Bug target/59787] [ARM] mmx-2.c causes ICE when GCC is configured for cortex-a5/vfpv3-d16-fp16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59787
Renlin Li renlin.li at arm dot com changed:
What|Removed |Added
CC||renlin.li at arm dot com,
||yufeng at gcc dot gnu.org
--- Comment #1 from Renlin Li renlin.li at arm dot com ---
Confirm that, gcc.target/arm/mmx-2.c cause an ICE with the following
configuration.
--target=arm-none-linux-gnueabihf
--with-arch=armv7-a
--with-fpu=vfpv3-d16
--with-float=softfp
(insn 51 50 52 2 (set (reg:DI 534 [orig:139 D.4720 ] [139])
(mem/v/c:DI (plus:SI (reg/f:SI 102 sfp)
(const_int -20 [0xffec])) [0 llsink+0 S8 A64]))
mmx-2.c:4
2 447 {*iwmmxt_arm_movdi}
(nil))
(insn 573 0 0 (set (reg:DI 139 [ D.4720 ])
(reg:DI 534 [orig:139 D.4720 ] [139])) -1
(nil))
lra_constraints() keeps reloading reg 139 until Max. number of reload insns
is reached.
[Bug rtl-optimization/59802] excessive compile time in RTL optimizers (loop unswitching, CPROP)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59802 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00780.html Even better would be to get rid of the explicit maximum set (just ignore incoming edges with the maximum set, aka 'unvisited' edges during bitmap_intersection_of_preds). Basically follow what tree PRE does for antic-in compute. That would make using regular bitmaps possible (if that is a win - at least computing the changed bit is free). Also queuing succs at the end of the worklist messes up iteration order for everything but the first iteration. PRE uses a sbitmap that records whether a BB was changed. Anyway, the above simple patch dramatically improves the numbers for this testcase.
[Bug preprocessor/59805] New: invalid preprocessing directive not diagnosed with assembler-with-cpp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59805 Bug ID: 59805 Summary: invalid preprocessing directive not diagnosed with assembler-with-cpp Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: aldot at gcc dot gnu.org CC: tromey at redhat dot com -x assembler-with-cpp remains silent instead of emitting some kind of diagnostics. $ cat libcpp-bug.c # INCLUDE ./does-not-exist.HHH # HUH ./does-not-exist.HHH $ gcc -x assembler-with-cpp -o xxx.o -c libcpp-bug.c -W -Wall -pedantic -Wextra Properly diagnosed with c or c-header: $ gcc -x c -o xxx.o -c libcpp-bug.c -W -Wall -pedantic -Wextra libcpp-bug.c:1:3: error: invalid preprocessing directive #INCLUDE # INCLUDE ./does-not-exist.HHH ^ libcpp-bug.c:2:3: error: invalid preprocessing directive #HUH # HUH ./does-not-exist.HHH ^ libcpp-bug.c:2:0: warning: ISO C forbids an empty translation unit [-Wpedantic] # HUH ./does-not-exist.HHH ^ gcc-4.9-trunk@206144 Since the #INCLUDE was not processed this missing diagnostics resulted in wrong code generated, but adding that keyword. Didn't look if this is a driver bug.
[Bug target/59794] [4.7/4.8/4.9 Regression] i386 backend fails to detect MMX/SSE/AVX ABI changes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59794
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Summary|[4.7/4.8/4.9 Regression]|[4.7/4.8/4.9 Regression]
|i386 backend fails to |i386 backend fails to
|detect MMX/SSE/AVX return |detect MMX/SSE/AVX ABI
|value |changes
--- Comment #7 from H.J. Lu hjl.tools at gmail dot com ---
[hjl@gnu-17 tmp]$ cat /tmp/f.i
typedef int __v4si __attribute__ ((__vector_size__ (16)));
typedef long long __m128i __attribute__ ((__vector_size__ (16),
__may_alias__));
__m128i
f1(void)
{
return __extension__ (__m128i)(__v4si){ 0, 0, 0, 0 };
}
[hjl@gnu-17 tmp]$
/export/gnu/import/git/gcc-regression/gcc-4_0-branch/83189/usr/bin/gcc -S -O
/tmp/f.i -mno-sse -m32
/tmp/f.i: In function `f1':
/tmp/f.i:6: warning: SSE vector return without SSE enabled changes the ABI
[hjl@gnu-17 tmp]$
/export/gnu/import/git/gcc-regression/gcc-4_0-branch/83189/usr/bin/gcc -v
Reading specs from
/export/gnu/import/git/gcc-regression/gcc-4_0-branch/83189/usr/lib/gcc/x86_64-unknown-linux-gnu/3.5.0/specs
Configured with: ../../../gcc/configure
--prefix=/export/gnu/import/git/gcc-regression/gcc-4_0-branch/83189/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--enable-languages=c,c++ --disable-bootstrap
Thread model: posix
gcc version 3.5.0 20040615 (experimental)
[hjl@gnu-17 tmp]$
/export/gnu/import/git/gcc-regression/gcc-4_0-branch/85148/usr/bin/gcc -S -O
/tmp/f.i -mno-sse -m32
[hjl@gnu-17 tmp]$
/export/gnu/import/git/gcc-regression/gcc-4_0-branch/85148/usr/bin/gcc -v
Reading specs from
/export/gnu/import/git/gcc-regression/gcc-4_0-branch/85148/usr/lib/gcc/x86_64-unknown-linux-gnu/3.5.0/specs
Configured with: ../../../gcc/configure
--prefix=/export/gnu/import/git/gcc-regression/gcc-4_0-branch/85148/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--enable-languages=c,c++ --disable-bootstrap
Thread model: posix
gcc version 3.5.0 20040725 (experimental)
[hjl@gnu-17 tmp]$
[Bug target/59794] [4.7/4.8/4.9 Regression] i386 backend fails to detect MMX/SSE/AVX ABI changes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59794 --- Comment #8 from H.J. Lu hjl.tools at gmail dot com --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00784.html
[Bug fortran/59806] New: ICE with -ggdb AND -finit-real=snan AND namelist variable AND internal procedure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59806 Bug ID: 59806 Summary: ICE with -ggdb AND -finit-real=snan AND namelist variable AND internal procedure Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mrestelli at gmail dot com Hi all, the attached code results in an internal compiler error when compiled with gfortran -ggdb -finit-real=snan -c ice.f90 Removing -ggdb and/or -finit-real=snan the code compiles correctly. Also, removing the namelist containing xx the problem disappears. (Sorry for the long summary, could't find a shorter one). $ gfortran --version GNU Fortran (GCC) 4.9.0 20140110 (experimental) $ gfortran -ggdb -finit-real=snan -c ice.f90 ice.f90: In function ‘prog’: ice.f90:5:0: internal compiler error: in force_decl_die, at dwarf2out.c:20111 real :: xx ^ 0x704d34 force_decl_die gcc/dwarf2out.c:20111 0x705207 gen_namelist_decl gcc/dwarf2out.c:20632 0x700fd3 gen_decl_die gcc/dwarf2out.c:20435 0x71314f decls_for_scope gcc/dwarf2out.c:19969 0x6fe0ea gen_subprogram_die gcc/dwarf2out.c:18354 0x701014 gen_decl_die gcc/dwarf2out.c:20336 0x701df8 dwarf2out_function_decl gcc/dwarf2out.c:20776 0x75289c rest_of_handle_final gcc/final.c:4469 0x75289c execute gcc/final.c:4513 program prog implicit none real :: xx character(len=100) :: message ! removing the following line the problem disappears namelist /input/ xx contains subroutine check() write(message,'(e8.2)') xx end subroutine check end program prog
[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678 --- Comment #25 from Nick Maclaren nmm1 at cam dot ac.uk --- On Jan 10 2014, vincent-gcc at vinc17 dot net wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678 --- Comment #24 from Vincent Lefèvre vincent-gcc at vinc17 dot net - (In reply to Nick Maclaren from comment #23) If __STDC_IEC_559__ is unset or does not have the value 1, setting STDC FENV_ACCESS to on is undefined behaviour (see 6.10.8.3, 7.6 and Annex F), unless the implementation explicitly chooses to extend the language to support it. You're wrong. The C standard doesn't say that. I am sorry, but it is you that is wrong. 6.10.8.3 says: __STDC_IEC_559__ The integer constant 1, intended to indica te conformance to the specifications in annex F (IEC 60559 floating-point arithmetic). and nothing about STDC FENV_ACCESS. 3.4.3 says: undefined behavior behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements 4. Conformance, paragraph 2, says: ... Undefined behavior is otherwise indicated in this International Standard by the words undefined behavior or by the omission of any explicit definition of behavior. There is no difference in emphasis among these three; they all describe behavior that is undefined. What explicit definition of behavior is there for the case when STDC FENV_ACCESS is set to on but __STDC_IEC_559__ is not set to one? As there is none, it is undefined behaviour. gcc can therefore do whatever it likes. Regards, Nick Maclaren.
[Bug rtl-optimization/38518] Excessive compile time with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38518
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||stevenb.gcc at gmail dot com
--- Comment #6 from Richard Biener rguenth at gcc dot gnu.org ---
The issue here is the DF machinery, or rather the fact that RTL invariant
motion
calls df_analyze () for each loop, thus
void
move_loop_invariants (void)
{
struct loop *loop;
if (flag_ira_loop_pressure)
{
df_analyze ();
regstat_init_n_sets_and_refs ();
ira_set_pseudo_classes (true, dump_file);
calculate_loop_reg_pressure ();
regstat_free_n_sets_and_refs ();
}
df_set_flags (DF_EQ_NOTES + DF_DEFER_INSN_RESCAN);
/* Process the loops, innermost first. */
FOR_EACH_LOOP (loop, LI_FROM_INNERMOST)
{
curr_loop = loop;
/* move_single_loop_invariants for very large loops
is time consuming and might need a lot of memory. */
if (loop-num_nodes = (unsigned) LOOP_INVARIANT_MAX_BBS_IN_LOOP)
move_single_loop_invariants (loop);
}
here move_single_loop_invariants - find_invariants - find_defs which
does
static void
find_defs (struct loop *loop, basic_block *body)
{
unsigned i;
bitmap blocks = BITMAP_ALLOC (NULL);
for (i = 0; i loop-num_nodes; i++)
bitmap_set_bit (blocks, body[i]-index);
if (dump_file)
{
fprintf (dump_file,
*starting processing of loop %d **\n,
loop-num);
}
df_remove_problem (df_chain);
df_process_deferred_rescans ();
df_chain_add_problem (DF_UD_CHAIN);
df_set_blocks (blocks);
df_set_flags (DF_RD_PRUNE_DEAD_DEFS);
df_analyze ();
...
which is excessive. It looks like the above DF stuff does not affects the
whole
function but only the BBs in the loop. Still the fact that we iterate
from inner to outer loops still
makes the DF analysis time quadratic in the loop depth.
The testcase has only loops of depth 1 (but 2164 ones), so it seems that
the DF restriction to a set of BBs does not work as expected?
From the profile I see that the most time spent in df_analyze is
inverted_post_order_compute and post_order_compute (obviosly not
region aware!) and then bitmap_set_bit and df_prune_to_subcfg.
I wonder if it isn't possible to either update the DF during the
transform, deal with partly out-of-date DF info (like process
loop siblings without re-calculating DF, and re-compute whole FN
DF after such iteration).
[Bug c++/59791] [4.9 Regression] ICE: Error reporting routines re-entered. with -fcompare-debug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59791 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- You don't need -fcompare-debug for that, even just ./cc1plus -std=c++11 testcase.C ICEs (though, not with -quiet).
[Bug target/59787] [ARM] mmx-2.c causes ICE when GCC is configured for cortex-a5/vfpv3-d16-fp16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59787 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-14 CC||ktkachov at gcc dot gnu.org, ||vmakarov at redhat dot com Ever confirmed|0 |1 --- Comment #2 from ktkachov at gcc dot gnu.org --- Adding Vlad to cc, since this seems to be an LRA ICE.
[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678 --- Comment #26 from Vincent Lefèvre vincent-gcc at vinc17 dot net --- (In reply to Nick Maclaren from comment #25) 3.4.3 says: undefined behavior behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements 4. Conformance, paragraph 2, says: ... Undefined behavior is otherwise indicated in this International Standard by the words undefined behavior or by the omission of any explicit definition of behavior. There is no difference in emphasis among these three; they all describe behavior that is undefined. What explicit definition of behavior is there for the case when STDC FENV_ACCESS is set to on but __STDC_IEC_559__ is not set to one? The behavior is defined. The standard says, e.g. for C99: 7.6.1 The FENV_ACCESS pragma The FENV_ACCESS pragma provides a means to inform the implementation when a program might access the floating-point environment to test floating-point status flags or run under non-default floating-point control modes.184) [...] 184) The purpose of the FENV_ACCESS pragma is to allow certain optimizations that could subvert flag tests and mode changes (e.g., global common ubexpression elimination, code motion, and constant folding). In general, if the state of FENV_ACCESS is ``off'', the translator can assume that default modes are in effect and the flags are not tested. And there is here no relation at all with __STDC_IEC_559__. As there is none, it is undefined behaviour. gcc can therefore do whatever it likes. No.
[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678 --- Comment #27 from Nick Maclaren nmm1 at cam dot ac.uk --- On Jan 14 2014, vincent-gcc at vinc17 dot net wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678 What explicit definition of behavior is there for the case when STDC FENV_ACCESS is set to on but __STDC_IEC_559__ is not set to one? The behavior is defined. The standard says, e.g. for C99: 7.6.1 The FENV_ACCESS pragma The FENV_ACCESS pragma provides a means to inform the implementation when a program might access the floating-point environment to test floating-point status flags or run under non-default floating-point control modes. I suggest looking up the word explicit in a dictionary. Unless __STDC_IEC_559__ is set to 1, what modes and flags exist (and, even more importantly) what there semantics are) is at best implicit and more realistically unspecified - see footnote 204 for a clear statement of that. Have you ever implemented a C system for an architecture with non-IEEE arithmetic but with modes and flags? Because I have, and I have used several others. As there is none, it is undefined behaviour. gcc can therefore do whatever it likes. No. You are quite simply wrong. Regards, Nick Maclaren.
[Bug libstdc++/59807] New: mutex misses destructor if non-function call initialization is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59807 Bug ID: 59807 Summary: mutex misses destructor if non-function call initialization is used Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: ahanins at gmail dot com Hi, Follow up to https://sourceforge.net/p/mingw-w64/bugs/376/ This is related to GTHR interface to pthread. C++11 __mutex_base class does not define a destructor if __GTHREAD_MUTEX_INIT is defined. It means, underlying implementation (pthread for example) has no any means to do a resource cleanup when std::mutex is destructed. In particular, it causes semaphore object resource (handle) leak on Windows in MinGW winpthread implementation where semaphore object is created during first pthread_mutex_lock invocation. Wouldn't it be more robust to always define a destructor for __mutex_base which calls __gthread_mutex_destroy, or even more flexibly, introduce a separate macro like __GTHREAD_MUTEX_DESTROY_FUNCTION which controls whether destructor should be defined at all or not.
[Bug libstdc++/59807] mutex misses destructor if non-function call initialization is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59807
--- Comment #1 from Andrey H. ahanins at gmail dot com ---
Simplest code which leaks handles on Windows:
for(;;) {
std::mutex op_mutex;
op_mutex.lock();
op_mutex.unlock();
}
[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #28 from Vincent Lefèvre vincent-gcc at vinc17 dot net ---
(In reply to Nick Maclaren from comment #27)
On Jan 14 2014, vincent-gcc at vinc17 dot net wrote:
The FENV_ACCESS pragma provides a means to inform the implementation when a
program might access the floating-point environment to test floating-point
status flags or run under non-default floating-point control modes.
I suggest looking up the word explicit in a dictionary.
The above is an explicit definition. Where do you see an undefined behavior
here?
#include fenv.h
#pragma STDC FENV_ACCESS ON
int main (void)
{
return 0;
}
The modes and so on are dealt with in other parts of the standard, e.g.
Each of the macros
FE_DOWNWARD
FE_TONEAREST
FE_TOWARDZERO
FE_UPWARD
is defined if and only if the implementation supports getting and setting the
represented rounding direction by means of the fegetround and fesetround
functions.
This doesn't mean that the rounding direction will necessarily be honored even
for the basic operations (just like the C standard doesn't require 1.0+2.0 to
evaluate as 3.0, and a poorly-designed implementation could decide that 1-bit
accuracy is OK), but honoring the rounding direction when the processor does[*]
is a reasonable QoI feature. Basically, this means: disabling some
optimizations when STDC FENV_ACCESS is set to ON. This is what this bug is
about.
[*] a weaker requirement than __STDC_IEC_559__ being set to 1.
Note that the C standard doesn't explicitly say how a source file as a sequence
of bytes is to be interpreted as a sequence of character, so that if you just
restrict to the C standard, everything is undefined. The discussion is going
nowhere.
[Bug target/59808] New: [4.9 Regression] r206596 caused: FAIL: gcc.target/i386/sse-14.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59808 Bug ID: 59808 Summary: [4.9 Regression] r206596 caused: FAIL: gcc.target/i386/sse-14.c (test for excess errors) Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: kirill.yukhin at intel dot com On Linux/x86, r206596 caused: FAIL: gcc.target/i386/sse-14.c (test for excess errors)
[Bug target/59808] [4.9 Regression] r206596 caused: FAIL: gcc.target/i386/sse-14.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59808 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-14 Target Milestone|--- |4.9.0 Ever confirmed|0 |1
[Bug c++/59809] New: template non-type parameter in nested class-template said not be declared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59809
Bug ID: 59809
Summary: template non-type parameter in nested class-template
said not be declared
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jorenheit at gmail dot com
The following code results in a compiler error on GCC 4.7.2:
gccbug.cc:8:15: error: ‘V’ was not declared in this scope
Code:
// ---
// gccbug.cc
template typename T
struct S
{
template int V
struct Inner
{
int a{V};
};
};
// ---
Output of gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5'
--with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.2 (Debian 4.7.2-5)
Command that triggers the error:
g++ --std=c++11 -c gccbug.cc
This might be related to bug 57239.
[Bug target/59810] New: [AArch64] LDn/STn implementations are not ABI-conformant for bigendian.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59810 Bug ID: 59810 Summary: [AArch64] LDn/STn implementations are not ABI-conformant for bigendian. Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: belagod at gcc dot gnu.org Permuted loads/stores implemented in the aarch64 backend do not conform to AArch64 ABI for bigendian. The ABI states that ... On a little endian system this means that element 0 will always contain the lowest addressed element of a short vector; on a big endian system element 0 will contain the highest addressed element of a short vector. In the implementations of vec_loadlanes and vec_storelanes in aarch64-simd.md, they are just loaded lane-wise for both endianness. This may be correct for little endian, but for bigendian, this is the reversed order. Because the architecture does not offer a way to perform opaque loads/stores(LDR q, STR q) for permuted loads, the lanes will need to be reversed after permuted loading and reversed before permuted storing.
[Bug target/59794] [4.7/4.8/4.9 Regression] i386 backend fails to detect MMX/SSE/AVX ABI changes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59794 --- Comment #9 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org --- Author: hjl Date: Tue Jan 14 16:41:10 2014 New Revision: 206603 URL: http://gcc.gnu.org/viewcvs?rev=206603root=gccview=rev Log: Consolidate ABI warning into type_natural_mode gcc/ PR target/59794 * config/i386/i386.c (type_natural_mode): Add a bool parameter to indicate if type is used for function return value. Warn ABI change if the vector mode isn't available for function return value. (ix86_function_arg_advance): Pass false to type_natural_mode. (ix86_function_arg): Likewise. (ix86_gimplify_va_arg): Likewise. (function_arg_32): Don't warn ABI change. (ix86_function_value): Pass true to type_natural_mode. (ix86_return_in_memory): Likewise. (ix86_struct_value_rtx): Removed. (TARGET_STRUCT_VALUE_RTX): Likewise. gcc/testsuite/ PR target/59794 * g++.dg/ext/vector23.C: Also prune ABI change for Linux/x86. * gcc.target/i386/pr39162.c (y): New __m256i variable. (bar): Change return type to void. Set y to x. * gcc.target/i386/pr59794-1.c: New testcase. * gcc.target/i386/pr59794-2.c: Likewise. * gcc.target/i386/pr59794-3.c: Likewise. * gcc.target/i386/pr59794-4.c: Likewise. * gcc.target/i386/pr59794-5.c: Likewise. * gcc.target/i386/pr59794-6.c: Likewise. * gcc.target/i386/pr59794-7.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/i386/pr59794-1.c trunk/gcc/testsuite/gcc.target/i386/pr59794-2.c trunk/gcc/testsuite/gcc.target/i386/pr59794-3.c trunk/gcc/testsuite/gcc.target/i386/pr59794-4.c trunk/gcc/testsuite/gcc.target/i386/pr59794-5.c trunk/gcc/testsuite/gcc.target/i386/pr59794-6.c trunk/gcc/testsuite/gcc.target/i386/pr59794-7.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/ext/vector23.C trunk/gcc/testsuite/gcc.target/i386/pr39162.c
[Bug target/59803] [4.8 Regression] s390x -march=z10 reload ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59803 --- Comment #2 from Andreas Krebbel krebbel at gcc dot gnu.org --- Created attachment 31832 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31832action=edit Experimental fix This patch fixes the problem. I'll post/commit it when it passed regtesting.
[Bug libstdc++/59807] mutex misses destructor if non-function call initialization is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59807 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- It a target's pthread_mutex requires cleanup then it should not define __GTHREAD_MUTEX_INIT, it should use the init function, and then it gets a chance to also run a destroy function. That can be controlled by defining _GTHREAD_USE_MUTEX_INIT_FUNC in the relevant libstdc++-v3/config/os/xxx/os_defines.h header.
[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678 --- Comment #29 from Nick Maclaren nmm1 at cam dot ac.uk --- On Jan 14 2014, vincent-gcc at vinc17 dot net wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678 The FENV_ACCESS pragma provides a means to inform the implementation whe n a program might access the floating-point environment to test floating-poi nt status flags or run under non-default floating-point control modes. I suggest looking up the word explicit in a dictionary. The above is an explicit definition. Where do you see an undefined behavior here? It is not an explicit definition of BEHAVIOR (my emphasis), and what it implies for any nnon-IEEE system is completely unclear. Of the two countries active during the standardisation of C99, one voted no on these grounds (among others). Note that the C standard doesn't explicitly say how a source file as a sequ ence of bytes is to be interpreted as a sequence of character, so that if you ju st restrict to the C standard, everything is undefined. Yes, it does - it's implementation-defined in 5.1.1.2 Translation phases, paragraph 1.1: Physical source file multibyte characters are mapped, in an implementation-defined manner, to the source character set (introducing new-line characters for end-of-line indicators) if necessary. ... You imply that you are also relying on some other standards or specifications. ISO/IEC Directives Part II is quite clear (in 6.2.2) that they shall be referenced in the ISO standard. Which ones are you referring to and why? If you are claiming that C99 and beyond support only systems that conform to IEEE 754, then I can tell you that was not the intention of WG21 at the time and is not a requirement of the standard. To repeat, how many other such systems are you familiar with? The grounds that the UK voted no to this aspect was that the whole 'IEEE 754' morass (including fenv.h) was neither dependent on __STD_IEC_559__ nor implementation-dependent nor sufficiently explicit to be interpreted on any non-IEEE system. The discussion is going nowhere. Now, at least that is true. Regards, Nick Maclaren.
[Bug libstdc++/59807] mutex misses destructor if non-function call initialization is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59807 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- In other words, we already have all the machinery in place to handle such cases, it just needs to be used for the target.
[Bug fortran/59811] New: Huge increase in memory usage and compile time with gfortran 4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59811 Bug ID: 59811 Summary: Huge increase in memory usage and compile time with gfortran 4.8 Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: bastian.feigl at kit dot edu Created attachment 31833 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31833action=edit Example fortran source code file with problems with gfortran 4.8 When switching from gfortran 4.7 to gfortran 4.8 the memory usage and compile time vastly increases for some files in our project, e.g. for the attached example file. gfortran 4.8.2 needs 50s to compile, using up to 1.7 GB of RAM, while gfortran 4.7 compiles it in 7s with a memory usage of 136 MB. The command line of the gfortran-call for the attached example is /opt/gcc/4.8.2/bin/gfortran -fno-automatic -ffixed-line-length-none -O2 -c FermionBoxEventempCoupling_Div.F -o output.o The problem seems to be partly linked to the option -fno-automatic, since omitting it inhibits the memory increase, but the compile time is still 14s with gfortran 4.8, compared to 6s with gfortran 4.7. The problem arises with optimizations -O2 and -O1 lead to a similar discrepancy, with -O0 the problem does not exist. The gfortran 4.8 which shows the problematic behaviour is built with: Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.8.2/configure --prefix=/opt/gcc/4.8.2 --enable-languages=c,c++,fortran gcc version 4.8.2 (GCC) The gfortran 4.7 is the built-in from openSUSE 12.2: Target: x86_64-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.7 --enable-ssp --disable-libssp --disable-libitm --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --enable-linker-build-id --program-suffix=-4.7 --enable-linux-futex --without-system-libunwind --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux gcc version 4.7.1 20120723 [gcc-4_7-branch revision 189773] (SUSE Linux)
[Bug c/59801] GCC does not warn on unused global variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59801
--- Comment #2 from Chengnian Sun chengniansun at gmail dot com ---
Thanks for your reply. One more question regarding this issue. Support I have a
closed program
static volatile int a;
int main() {return 0;}
Even though a is not read anywhere in this program, do you mean that it is
still possible for a to be used somewhere else?
I checked the C standard
draft(http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf). In Page 122,
it says that what constitutes an access to an object that has volatile-qualified
type is implementation-defined. Is this the reason why GCC thinks the variable
is used, but Clang treats it unused?
Thanks again.
[Bug c/59812] New: Missing aggressive loop optimization warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59812
Bug ID: 59812
Summary: Missing aggressive loop optimization warning
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Google ref: b/12015772
The following source:
int x[4];
int foo (int a)
{
int n = a ? 1 : 2;
int i;
for(i = 0; i 4 + n; i++ )
x[i]++;
return 0;
}
compiles into infinite loop due to aggressive loop optimization,
but produces no warnings with
g++ (GCC) 4.9.0 20140110 (experimental)
g++ -c -O2 -Wall -Wextra t.c objdump -d t.o
t.o: file format elf64-x86-64
Disassembly of section .text:
_Z3fooi:
0: b8 00 00 00 00 mov$0x0,%eax
5: 83 00 01addl $0x1,(%rax)
8: 48 83 c0 04 add$0x4,%rax
c: eb f7 jmp5 _Z3fooi+0x5
It would be much nicer to end-user to emit compile time warning here.
[Bug c/59812] Missing aggressive loop optimization warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59812 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- The warning is documented to warn only about loops with constant number of iterations. Generally the number of iterations analysis which computes that the loop has at most 4 (valid) iterations on the other side doesn't have access to VRP to see what the values would be here, while for post-VRP it could use remembered SSA_NAME_RANGE_INFO, during VRP when this is optimized it can't, it isn't stored there yet.
[Bug target/59787] [ARM] mmx-2.c causes ICE when GCC is configured for cortex-a5/vfpv3-d16-fp16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59787 --- Comment #3 from Vladimir Makarov vmakarov at gcc dot gnu.org --- Author: vmakarov Date: Tue Jan 14 19:07:01 2014 New Revision: 206605 URL: http://gcc.gnu.org/viewcvs?rev=206605root=gccview=rev Log: 2014-01-14 Vladimir Makarov vmaka...@redhat.com PR target/59787 * config/arm/arm.c (arm_coproc_mem_operand): Add lra_in_progress. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c
[Bug testsuite/59808] [4.9 Regression] r206596 caused: FAIL: gcc.target/i386/sse-14.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59808 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Component|target |testsuite --- Comment #1 from Uroš Bizjak ubizjak at gmail dot com --- Somebody forgot to update gcc.target/i386/sse-14.c, in the same way as sse-22.c [1]. [1] http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/testsuite/gcc.target/i386/sse-22.c?limit_changes=0r1=206596r2=206595pathrev=206596
[Bug testsuite/59808] [4.9 Regression] r206596 caused: FAIL: gcc.target/i386/sse-14.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59808 --- Comment #2 from Uroš Bizjak ubizjak at gmail dot com --- Kirill, please update also sse-13.c with new builtins.
[Bug testsuite/59808] [4.9 Regression] r206596 caused: FAIL: gcc.target/i386/sse-14.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59808 --- Comment #3 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Uroš Bizjak from comment #2) Kirill, please update also sse-13.c with new builtins. And sse-12.c with new options.
[Bug middle-end/28865] Structures with a flexible arrray member have wrong .size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28865
--- Comment #25 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
On Mon, 13 Jan 2014, jakub at gcc dot gnu.org wrote:
But the glibc headers case you're mentioning wasn't initializing the flexible
array members, right? (Or even initialization with {} initializer is fine I
I don't have details of exactly what uses of flexible array members they
were making beyond those permitted by ISO C. I guess the general point is
to be careful about disallowing such uses because it might break existing
code (so allowing plenty of time before a release for distribution
rebuilds to catch any problems with such a change, for example).
[Bug fortran/59806] ICE with -ggdb AND -finit-real=snan AND namelist variable AND internal procedure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59806 Harald Anlauf anlauf at gmx dot de changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #1 from Harald Anlauf anlauf at gmx dot de --- Possibly related to or duplicate of PR 59440.
[Bug rtl-optimization/56742] [4.8/4.9 regression] Optimization bug lead to uncaught throw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56742 at2010 g63marty at yahoo dot com changed: What|Removed |Added CC||g63marty at yahoo dot com --- Comment #12 from at2010 g63marty at yahoo dot com --- Created attachment 31834 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31834action=edit save output log and debug window log (at end)
[Bug rtl-optimization/56742] [4.8/4.9 regression] Optimization bug lead to uncaught throw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56742
--- Comment #13 from at2010 g63marty at yahoo dot com ---
Hello.
I also observed the 64bit compile problem while muxing. And after using the new
build the problem is indeed resolved. However I still see a remnant wxwiget
error in the logs that you may wish to fix as well.
Error is
In file
/home/mosu/prog/video/mingw/cross-git-all/tmp-wxwidgets/wxWidgets-3.0.0/src/msw/window.cpp
at line 576: 'SetFocus' failed with error 0x0057 (the parameter is
incorrect.).
This is the pre-fix log. The post-fix log is below.
mkvmerge v6.7.0 ('Back to the Ground') 64bit built on Jan 8 2014 15:10:52
'notrealfilename.avi': Using the demultiplexer for the format 'AVI'.
'notrealfilename.avi' track 0: Using the output module for the format 'MPEG-4'.
'notrealfilename.avi' track 1: Using the output module for the format 'AC3'.
The file 'notrealfilename (1).mkv' has been opened for writing.
Progress: 0%
[Fails with return code 3]
Output of Debug window:
12:34:22: dpi is 96/96
12:34:22: Querying mkvmerge's capabilities
12:34:23: Capability: VERSION=mkvmerge v6.7.0 ('Back to the Ground') 64bit
built on Jan 8 2014 15:10:52
12:34:23: Capability:
12:34:23: Capability: FLAC
12:34:23: Capability:
12:34:23: about to check... btw int? 0
12:34:23: update state changed, now 1
12:34:26: update state changed, now 2
12:34:32: identify 1: command: ``C:\Program Files
(x86)\MKVToolNix\mkvmerge.exe
@C:\Users\notme\AppData\Local\Temp\mmg-mkvmerge-options-3992-1389731672''
12:34:33: identify 1: result: 0
12:34:33: identify 1: output[0]: ``File 'notrealfilename.avi': container: AVI
[is_providing_timecodes:1]''
12:34:33: identify 1: output[1]: ``''
12:34:33: identify 1: output[2]: ``Track ID 0: video (MPEG-4p2)''
12:34:33: identify 1: output[3]: ``''
12:34:33: identify 1: output[4]: ``Track ID 1: audio (AC3/EAC3)''
12:34:33: identify 1: output[5]: ``''
12:36:58: Locale selection logic: select_locale English (English)
uu_locale_lower en translation_c::get_default_ui_locale() en app-m_ui_locale
en
12:37:20: Querying mkvmerge's capabilities
12:37:20: Capability: VERSION=mkvmerge v6.7.0 ('Back to the Ground') 64bit
built on Jan 8 2014 15:10:52
12:37:20: Capability:
12:37:20: Capability: FLAC
12:37:20: Capability:
In file
/home/mosu/prog/video/mingw/cross-git-all/tmp-wxwidgets/wxWidgets-3.0.0/src/msw/window.cpp
at line 576: 'SetFocus' failed with error 0x0057 (the parameter is
incorrect.).
In file
/home/mosu/prog/video/mingw/cross-git-all/tmp-wxwidgets/wxWidgets-3.0.0/src/msw/window.cpp
at line 576: 'SetFocus' failed with error 0x0057 (the parameter is
incorrect.).
In file
/home/mosu/prog/video/mingw/cross-git-all/tmp-wxwidgets/wxWidgets-3.0.0/src/msw/window.cpp
at line 576: 'SetFocus' failed with error 0x0057 (the parameter is
incorrect.).
In file
/home/mosu/prog/video/mingw/cross-git-all/tmp-wxwidgets/wxWidgets-3.0.0/src/msw/window.cpp
at line 576: 'SetFocus' failed with error 0x0057 (the parameter is
incorrect.).
12:57:49: dpi is 96/96
12:57:49: Querying mkvmerge's capabilities
12:57:49: Capability: VERSION=mkvmerge v6.7.0 ('Back to the Ground') 64bit
built on Jan 8 2014 15:10:52
12:57:49: Capability:
12:57:49: Capability: FLAC
12:57:49: Capability:
12:58:00: identify 1: command: ``C:\Program Files
(x86)\MKVToolNix\mkvmerge.exe
@C:\Users\Marty\AppData\Local\Temp\mmg-mkvmerge-options-4540-1389733080''
12:58:01: identify 1: result: 0
12:58:01: identify 1: output[0]: ``File 'notrealfilename.avi': container: AVI
[is_providing_timecodes:1]''
12:58:01: identify 1: output[1]: ``''
12:58:01: identify 1: output[2]: ``Track ID 0: video (MPEG-4p2)''
12:58:01: identify 1: output[3]: ``''
12:58:01: identify 1: output[4]: ``Track ID 1: audio (AC3/EAC3)''
12:58:01: identify 1: output[5]: ``''
In file
/home/mosu/prog/video/mingw/cross-git-all/tmp-wxwidgets/wxWidgets-3.0.0/src/msw/window.cpp
at line 576: 'SetFocus' failed with error 0x0057 (the parameter is
incorrect.).
mkvmerge v6.7.0 ('Back to the Ground') 64bit built on Jan 11 2014 10:17:39
'notrealfilename.avi': Using the demultiplexer for the format 'AVI'.
'notrealfilename.avi' track 0: Using the output module for the format 'MPEG-4'.
'notrealfilename.avi' track 1: Using the output module for the format 'AC3'.
The file 'notrealfilename (2).mkv' has been opened for writing.
Progress: 0%
[omitted lines]
Progress: 100%
The cue entries (the index) are being written...
Muxing took 53 seconds.
Output of Debug window:
13:01:17: dpi is 96/96
13:01:17: Querying mkvmerge's capabilities
13:01:17: Capability: VERSION=mkvmerge v6.7.0 ('Back to the Ground') 64bit
built on Jan 11 2014 10:17:39
13:01:17: Capability:
13:01:17: Capability: FLAC
13:01:17: Capability:
13:01:36: identify 1: command: ``C:\Program Files
(x86)\MKVToolNix\mkvmerge.exe
@C:\Users\notme\AppData\Local\Temp\mmg-mkvmerge-options-4456-1389733296''
13:01:37: identify 1: result: 0
13:01:37: identify 1: output[0]: ``File 'notrealfilename.avi': container: AVI
[Bug c++/59813] New: tail-call elimintation didn't fired with left-shift of char to cout
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59813
Bug ID: 59813
Summary: tail-call elimintation didn't fired with left-shift of
char to cout
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: virkony at gmail dot com
#include iostream
using namespace std;
void foo()
{
cout x endl; // ok
cout 'x' endl; // kills tail-call elimination in gcc 4.8.2
foo();
}
int main() { foo(); return 0; }
// core-dups by long stack while in 4.7.3 works as expected (infinite loop)
[Bug target/59814] New: powerpc64le ICE with -O2 -mpower8 -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59814
Bug ID: 59814
Summary: powerpc64le ICE with -O2 -mpower8 -ffast-math
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at samba dot org
The following test case:
/* -O2 -mcpu=power8 -ffast-math */
float val;
int verbose;
void bar(float x);
void foo(void)
{
if (val 0.0) {
val = 1.0;
if (!verbose)
zot();
bar(val);
}
}
fails with:
# gcc -c -O2 -mcpu=power8 -ffast-math testcase.c
testcase.c: In function ‘foo’:
testcase.c:16:1: error: unrecognizable insn:
}
^
(insn 52 16 3 3 (parallel [
(set (reg:SF 33 1 [orig:125 D.2152 ] [125])
(unspec:SF [
(reg:SF 9 9 [131])
] UNSPEC_P8V_RELOAD_FROM_GPR))
(clobber (reg:DI 8 8))
]) -1
(nil))
testcase.c:16:1: internal compiler error: in extract_insn, at recog.c:2154
[Bug c++/59813] tail-call elimintation didn't fired with left-shift of char to cout
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59813
--- Comment #1 from Nikolay Orliuk virkony at gmail dot com ---
In 4.7.3 that code works, but changing it to
void foo()
{
cout x endl; // ok
cout 'x' endl; // kills tail-call elimination in gcc 4.8.2
struct {} bar; // kills tail-call elimination in 4.7.3
foo();
}
Removing either bar or 'x' results in normal infinite loop.
In 4.5.4 this works fine as is.
[Bug c++/59815] New: Apparently bogus error: 'Outer' is already declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59815
Bug ID: 59815
Summary: Apparently bogus error: 'Outer' is already declared in
this scope
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Google ref: b/12471255
/// --- cut ---
namespace foo
{
template typename class A
{
template typename friend class Outer;
};
class B:foo::A int
{
};
template typename class Outer;
}
using foo::Outer;
/// --- cut ---
Using g++ (GCC) 4.9.0 20140110 (experimental):
g++ -c tt.cc
tt.cc:13:12: error: 'Outer' is already declared in this scope
using foo::Outer;
^
Source is accepted by Clang and is believed to be valid.
[Bug c++/59813] tail-call elimintation didn't fired with left-shift of char to cout
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59813 --- Comment #2 from Nikolay Orliuk virkony at gmail dot com --- My 4.5.4 built without graphite support. Both 4.7.3 and 4.8.2 built with cloog 0.17.0 and isl 0.11.2
[Bug c++/59815] Apparently bogus error: 'Outer' is already declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59815
--- Comment #1 from Paul Pluzhnikov ppluzhnikov at google dot com ---
Slightly more reduced test:
namespace foo
{
template typename class A
{
template typename friend class Outer;
};
Aint a; // comment out - bug goes away.
template typename class Outer;
}
using foo::Outer;
[Bug libfortran/48925] Code cleanup in write_float.def
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48925 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-14 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- For having looked at the code for pr59774, I agree that libgfortran/io/write_float.def badly needs some cleaning in next stage 1.
[Bug libfortran/59774] [Regression] Inconsistent rounding between -m32 and -m64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59774
--- Comment #9 from Dominique d'Humieres dominiq at lps dot ens.fr ---
I have understood the problem in comment 8. It is illustrated by the following
code
print (ru,g45.3), 891.1
print (rd,g45.3), -891.1
end
which gives the output
9.
-9.
with current releases and trunk. The problem comes from the lines
newf.u.real.d = m == 0.0 ? d - 1 : -(mid - d - 1) ;\
and
if (w 0 d == 0 p == 0)
nbefore = 1;
in libgfortran/io/write_float.def when mid==d+1.
I have also noticed the sentence the asm volatile is required for 32-bit x86
platforms which seems to answer my question in comment 6. These remarks led me
to the following patch
--- ../_clean/libgfortran/io/write_float.def2014-01-04 15:51:53.0
+0100
+++ libgfortran/io/write_float.def2014-01-14 22:55:24.0 +0100
@@ -112,7 +112,7 @@ determine_precision (st_parameter_dt * d
static bool
output_float (st_parameter_dt *dtp, const fnode *f, char *buffer, size_t size,
- int nprinted, int precision, int sign_bit, bool zero_flag)
+ int nprinted, int precision, int sign_bit, bool zero_flag, int d_o)
{
char *out;
char *digits;
@@ -373,7 +373,7 @@ output_float (st_parameter_dt *dtp, cons
updown:
rchar = '0';
- if (w 0 d == 0 p == 0)
+ if (w 0 d_o == 0 p == 0)
nbefore = 1;
/* Scan for trailing zeros to see if we really need to round it. */
for(i = nbefore + nafter; i ndigits; i++)
@@ -1018,13 +1018,14 @@ output_float_FMT_G_ ## x (st_parameter_d
int d = f-u.real.d;\
int w = f-u.real.w;\
fnode newf;\
- GFC_REAL_ ## x rexp_d, r = 0.5;\
+ GFC_REAL_ ## x rexp_d, r = 0.5, r_sc;\
int low, high, mid;\
int ubound, lbound;\
char *p, pad = ' ';\
int save_scale_factor, nb = 0;\
bool result;\
int nprinted, precision;\
+ volatile GFC_REAL_ ## x temp;\
\
save_scale_factor = dtp-u.p.scale_factor;\
\
@@ -1043,10 +1044,13 @@ output_float_FMT_G_ ## x (st_parameter_d
break;\
}\
\
- rexp_d = calculate_exp_ ## x (-d);\
- if ((m 0.0 ((m 0.1 - 0.1 * r * rexp_d) || (rexp_d * (m + r) =
1.0)))\
+ rexp_d = calculate_exp_ ## x (d);\
+ r_sc = (1 - r / rexp_d);\
+ temp = 0.1 * r_sc;\
+ if ((m 0.0 ((m temp) || (r = (rexp_d - m\
|| ((m == 0.0) !(compile_options.allow_std\
- (GFC_STD_F2003 | GFC_STD_F2008\
+ (GFC_STD_F2003 | GFC_STD_F2008)))\
+ || d == 0)\
{ \
newf.format = FMT_E;\
newf.u.real.w = w;\
@@ -1066,10 +1070,9 @@ output_float_FMT_G_ ## x (st_parameter_d
\
while (low = high)\
{ \
- volatile GFC_REAL_ ## x temp;\
mid = (low + high) / 2;\
\
- temp = (calculate_exp_ ## x (mid - 1) * (1 - r * rexp_d));\
+ temp = (calculate_exp_ ## x (mid - 1) * r_sc);\
\
if (m temp)\
{ \
@@ -1106,7 +1109,7 @@ output_float_FMT_G_ ## x (st_parameter_d
\
finish:\
result = output_float (dtp, newf, buffer, size, nprinted, precision,\
- sign_bit, zero_flag);\
+ sign_bit, zero_flag, d);\
dtp-u.p.scale_factor = save_scale_factor;\
\
\
@@ -1240,7 +1243,7 @@ determine_en_precision (st_parameter_dt
else\
nprinted = DTOA(y,precision,tmp);\
output_float (dtp, f, buffer, size, nprinted, precision,\
- sign_bit, zero_flag);\
+ sign_bit, zero_flag, f-u.real.d);\
}\
}\
I agree that the additional dummy argument d_o is a kludge, but I did not find
a better way to distinguish between d==0 in the format and mid==d+1. Comments
and improvements welcomed.
Regtested without regression r206590 plus the patch.
[Bug c++/59815] Apparently bogus error: 'Outer' is already declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59815 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- I think this is a duplicate of bug 37804.
[Bug target/58675] ICE in rs6000_secondary_reload_inner:15460, type = store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58675 --- Comment #1 from Peter Bergner bergner at gcc dot gnu.org --- Pat, this doesn't ICE for me anymore. Can we close this?
[Bug fortran/28397] Check format mismatches at compile time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28397 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- See also pr56675.
[Bug fortran/56675] I/O: Check edit descriptors with READ/WRITE used in FORMAT statements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56675 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-14 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Related to pr28397 if not a duplicate.
[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678 --- Comment #30 from Vincent Lefèvre vincent-gcc at vinc17 dot net --- (In reply to Nick Maclaren from comment #29) It is not an explicit definition of BEHAVIOR (my emphasis), The pragma is just a directive. It has no additional behavior, so that there is nothing else to define. Note that the C standard doesn't explicitly say how a source file as a sequence of bytes is to be interpreted as a sequence of character, so that if you just ^ restrict to the C standard, everything is undefined. Yes, it does - it's implementation-defined in 5.1.1.2 Translation phases, paragraph 1.1: Physical source file multibyte characters are mapped, in an Read again. I'm talking of a sequence of bytes. What your quoting is about a sequence of multibyte characters. The interpretation of the sequences of bytes as a sequence of multibyte characters is not defined. You imply that you are also relying on some other standards or specifications. Not other standards, just the implementation.
[Bug libfortran/53962] Tab handling with formatted stream output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53962 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-14 Ever confirmed|0 |1 Known to fail||4.7.4, 4.8.2, 4.9.0 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed at r206590.
[Bug c++/59500] Bogus maybe-unintialized warning due to optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59500 --- Comment #1 from Andy Lutomirski luto at mit dot edu --- This might be a duplicate of PR56574
[Bug target/59814] powerpc64le ICE with -O2 -mpower8 -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59814 Alan Modra amodra at gmail dot com changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #1 from Alan Modra amodra at gmail dot com --- Created attachment 31835 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31835action=edit make rs6000.c match rs6000.md This patch simply avoids the ICE by ensuring we don't generate these insns in the first place. The insns currently have WORDS_BIG_ENDIAN in their predicates.
[Bug c++/59813] tail-call elimintation didn't fired with left-shift of char to cout
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59813 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-15 Ever confirmed|0 |1 Severity|major |normal --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- The early inliner is inlining a function which contains a variable which maybe escapes (address taken) which is causing the tail-call elimination not to happen. There are a few ways of fixing this: 1) Changing the the early inlining heuristics so it will not inline functions where local variables have their address taken. 2) Or have a tail-call optimize pass before early inlining.
[Bug c++/59816] New: [c++11] Incorrect visibility check in template instantiation when the default constructor is a variadic template.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59816
Bug ID: 59816
Summary: [c++11] Incorrect visibility check in template
instantiation when the default constructor is a
variadic template.
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: libremax90 at gmail dot com
The following C++11 code won't compile on GCC 4.8.2 while clang++ will accept
it without a warning. In the following test case, GCC seems to check Base's
default constructor visibility in the test function's context, where the
templates are instantiated.
class Base {
protected:
templateclass... TArgs
Base(TArgs...) {}
// Uncomment to workaround
//Base() {}
};
class Class
: public Base {
public:
templateclass... TArgs
Class(TArgs... args) : Base { args... } {}
// Another workaround:
//Class() {}
};
void test() {
Class{};
}
Here is `g++ -v`'s output:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc/src/gcc-4.8-20131219/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-cloog-backend=isl --disable-cloog-version-check --enable-lto
--enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu
--disable-multilib --disable-werror --enable-checking=release
Thread model: posix
gcc version 4.8.2 20131219 (prerelease) (GCC)
[Bug target/59725] [4.9 Regression] ARM,AArch64 r206148 (PR tree-optimization/59544) caused regressions in pr52943
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59725 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code, patch Status|UNCONFIRMED |NEW URL||http://gcc.gnu.org/ml/gcc-p ||atches/2014-01/msg00805.htm ||l Last reconfirmed||2014-01-15 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Confirmed.
[Bug tree-optimization/59817] New: ICE in extract_affine_chrec with -O2 -ftree-loop-linear
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59817 Bug ID: 59817 Summary: ICE in extract_affine_chrec with -O2 -ftree-loop-linear Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: anton at samba dot org The following testcase: c -O2 -ftree-loop-linear SUBROUTINE PREPD(ICAST,ICAS,ICASX,ICAS1,ICAS2,NDET,NM,III,IMP, * CASMIN) LOGICAL CASMIN DIMENSION ICAST(NDET,NM),IMP(NM) IF(CASMIN) THEN DO K=1,NDET DO L=1,NM IF(L.EQ.K-1) ICAST(K,L) = 1 END DO END DO END IF fails on a powerpc64-linux build from today with: # gfortran -c -O2 -ftree-loop-linear testcase.f testcase.f: In function ‘prepd’: testcase.f:3:0: internal compiler error: in extract_affine_chrec, at graphite-sese-to-poly.c:620 SUBROUTINE PREPD(ICAST,ICAS,ICASX,ICAS1,ICAS2,NDET,NM,III,IMP, ^ 0x10cf684f extract_affine_chrec ../../gcc/gcc/graphite-sese-to-poly.c:619 0x10cf684f extract_affine ../../gcc/gcc/graphite-sese-to-poly.c:803 0x10cf62fb extract_affine ../../gcc/gcc/graphite-sese-to-poly.c:842 0x10cf843f pdr_add_memory_accesses ../../gcc/gcc/graphite-sese-to-poly.c:1486 0x10cf843f build_poly_dr ../../gcc/gcc/graphite-sese-to-poly.c:1583 0x10cf843f build_pbb_drs ../../gcc/gcc/graphite-sese-to-poly.c:1846 0x10cf843f build_scop_drs ../../gcc/gcc/graphite-sese-to-poly.c:1929 0x10cfa8d7 build_poly_scop(scop*) ../../gcc/gcc/graphite-sese-to-poly.c:3171 0x10cdcabb graphite_transform_loops() ../../gcc/gcc/graphite.c:300 0x10cdd227 graphite_transforms ../../gcc/gcc/graphite.c:332 0x10cdd227 execute ../../gcc/gcc/graphite.c:416
[Bug target/59780] ICE in aarch64_split_128bit_move
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59780 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-checking, ||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-15 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- Confirmed.
[Bug target/59799] aarch64_pass_by_reference never passes arrays by value, contrary to ABI documentation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59799 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-15 Ever confirmed|0 |1 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org --- Confirmed.
[Bug c++/59742] compilation failed for package ‘RcppEigen’
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59742 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-01-15 Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- g++: internt kompilatorfel: Dödad (program cc1plus) How much memory do you have installed or even how much swap space do you have? cc1plus is being killed by the kernel due to out of memory.
[Bug c++/59818] New: [4.9 regression] Bogus error: call of overloaded .... is ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59818
Bug ID: 59818
Summary: [4.9 regression] Bogus error: call of overloaded
is ambiguous
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
This is caused by r197790 (fix for PR c++/23055).
Google ref: b/12471166
/// --- cut ---
template class T
struct Identity {
typedef T type;
};
struct Foo {
template typename T
Foo(T*, void (IdentityT::type::*m)(void));
template typename T
Foo(const T*, void (IdentityT::type::*m)(void) const);
};
struct Bar {
void Method(void) const;
};
void Bar::Method(void) const
{
Foo foo(this, Bar::Method);
}
/// --- cut ---
Using g++ (GCC) 4.9.0 20140110 (experimental)
g++ -c t.cc
t.cc: In member function 'void Bar::Method() const':
t.cc:20:29: error: call of overloaded 'Foo(const Bar*, void (Bar::*)() const)'
is ambiguous
Foo foo(this, Bar::Method);
^
t.cc:20:29: note: candidates are:
t.cc:11:3: note: Foo::Foo(const T*, void (IdentityT::type::*)() const) [with
T = Bar; typename IdentityT::type = Bar]
Foo(const T*, void (IdentityT::type::*m)(void) const);
^
t.cc:8:3: note: Foo::Foo(T*, void (IdentityT::type::*)()) [with T = const
Bar; typename IdentityT::type = const Bar]
Foo(T*, void (IdentityT::type::*m)(void));
^
Replacing 'IdentityT::type' with 'T' makes the problem go away.
Source accepted by gcc-4.8 and Clang.
[Bug preprocessor/59782] libcpp does not avoid bug #48326 when compiled by older GCC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59782 --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org --- Isn't it better to disable this code when not optimizing so that stage 1 is never miscompiled?
[Bug c++/23055] overload resolution does not find templated function (zero - pointer)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23055 Paul Pluzhnikov ppluzhnikov at google dot com changed: What|Removed |Added CC||ppluzhnikov at google dot com --- Comment #12 from Paul Pluzhnikov ppluzhnikov at google dot com --- The r197790 appears to have caused PR 59818.
[Bug libfortran/59774] [Regression] Inconsistent rounding between -m32 and -m64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59774 --- Comment #10 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Very interesting and good sleuthing! The way this is suppose to work: For G formatting, we compute the equivalent F or E formatting, as defined in the standard, and pass this new format to output_float which then uses the regular existing formatting processes to do the work. This line: (on or about line 1105 in write_float.def newf.u.real.d = m == 0.0 ? d - 1 : -(mid - d - 1) ;\ is suppose to compute the new 'd' from mid and the given d and pass that into output_float using the newf fnode structure. In the failing case the new 'd' is being set to zero and being passed on. As far as your 'kludge'. I don't think of it that way, but we should see if there is a way to correctly compute the d_o value where you are using it in output_float. There should be a way. Since the standard defines all we do in terms of F and E formatting, I think we are mishandling something there in output_float. You are very close to the solution here. (of course I could be wrong). Someone on the list once said, if it fixes the bug, its probably good enough. The computer has no feelings about correctness of approach.
[Bug c++/59818] [4.9 regression] Bogus error: call of overloaded .... is ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59818 --- Comment #1 from ppluzhnikov at gcc dot gnu.org --- Author: ppluzhnikov Date: Wed Jan 15 05:35:24 2014 New Revision: 206618 URL: http://gcc.gnu.org/viewcvs?rev=206618root=gccview=rev Log: For Google b/12471166 and PR 59818, rollback r206534 (which was a back-port from trunk of r197790). Modified: branches/google/gcc-4_8/gcc/cp/pt.c branches/google/gcc-4_8/gcc/testsuite/g++.dg/template/non-deducible1.C branches/google/gcc-4_8/gcc/testsuite/g++.dg/template/nontype25.C
[Bug c++/59819] New: -Wunused-value reports incorrect values as unused
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59819 Bug ID: 59819 Summary: -Wunused-value reports incorrect values as unused Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: caibbor at gmail dot com Created attachment 31836 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31836action=edit The program in full to replicate this bug This is pretty trivial but the warning outputs incorrect information. given the line: int foo = static_cast int ( 1, 2, 3 ); G++ reports that value 2 and 3 are not used, when in fact 1 and 2 are not used. G++ 4.8.1's output (with -Wall): test.cpp: In function ‘int main()’: test.cpp:15:35: warning: left operand of comma operator has no effect [-Wunused-value] int foo = static_cast int ( 1, 2, 3 ); ^ test.cpp:15:38: warning: right operand of comma operator has no effect [-Wunused-value] int foo = static_cast int ( 1, 2, 3 ); ^ Clang 3.2.7 gets it right, however: test.cpp:15:32: warning: expression result unused [-Wunused-value] int foo = static_cast int ( 1, 2, 3 ); ^ test.cpp:15:35: warning: expression result unused [-Wunused-value] int foo = static_cast int ( 1, 2, 3 ); ^ 2 warnings generated.
[Bug testsuite/59808] [4.9 Regression] r206596 caused: FAIL: gcc.target/i386/sse-14.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59808 --- Comment #4 from Yukhin Kirill kirill.yukhin at intel dot com --- (In reply to Uroš Bizjak from comment #2) Kirill, please update also sse-13.c with new builtins. Fix is posted as part of: http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00761.html I may strip it into separate one...
