[Bug debug/59474] Invalid binaries produced when making win32 EXEs with -gsplit-dwarf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59474 asmwarrior asmwarrior at gmail dot com changed: What|Removed |Added CC||asmwarrior at gmail dot com --- Comment #1 from asmwarrior asmwarrior at gmail dot com --- Same issue with MinGW-Build i686-4.8.2-release-posix-dwarf-rt_v3-rev2
[Bug fortran/60191] test case gfortran.dg/dynamic_dispatch_1/3.f03 fail on ARMv7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60191 Bernd Edlinger bernd.edlinger at hotmail dot de changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Bernd Edlinger bernd.edlinger at hotmail dot de --- fixed.
[Bug rtl-optimization/60763] ICE in extract_insn starting with rev 208984
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60763 --- Comment #1 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org --- I can't reproduce this locally. Do I need any special configure flags apart from -mcpu=power8? It'd be interesting to see the insn that split_insn is splitting. Hopefully that should give an idea which define_split is being used.
[Bug tree-optimization/60766] [4.8/4.9 Regression] Wrong optimization with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60766 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch Known to fail|4.9.0 |4.7.2, 4.8.3 --- Comment #2 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- fails for me with the (old) 4.7, 4.8 branch, works with 4.9. gcc version 4.7.2 20120816 (prerelease) [gcc-4_7-branch revision 190437] (GCC) : fail gcc version 4.8.3 20140315 (prerelease) [gcc-4_8-branch revision 208588] : fail gcc version 4.9.0 20140405 (experimental) [trunk revision 209137] (GCC) : OK
[Bug middle-end/60762] [ASAN] -fsanitize=address fails with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60762 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org --- Hmm, the problem turns out to be more subtle: I compiled the same program on CentOS 6.4 and on openSUSE 13.1. Result: * On CentOS, both binaries fail with the assert (also independent of the use of a linker plugin) * On openSUSE, both binaries work fine. Also copying libasan.so to the other system made no difference. While without -flto, the code runs fine on CentOS 6.4.
[Bug c++/60768] New: Excessive C++ compile time with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60768 Bug ID: 60768 Summary: Excessive C++ compile time with -O3 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 32547 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32547action=edit gzipped C++ source code I just tried to compile the attached code with flag -O3 on trunk dated 20140402 and it couldn't compile in five minutes on an otherwise idle 3.5GHz AMD Phenom. Of the approx 249,000 compilations required to compile a recent Fredora Linux distribution, this one compilation took the longest.
[Bug target/57578] SPE detection broken on Linux (bits/predefs.h: No such file or directory)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57578 Matthias Klose doko at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Matthias Klose doko at gcc dot gnu.org --- works on trunk
[Bug fortran/60751] Extra comma in WRITE statement not diagnosed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60751 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-04-05 Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- My thoughts are that a warning message should be issued, rather than quietly accepting the extension by default. It seems quite trivial to fix, but does it really worth the work?
[Bug c++/60768] Excessive C++ compile time with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60768 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Are you using --enable-checking=release? Might be a dup of pr59802.
[Bug c++/60768] Excessive C++ compile time with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60768 --- Comment #2 from David Binderman dcb314 at hotmail dot com --- (In reply to Markus Trippelsdorf from comment #1) Are you using --enable-checking=release? No, --enable-checking=yes Might be a dup of pr59802. Might be. Similar report from -ftime-report to previous bug report. [dcb@zippy4 foundBugs]$ fgrep -v ( 0%) usr time.out Execution times (seconds) phase opt and generate : 347.98 (100%) usr 0.46 (57%) sys 350.31 (100%) wall 137096 kB (60%) ggc CFG verifier: 3.26 ( 1%) usr 0.00 ( 0%) sys 3.33 ( 1%) wall 0 kB ( 0%) ggc df reaching defs: 5.21 ( 1%) usr 0.02 ( 2%) sys 5.36 ( 2%) wall 0 kB ( 0%) ggc df live regs: 4.65 ( 1%) usr 0.01 ( 1%) sys 4.75 ( 1%) wall 0 kB ( 0%) ggc df liveinitialized regs: 6.31 ( 2%) usr 0.01 ( 1%) sys 6.25 ( 2%) wall 0 kB ( 0%) ggc tree SSA verifier : 1.89 ( 1%) usr 0.00 ( 0%) sys 1.86 ( 1%) wall 0 kB ( 0%) ggc tree STMT verifier : 2.70 ( 1%) usr 0.00 ( 0%) sys 2.85 ( 1%) wall 0 kB ( 0%) ggc loop init : 2.56 ( 1%) usr 0.00 ( 0%) sys 2.60 ( 1%) wall 11945 kB ( 5%) ggc loop unswitching: 285.78 (82%) usr 0.01 ( 1%) sys 287.15 (82%) wall 72 kB ( 0%) ggc CPROP : 5.08 ( 1%) usr 0.09 (11%) sys 5.16 ( 1%) wall 4443 kB ( 2%) ggc PRE : 1.88 ( 1%) usr 0.04 ( 5%) sys 1.92 ( 1%) wall 1389 kB ( 1%) ggc if-conversion : 4.60 ( 1%) usr 0.00 ( 0%) sys 4.74 ( 1%) wall 2588 kB ( 1%) ggc reorder blocks : 1.92 ( 1%) usr 0.00 ( 0%) sys 1.90 ( 1%) wall 7126 kB ( 3%) ggc TOTAL : 348.90 0.81 351.64 227558 kB Extra diagnostic checks enabled; compiler may run slowly. Configure with --enable-checking=release to disable checks. I'll try --enable-checking=release and see if the times are reasonable.
[Bug fortran/60283] Wrong code: decode_omp_directive: implicit_pure not correctly unset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60283 --- Comment #6 from Thomas Schwinge tschwinge at gcc dot gnu.org --- Author: tschwinge Date: Sat Apr 5 10:36:58 2014 New Revision: 209150 URL: http://gcc.gnu.org/viewcvs?rev=209150root=gccview=rev Log: Use gfc_unset_implicit_pure. PR fortran/60283 gcc/fortran/ * parse.c (decode_oacc_directive): Use gfc_unset_implicit_pure. Modified: branches/gomp-4_0-branch/gcc/fortran/ChangeLog.gomp branches/gomp-4_0-branch/gcc/fortran/parse.c
[Bug rtl-optimization/60769] New: [4.8 Regression] ICE: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60769
Bug ID: 60769
Summary: [4.8 Regression] ICE: Max. number of generated reload
insns per insn is achieved (90)
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Hello,
the following seems already fixed in 4.9, but it would be great to backport it
(I don't know which patch) to 4.8. For many bugs, it is often possible to find
a workaround, but for allocation bugs, it is quite mysterious what fragile
changes I have to make to my code to work around it. I tested with debian's
current gcc-4.8, which is essentially r207828 from gcc-4_8-branch.
Compile with g++-4.8 -c -O ouin.ii:
ouin.ii: In function ‘void fn3(N)’:
ouin.ii:38:1: internal compiler error: Max. number of generated reload insns
per insn is achieved (90)
}
^
template class T void fun(T);
struct B {};
struct R {
int *x;
B f;
};
R v(int , R);
void rfun(R );
struct A {
void m_fn2(R p1) {
R a = p1;
rfun(p1);
fun(this);
fun(a);
}
};
struct J {
A ep;
A ap;
int c2a;
void m_fn1(R p2) {
R d, e, b;
v(c2a, p2);
e = v(c2a, b);
ap.m_fn2(e);
v(c2a, p2);
d = v(c2a, b);
ep.m_fn2(d);
}
};
struct N {
int p_;
J cfo;
};
void fn3(Nn) {
R h;
n.cfo.m_fn1(h);
}
extern N c;
void fn1() { fn3(c); }
[Bug rtl-optimization/60769] [4.8 Regression] ICE: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60769 --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org --- Still present with a pure r209150. 0x98bcc9 lra_constraints(bool) /data/repos/gcc/gcc-4_8-branch/gcc/lra-constraints.c:3563 0x97c676 lra(_IO_FILE*) /data/repos/gcc/gcc-4_8-branch/gcc/lra.c:2278 0x937a82 do_reload /data/repos/gcc/gcc-4_8-branch/gcc/ira.c:4667 0x937cd9 rest_of_handle_reload /data/repos/gcc/gcc-4_8-branch/gcc/ira.c:4791
[Bug target/54407] FAIL: 30_threads/condition_variable/54185.cc execution test program timed out on powerpc-apple-darwin9 and x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54407 --- Comment #22 from dominiq at gcc dot gnu.org --- Author: dominiq Date: Sat Apr 5 12:25:37 2014 New Revision: 209152 URL: http://gcc.gnu.org/viewcvs?rev=209152root=gccview=rev Log: 2012-04-06 Dominique d'Humieres domi...@lps.ens.fr Jack Howarth howa...@bromo.med.uc.edu PR target/54407 * 30_threads/condition_variable/54185.cc: Skip for darwin 11. Modified: branches/gcc-4_8-branch/libstdc++-v3/ChangeLog branches/gcc-4_8-branch/libstdc++-v3/testsuite/30_threads/condition_variable/54185.cc
[Bug target/54407] FAIL: 30_threads/condition_variable/54185.cc execution test program timed out on powerpc-apple-darwin9 and x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54407 --- Comment #23 from dominiq at gcc dot gnu.org --- Author: dominiq Date: Sat Apr 5 12:29:27 2014 New Revision: 209153 URL: http://gcc.gnu.org/viewcvs?rev=209153root=gccview=rev Log: 2012-04-05 Dominique d'Humieres domi...@lps.ens.fr Jack Howarth howa...@bromo.med.uc.edu PR target/54407 * 30_threads/condition_variable/54185.cc: Skip for darwin 11. Modified: branches/gcc-4_7-branch/libstdc++-v3/ChangeLog branches/gcc-4_7-branch/libstdc++-v3/testsuite/30_threads/condition_variable/54185.cc
[Bug target/54407] FAIL: 30_threads/condition_variable/54185.cc execution test program timed out on powerpc-apple-darwin9 and x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54407 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #24 from Dominique d'Humieres dominiq at lps dot ens.fr --- Finally fixed.
[Bug libgomp/60035] [PATCH] make it possible to use OMP on both sides of a fork (without violating standard)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60035 larsmans at gmail dot com changed: What|Removed |Added CC||larsmans at gmail dot com --- Comment #4 from larsmans at gmail dot com --- Nathaniel, could you apply the cosmetic changes suggested at http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00860.html? I'd hate to see this patch go to waste.
[Bug libgomp/60035] [PATCH] make it possible to use OMP on both sides of a fork (without violating standard)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60035 Nathaniel J. Smith njs at pobox dot com changed: What|Removed |Added Attachment #32019|0 |1 is obsolete|| --- Comment #5 from Nathaniel J. Smith njs at pobox dot com --- Created attachment 32548 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32548action=edit patch to make openmp - quiesce - fork - openmp work (updated) Updated based on feedback from Richard Henderson
[Bug libgomp/60035] [PATCH] make it possible to use OMP on both sides of a fork (without violating standard)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60035 --- Comment #6 from Nathaniel J. Smith njs at pobox dot com --- (In reply to larsmans from comment #4) Nathaniel, could you apply the cosmetic changes suggested at http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00860.html? I'd hate to see this patch go to waste. If you look at that thread then you'll see I did resend the patch with those fixes -- I've just attached the updated patch to this bug report as well, thanks for the catch. My guess is that no-one will pay much attention to this until gcc re-enters phase 1 in any case.
[Bug libgomp/60035] [PATCH] make it possible to use OMP on both sides of a fork (without violating standard)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60035 --- Comment #7 from larsmans at gmail dot com --- Phase 1? (Not familiar with the GCC dev cycle.)
[Bug libgomp/60035] [PATCH] make it possible to use OMP on both sides of a fork (without violating standard)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60035 --- Comment #8 from Nathaniel J. Smith njs at pobox dot com --- (In reply to larsmans from comment #7) Phase 1? (Not familiar with the GCC dev cycle.) Sorry, meant stage 1. GCC trunk is (IIUC) currently in RC-bug-fixes-only pre-release freeze mode. http://gcc.gnu.org/develop.html
[Bug target/60582] gfortran.dg/fmt_en.f90 FAILs on Solaris 9/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60582 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- From http://gcc.gnu.org/ml/gcc-testresults/2014-04/msg00407.html I assume this PR has been fixed by r209070.
[Bug c++/60767] [ICE] use of using inside template causes failure in retreive_specialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60767 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com --- The code fails also for gcc 4.9.0 trunk
[Bug fortran/60751] Extra comma in WRITE statement not diagnosed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60751 --- Comment #5 from Walter Spector w6ws at earthlink dot net --- It seems quite trivial to fix, but does it really worth the work? Well, we had an instance where this accidentally slipped into our code. Later on, our nightly regression runs crashed with several non-gfortran (and non-Intel) compilers. The extension itself is pretty gratuitous. It adds nothing to the language, yet can quietly promote incompatibilities. Since g95 also accepts it, I am assuming it came into the compiler before the split.
[Bug fortran/60751] Extra comma in WRITE statement not diagnosed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60751 --- Comment #6 from Walter Spector w6ws at earthlink dot net --- Adding that both READ and WRITE have this issue. Interestingly, the iolength version of INQUIRE does not: inquire (iolength=i), i 1 Error: Expected expression in INQUIRE statement at (1)
[Bug fortran/60751] Extra comma in WRITE statement not diagnosed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60751 --- Comment #7 from Harald Anlauf anlauf at gmx dot de --- (In reply to Walter Spector from comment #5) It seems quite trivial to fix, but does it really worth the work? Well, we had an instance where this accidentally slipped into our code. Later on, our nightly regression runs crashed with several non-gfortran (and non-Intel) compilers. If you want diagnostics of standard violations, you might consider adding -std=f2008 (e.g.) to the compile flags in your test suite. Most compilers allow their set of extensions by default. The extension itself is pretty gratuitous. It adds nothing to the language, yet can quietly promote incompatibilities. Since g95 also accepts it, I am assuming it came into the compiler before the split.
[Bug ipa/60761] Names of all function clones in g++ are built-in, in both warnings and dumps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60761 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Martin Jambor from comment #0) mjambor@virgil:~/gcc/bisect/test/clonenames$ ~/gcc/bisect/inst/bin/g++ -O3 -S -Wall zz.C -fno-inline zz.C: In function ‘built-in’: zz.C:14:13: warning: iteration 3u invokes undefined behavior [-Waggressive-loop-optimizations] z[i] = i; ^ What is 3u? zz.C:13:3: note: containing loop Wouldn't be more clear to say within this loop? Isn't this a regression?
[Bug ipa/60761] Names of all function clones in g++ are built-in, in both warnings and dumps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60761
--- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
(In reply to Manuel López-Ibáñez from comment #2)
(In reply to Martin Jambor from comment #0)
mjambor@virgil:~/gcc/bisect/test/clonenames$ ~/gcc/bisect/inst/bin/g++ -O3
-S -Wall zz.C -fno-inline
zz.C: In function ‘built-in’:
zz.C:14:13: warning: iteration 3u invokes undefined behavior
[-Waggressive-loop-optimizations]
z[i] = i;
^
What is 3u?
zz.C:13:3: note: containing loop
Wouldn't be more clear to say within this loop?
I really cannot believe that after all this time, there is no printf-like code
to print a double_int. Why not %I? Interestingly, there is pp_double_int, so it
is obvious to me that this %E trick is just an ugly hack.
Index: tree-ssa-loop-niter.c
===
--- tree-ssa-loop-niter.c (revision 208648)
+++ tree-ssa-loop-niter.c (working copy)
@@ -2626,15 +2626,17 @@ do_warn_aggressive_loop_optimizations (s
edge e = single_exit (loop);
if (e == NULL)
return;
gimple estmt = last_stmt (e-src);
+#pragma GCC diagnostic ignored -Wformat
+#pragma GCC diagnostic ignored -Wformat-extra-args
if (warning_at (gimple_location (stmt), OPT_Waggressive_loop_optimizations,
- iteration %E invokes undefined behavior,
- double_int_to_tree (TREE_TYPE (loop-nb_iterations),
- i_bound)))
-inform (gimple_location (estmt), containing loop);
+ iteration %I invokes undefined behavior,
+ i_bound, TYPE_UNSIGNED (TREE_TYPE (loop-nb_iterations
+inform (gimple_location (estmt), within this loop);
+
loop-warned_aggressive_loop_optimizations = true;
}
/* Records that AT_STMT is executed at most BOUND + 1 times in LOOP. IS_EXIT
is true if the loop is exited immediately after STMT, and this exit
Index: tree-pretty-print.c
===
--- tree-pretty-print.c (revision 208648)
+++ tree-pretty-print.c (working copy)
@@ -3435,32 +3435,8 @@ dump_function_header (FILE *dump_file, t
}
else
fprintf (dump_file, )\n\n);
}
-/* Dump double_int D to pretty_printer PP. UNS is true
- if D is unsigned and false otherwise. */
-void
-pp_double_int (pretty_printer *pp, double_int d, bool uns)
-{
- if (d.fits_shwi ())
-pp_wide_integer (pp, d.low);
- else if (d.fits_uhwi ())
-pp_unsigned_wide_integer (pp, d.low);
- else
-{
- unsigned HOST_WIDE_INT low = d.low;
- HOST_WIDE_INT high = d.high;
- if (!uns d.is_negative ())
- {
- pp_minus (pp);
- high = ~high + !low;
- low = -low;
- }
- /* Would %x%0*x or %x%*0x get zero-padding on all
-systems? */
- sprintf (pp_buffer (pp)-digit_buffer,
- HOST_WIDE_INT_PRINT_DOUBLE_HEX,
- (unsigned HOST_WIDE_INT) high, low);
- pp_string (pp, pp_buffer (pp)-digit_buffer);
-}
-}
+
+
+
Index: pretty-print.c
===
--- pretty-print.c (revision 208648)
+++ pretty-print.c (working copy)
@@ -22,11 +22,12 @@ along with GCC; see the file COPYING3.
#include system.h
#include coretypes.h
#include intl.h
#include pretty-print.h
#include diagnostic-color.h
-
+#include double-int.h
+extern void pp_double_int (pretty_printer *pp, double_int d, bool uns);
#include new// For placement-new.
#if HAVE_ICONV
#include iconv.h
#endif
@@ -261,10 +262,11 @@ pp_indent (pretty_printer *pp)
%': apostrophe (should only be used in untranslated messages;
translations should use appropriate punctuation directly).
%.*s: a substring the length of which is specified by an argument
integer.
%Ns: likewise, but length specified as constant in the format string.
+ %I: double_int
Flag 'q': quote formatted text (must come immediately after '%').
Arguments can be used sequentially, or through %N$ resp. *N$
notation Nth argument after the format string. If %N$ / *N$
notation is used, it must be used for all arguments, except %m, %%,
@@ -605,10 +607,19 @@ pp_format (pretty_printer *pp, text_info
s = va_arg (*text-args_ptr, const char *);
pp_append_text (pp, s, s + n);
}
break;
+
+ case 'I':
+ {
+ double_int i = va_arg (*text-args_ptr, double_int);
+ bool uns = va_arg (*text-args_ptr, int);
+ pp_double_int (pp, i, uns);
+ }
+ break;
+
default:
{
bool ok;
gcc_assert (pp_format_decoder (pp));
@@ -896,10 +907,38 @@ pp_character (pretty_printer *pp, int c)
}
obstack_1grow (pp_buffer (pp)-obstack, c);
++pp_buffer (pp)-line_length;
}
+/* Dump double_int D to pretty_printer PP. UNS is true
+ if D is
[Bug ipa/60665] gcc/ipa-devirt.c:1510:7: warning: variable 'can_refer' is used uninitialized whenever '?:' condition is false
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60665 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-04-05 CC||hubicka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jan Hubicka hubicka at gcc dot gnu.org --- Not really a bug, since can_refer is unused in that case, but I will add initialization to that code path, it would make sense.
[Bug tree-optimization/60770] New: disappearing clobbers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60770
Bug ID: 60770
Summary: disappearing clobbers
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Hello,
looking at Manuel's testcase from PR 60517, I notice that EINLINE changes:
D.2253 = A::getB (a);
to:
D.2264 = a.b;
D.2263 = D.2264;
D.2253 = D.2263;
(several copies, but only the original D.2253 has a clobber)
and ESRA changes:
D.2253 = D.2263;
D.2253 ={v} {CLOBBER};
_5 = MEM[(double *)D.2253];
to:
D.2253 = D.2263;
SR.1_3 = MEM[(struct B *)D.2263];
D.2253 ={v} {CLOBBER};
_5 = SR.1_3;
The clobber then disappears in release_ssa.
It is correct, but not so helpful, because it hides the fact that we are
reading from dead memory. If I disable ESRA, the clobber and the memory read
are still present in the right order in the .optimized dump at -O3.
Would it be possible to keep the memory read after the clobber, without
affecting performance?
class B {
public:
double x[2];
};
class A {
B b;
public:
B getB(void) { return b; }
};
double foo(A a) {
double * x = (a.getB().x[0]);
return x[0];
}
[Bug c++/60517] warning/error for taking address of member of a temporary object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60517 --- Comment #10 from Marc Glisse glisse at gcc dot gnu.org --- Created attachment 32549 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32549action=edit first try With -O -fdisable-tree-esra (see PR 60770), it warns on the testcase. Twice because the DSE pass is run twice. The commented out code was supposed to remove the clobber, but it crashes in unlink_stmt_vdef (probably because I am exiting FOR_EACH_IMM_USE_STMT too violently) so I removed it for now.
[Bug c++/60771] New: rejects-valid: static constexpr const reference initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60771
Bug ID: 60771
Summary: rejects-valid: static constexpr const reference
initialization
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: filip.roseen at gmail dot com
Created attachment 32550
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32550action=edit
testcase.cpp
struct A {
static constexpr int const ref = 5;
};
int main () { }
--
testcase.cpp:2:37: error: non-constant in-class initialization invalid for
static member ‘A::ref’
static constexpr int const ref = 5;
^
testcase.cpp:2:37: error: (an out of class initialization is required)
testcase.cpp:2:37: error: ‘A::ref’ cannot be initialized by a non-constant
expression when being declared
--
The snippet should be accepted, `int const` is a literal-type and `5` sure is
a constant expression suitable for initializing `ref` in the written context.
[ Note: `gcc` correctly accepts `static constexpr int const ref = 5;` if it
appears outside of a class definition. ]
[ Note: `clang` shows the correct behavior. ]
--
[basic.start.init]p2:
Variables with static storage duration (3.7.1) or thread storage
duration (3.7.2) shall be zero-initialized (8.5) before any other
initialization takes place. A constant initializer for an object o is
an expression that is a constant expression, except that it may also
invoke constexpr constructors for o and its subobjects even if those
objects are of non-literal class types [ Note: such a class may have a
non-trivial destructor — end note ].
Constant initialization is performed:
— if each full-expression (including implicit conversions) that
appears in the initializer of a reference with static or
thread storage duration is a constant expression (5.19) and
the reference is bound to an lvalue designating an object
with static storage duration or to a temporary (see 12.2);
/snip
[Bug middle-end/60469] simple cilk plus program ICEs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60469
--- Comment #1 from Andi Kleen andi-gcc at firstfloor dot org ---
I investigated this a bit.
The problem is in get_chain_decl() in the nested function lowering because Cilk
creates nested functions.
info-outer is NULL
created_nesting_tree does this
for (cgn = cgn-nested; cgn ; cgn = cgn-next_nested)
{
struct nesting_info *sub = create_nesting_tree (cgn);
sub-outer = info;
sub-next = info-inner;
info-inner = sub;
}
So it would only set -outer for any inner functions and it is expected to be
NULL on the outer most nesting level
$6 = {outer = 0x0, inner = 0x329b590, next = 0x0, field_map = 0x329c780,
var_map = 0x329dc70, mem_refs = 0x329e850, suppress_expansion = 0x32f8d20,
context = function_decl 0x7fe4297b7e00 main, new_local_var_chain = tree
0x0, debug_var_chain = tree 0x0, frame_type = tree 0x0, frame_decl = tree
0x0,
chain_field = tree 0x0, chain_decl = tree 0x0, nl_goto_field = tree
0x0, any_parm_remapped = false, any_tramp_created = false, static_chain_added
= 0 '\000'}
So this whole code is invoked on the most outer most context, which it cannot
deal with
This seems to be related to the decl_function_context farther up the callstack:
static tree
convert_nonlocal_reference_op (tree *tp, int *walk_subtrees, void *data)
{
struct walk_stmt_info *wi = (struct walk_stmt_info *) data;
struct nesting_info *const info = (struct nesting_info *) wi-info;
tree t = *tp;
*walk_subtrees = 0;
switch (TREE_CODE (t))
{
case VAR_DECL:
/* Non-automatic variables are never processed. */
if (TREE_STATIC (t) || DECL_EXTERNAL (t))
break;
/* FALLTHRU */
case PARM_DECL:
if (decl_function_context (t) != info-context)
(gdb) p t-decl_minimal.context
$11 = tree 0x0
(gdb) p info-context
$12 = function_decl 0x7fe4297b7e00 main
This means the VAR_DECL doesn't have the correct context
Looking at c-common/cilk.c it seems to copy VAR_DECLs.
So it somehow doesn't set up the context correctly?
[Bug fortran/60751] Extra comma in WRITE statement not diagnosed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60751 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #8 from kargl at gcc dot gnu.org --- (In reply to Walter Spector from comment #6) Adding that both READ and WRITE have this issue. Interestingly, the iolength version of INQUIRE does not: inquire (iolength=i), i 1 Error: Expected expression in INQUIRE statement at (1) It a g77 compatibility issue. From the g77 manual (page 190), · The commas in `READ (5), I' and `WRITE (10), J'. These commas are disallowed by FORTRAN 77, but, while strictly superfluous, are syntactically elegant, especially given that commas are required in statements such as `READ 99, I' and `PRINT *, J'. Many compilers permit the superfluous commas for this reason. This is part of GNU Fortran, which I agree a cesspool of vendor extensions. I doubt that this will be changed (too many more important things to work on). If you want strict conformance, it is probably best to add -std=f95 or -std=f2003, or -std=2008 to your command line.
