[Bug tree-optimization/56488] [4.7 Regression] wrong code for loop at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56488
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-03-01
CC||jakub at gcc dot gnu.org
Target Milestone|--- |4.7.3
Summary|wrong code for loop at -O3 |[4.7 Regression] wrong code
||for loop at -O3
Ever Confirmed|0 |1
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-01
07:59:16 UTC ---
Seems to have started with
http://gcc.gnu.org/viewcvs?root=gccview=revrev=181172
and fixed by http://gcc.gnu.org/viewcvs?root=gccview=revrev=190614
Slightly cleaned up testcase:
int a, c, d = 1;
struct S { int s; } b, f;
short e;
void
foo (int x)
{
int g[] = { };
for (e = 0; e != 1; e = e + 5)
{
int *h[1] = { g[0] };
if (!x)
return;
f = b;
}
}
int
main ()
{
int i, j;
for (i = 0; i 6; i++)
for (j = 8; j; j--)
a = 0;
foo (d);
while (c)
;
return 0;
}
[Bug target/56484] [4.8 Regression] ICE in assign_by_spills, at lra-assigns.c:1268
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56484 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-01 CC||jakub at gcc dot gnu.org, ||uros at gcc dot gnu.org Target Milestone|--- |4.8.0 Summary|ICE in assign_by_spills, at |[4.8 Regression] ICE in |lra-assigns.c:1268 |assign_by_spills, at ||lra-assigns.c:1268 Ever Confirmed|0 |1 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-01 08:30:31 UTC --- Started with http://gcc.gnu.org/viewcvs?root=gccview=revrev=188526 but it was merely latent before that, so it isn't LRA bug, because it fails with reload equally. I think the problem is in combine, where we have: ax = call ... flags = r59 != 0 r60 = flags = 0 ? ax : r59 r65 = buf r68 = 768 rep stosd [r65 .. r65 + r68 - 4] = 0 r59 = r60 and the combiner combines the r60 = flags = 0 ? ax : r59 instruction with r59 = r60 into r59 = flags = 0 ? ax : r59 instruction in the last spot, thus extending the lifetime of the ax and flags hard registers across various other instructions.
[Bug target/56484] [4.8 Regression] ICE in assign_by_spills, at lra-assigns.c:1268
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56484 --- Comment #5 from Venkataramanan venkataramanan.kumar at amd dot com 2013-03-01 08:42:42 UTC --- -fno-tree-coalesce-vars for workarround
[Bug fortran/56490] New: [4.6/4.7 Regression] -Wall triggering infinite loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56490 Bug #: 56490 Summary: [4.6/4.7 Regression] -Wall triggering infinite loop Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: o.fle...@science-computing.de Created attachment 29559 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29559 Testcase: Loops forever with -O2 -Wall Compiling testcase, gfortran seems to loop forever. gfortran -c -O -Wall testcase.f leaving out -Wall seems to compile o.k. Have to problem on several independent gcc distros: This one for instance: COLLECT_GCC=/usr/local/gcc-4.6.3/bin/gcc COLLECT_LTO_WRAPPER=/usr/local/gcc-4.6.3/libexec/gcc/x86_64-unknown-linux-gnu/4.6.3/lto-wrapper Ziel: x86_64-unknown-linux-gnu Konfiguriert mit: /soft/os/gcc/gcc-4.6.3/gcc-4.6.3/configure --srcdir=/soft/os/gcc/gcc-4.6.3/gcc-4.6.3 --prefix=/usr/local/gcc-4.6.3 --with-included-gettext --enable-__cxa_atexit --enable-threads --enable-shared --enable-languages=c,c++,fortran --enable-libgcj --enable-ssp --disable-libssp --with-gmp-include=/usr/local/devel/gmp/5.0.1-static/include --with-gmp-lib=/usr/local/devel/gmp/5.0.1-static/lib64 --with-mpfr-include=/usr/local/devel/mpfr/2.4.2-static/include --with-mpfr-lib=/usr/local/devel/mpfr/2.4.2-static/lib64 --with-mpc-include=/usr/local/devel/mpc/0.8.1-static/include --with-mpc-lib=/usr/local/devel/mpc/0.8.1-static/lib64 Thread-Modell: posix gcc-Version 4.6.3 (GCC)
[Bug c++/56489] [C++11] Member type lookup fails on dependent using-declarations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56489 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-01 09:30:17 UTC --- This is already fixed in mainline and isn't a regression.
[Bug c++/55135] [4.8 Regression] Segfault of gcc on a big file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135 --- Comment #14 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-01 09:35:41 UTC --- Thanks Steven for analyzing / fixing this.
[Bug tree-optimization/56488] [4.7 Regression] wrong code for loop at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56488 --- Comment #3 from Marc Glisse glisse at gcc dot gnu.org 2013-03-01 09:53:20 UTC --- Seems to me that 'e' is signed and the testcase relies on wrapping overflow (-fwrapv helps).
[Bug fortran/56491] New: [OOP] Memory leak with vtab's type-bound-procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56491 Bug #: 56491 Summary: [OOP] Memory leak with vtab's type-bound-procedures Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: ja...@gcc.gnu.org gfc_find_derived_vtab (gfc_symbol *derived) ... if (gfc_add_component (vtype, _copy, c) == FAILURE) goto cleanup; c-attr.proc_pointer = 1; c-attr.access = ACCESS_PRIVATE; c-tb = XCNEW (gfc_typebound_proc); The c-tb leaks memory; similarly for gfc_find_intrinsic_vtab. Example: class(*), allocatable :: A allocate(integer :: a) select type(a) type is (integer) a= 5 print *, a end select end Looking at source.c, free_components does not handle TBP. Those are only freed via gfc_free_namespace: free_tb_tree (ns-tb_sym_root); free_tb_tree (ns-tb_uop_root); but vtab's tb do not end up in those symtrees.
[Bug tree-optimization/56488] [4.7 Regression] wrong code for loop at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56488 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-01 09:59:39 UTC --- But e = e + 5 is avaluated as e = (short) ((int) e + 5) and thus I think it just falls down to implementation defined behavior (assuming short is smaller than int of course), because no overflow happens in the int type in which the addition is computed, and there is just cast of a larger int value to smaller short type.
[Bug tree-optimization/56488] [4.7 Regression] wrong code for loop at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56488 --- Comment #5 from Marc Glisse glisse at gcc dot gnu.org 2013-03-01 10:05:53 UTC --- You are right, of course. I remembered that gcc defined unsigned-signed conversion, but I had forgotten that it defined all narrowing conversions as well, sorry.
[Bug tree-optimization/56486] [4.6/4.7 Regression] infinite loop in cc1 at -O1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56486 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-01 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.6.4 Summary|infinite loop in cc1 at -O1 |[4.6/4.7 Regression] |and above |infinite loop in cc1 at -O1 ||and above Ever Confirmed|0 |1 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-01 10:10:09 UTC --- Fixed on trunk by http://gcc.gnu.org/viewcvs?root=gccview=revrev=187053 which made gsi_for_stmt O(1). Random interruption in gdb shows that most time is spent in #0 0x008bddd5 in gsi_next (i=0x7fffdb90) at ../../gcc/gimple.h:4945 #1 0x008bf07a in gsi_for_stmt (stmt=0x71393b00) at ../../gcc/gimple-iterator.c:560 #2 0x00cfe4dc in remove_visited_stmt_chain (var=0x71394e10) at ../../gcc/tree-ssa-reassoc.c:2228 #3 0x00cfeb5b in rewrite_expr_tree (stmt=0x71393c60, opindex=0, ops=0x3505a80, moved=0 '\000') at ../../gcc/tree-ssa-reassoc.c:2383 #4 0x00d02614 in reassociate_bb (bb=0x71580750) at ../../gcc/tree-ssa-reassoc.c:3607 #5 0x00d02691 in reassociate_bb (bb=0x715806e8) at ../../gcc/tree-ssa-reassoc.c:3617 #6 0x00d0277f in do_reassoc () at ../../gcc/tree-ssa-reassoc.c:3650 #7 0x00d02b57 in execute_reassoc () at ../../gcc/tree-ssa-reassoc.c:3742 or similar. Guess for 4.7 and 4.6 perhaps remove_visited_stmt_chain should before trying gsi_for_stmt test whether gsi from previous iteration isn't in the same bb as the stmt we'd call gsi_for_stmt on, and if yes, walk from that gsi backwards manually instead of calling gsi_for_stmt (because, the definitions generally should be before the uses). That would make remove_visited_stmt_chain linear complexity instead of quadratic.
[Bug libstdc++/56475] Incorrect result of configure test for /dev/random (_GLIBCXX_USE_RANDOM_TR1) for MinGW platform (and others?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56475 --- Comment #8 from Kai Tietz ktietz at gcc dot gnu.org 2013-03-01 10:23:28 UTC --- Author: ktietz Date: Fri Mar 1 10:23:21 2013 New Revision: 196371 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196371 Log: PR libstdc++/56475 * acinclude.m4 (GLIBCXX_CHECK_RANDOM_TR1): Disable check for mingw-targets. * configure: Regenerated. Modified: trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/configure
[Bug libstdc++/56475] Incorrect result of configure test for /dev/random (_GLIBCXX_USE_RANDOM_TR1) for MinGW platform (and others?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56475 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #9 from Kai Tietz ktietz at gcc dot gnu.org 2013-03-01 10:27:05 UTC --- Fixed on trunk.
[Bug tree-optimization/56294] BOOT_CFLAGS='-O2 -g -fno-ipa-sra' leads to bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56294 --- Comment #13 from Richard Biener rguenth at gcc dot gnu.org 2013-03-01 10:27:50 UTC --- A guess is that you end up creating SSA names during code transform in different order - which can result from walking a hashtable to do things (which might be in different order when it doesn't have the same number of entries). Note that if you process debug stmts _at all_ (thus end up creating new SSA names because of them) then this will break as well.
[Bug tree-optimization/56294] BOOT_CFLAGS='-O2 -g -fno-ipa-sra' leads to bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56294 --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-01 10:32:34 UTC --- No SSA_NAMEs should be created because of debug stmts. SSA_NAME_VERSION must be identical in between -fvar-tracking-assignments and -fno-var-tracking-assignments, DECL_UIDs might differ, but sorted by DECL_UID the decls must be same if you only consider decls seen with -fno-var-tracking-assignments.
[Bug c++/55135] [4.8 Regression] Segfault of gcc on a big file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Blocks||47344 Target Milestone|--- |4.8.0
[Bug libstdc++/56492] New: std::packaged_task requires CopyConstructible stored task
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56492
Bug #: 56492
Summary: std::packaged_task requires CopyConstructible stored
task
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
This is rejected because std::packaged_task uses std::function internally and
std::function requires a CopyConstructible target object:
#include future
struct S
{
S() = default;
S(S) = default;
void operator()() { }
};
std::packaged_taskvoid () pt{ S{} };
It's not necessary to use std::function, the _Task_state type could hold the
stored task directly, which would allow it to be move constructed.
[Bug c++/55135] [4.8 Regression] Segfault of gcc on a big file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135 --- Comment #15 from Richard Biener rguenth at gcc dot gnu.org 2013-03-01 10:44:10 UTC --- (In reply to comment #10) Created attachment 29557 [details] Collected hacks to make the test case compile in reasonable time with -O0 Patch does 2 things: - Queue up to-be-removed EH regions, instead of removing them one-by-one. Removing them one at a time results in walking the list of EH regions repeatedly, thus taking O(# of EH regions ** 2) time. This (properly cleaned up) looks reasonable to me. - Rewrite init_subregs_of_mode and subroutines to first collect the invalid mode change subregs in sbitmaps, and then converting the final sbitmap to a bitmap. This trades memory for time: the bitmap lookups are also potentially O(# of registers ** 2) and this test case has more than one million registers, many of them with invalid mode changes (to be fixed up by IRA/LRA). Hmm - this is because we hit the O(n) complexity we have on our bitmap implementation? Can't we improve init_subregs_of_mode by first collecting all mode changes we see for a pseudo (eventually using DF info?) and then do the processing in some more optimal order? Trading memory O(number of pseudos) with a large constant factor sounds like something waiting for trouble for other testcases ... Peak memory at -O0 is 4GB. Compile time on a Quad-Core AMD Opteron(tm) Processor 8354 at 2200MHz is 240s, half of it still taken up by IRA+LRA. At -O1 the einline pass is consuming almost all compile time again. - Honza: Can we please have a proper permanent fix for this recurring problem? What's there now just Does Not Work!
[Bug libstdc++/56492] std::packaged_task requires CopyConstructible stored task
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56492 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-03-01 AssignedTo|unassigned at gcc dot |redi at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-01 10:45:01 UTC --- mine
[Bug tree-optimization/56486] [4.6/4.7 Regression] infinite loop in cc1 at -O1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56486 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||compile-time-hog Known to work||4.8.0 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2013-03-01 10:45:45 UTC --- I suppose hangs == just takes very long.
[Bug middle-end/56483] LTO issue with expanding GIMPLE_COND
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56483
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Keywords||lto, missed-optimization
Last reconfirmed||2013-03-01
Component|lto |middle-end
AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-03-01
11:00:18 UTC ---
gimple_cond_single_var_p should be inlined at its single caller, it isn't
any good abstraction.
integer_zerop isn't a good enough test for what the single caller tries to
assert as far as I can see. You'd need to test whether it's precision
is 1 as well (or whether it's BOOLEAN_TYPE).
The IR reader cannot be fixed (the middle-end shouldn't use
frontend boolean_*_node) - frontends have different representation for their
boolean_{true,false,type}_nodes.
Well. Confirmed and mine.
[Bug middle-end/56483] LTO issue with expanding GIMPLE_COND
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56483 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2013-03-01 11:03:24 UTC --- Created attachment 29560 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29560 patch Patch, queued for 4.9.
[Bug c++/55788] inlining failed in call to always_inline: mismatched arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55788 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2013-03-01 11:08:02 UTC --- Yes, looks safe to backport, and indeed a dup. *** This bug has been marked as a duplicate of bug 52888 ***
[Bug middle-end/52888] Unable to inline function pointer call with inexact signature match
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52888 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||geza at bitquad dot com --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2013-03-01 11:08:02 UTC --- *** Bug 55788 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/56424] [4.8 Regression] ICE at tree-inline.c:2833 on a-nllcef.ads at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56424 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Component|bootstrap |tree-optimization --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-01 11:14:51 UTC --- Recategorizing.
[Bug ada/56474] [4.8 regression] bogus Storage_Error raised for record containing empty zero-based array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56474 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2013-03-01 11:26:59 UTC --- Probably caused by my sizetype changes. For frontends that support arbitrary array domains the only good reliable way out is to support and use both signed and unsigned TYPE_DOMAINs.
[Bug tree-optimization/49234] [4.5/4.6/4.7/4.8 Regression] -Wstrict-overflow gives obviously unwarranted warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49234
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||iant at google dot com
--- Comment #10 from Richard Biener rguenth at gcc dot gnu.org 2013-03-01
11:45:54 UTC ---
(In reply to comment #9)
(In reply to comment #3)
We hit:
163724rguenth /* Similarly, if the new maximum is smaller or
larger
than
163724rguenththe previous one, go all the way to +INF. */
163724rguenth if (cmp_max 0 || cmp_max 0)
163724rguenth {
163724rguenth if (!needs_overflow_infinity (TREE_TYPE
(vr_result.max))
163724rguenth || !vrp_var_may_overflow (lhs, phi))
163724rguenth vr_result.max = TYPE_MAX_VALUE (TREE_TYPE
(vr_result.max));
163724rguenth else if (supports_overflow_infinity (TREE_TYPE
(vr_result.max)))
163724rguenth vr_result.max =
163724rguenth positive_overflow_infinity (TREE_TYPE
(vr_result.max));
163724rguenth }
(In reply to comment #8)
Does this seem like an approach worth exploring (this silences the
warning), or
does anyone have a better suggestion?
Isn't the problem that vrp_var_may_overflow returns true even though 'state'
cannot overflow? Jakub says:
As the IV (i) might overflow, vrp_var_may_overflow returns true.
In particular, chrec is SCEV_NOT_KNOWN. Thus it just in case sets
vr_result.max to +INF(OVF) and later on we warn about it.
Before hitting this code, vr_result contains the right range [0, 2], but it
doesn't know it can safely use that.
Couldn't be possible to detect this by the fact that 'state' does not depend
on
anything variable?
Also, in such a case, the algorithm cannot iterate more than the number of phi
nodes in the loop (if I understand the VRP correctly, which I most likely
don't).
But I looked around and I honestly don't know how to implement this idea.
In any case, your patch would need to adjust the code for the minimum also,
no?
Because the same behaviour can be triggered just by using negative numbers to
trigger a negative overflow infinity.
I think we should simply not set overflow on this code path in any case. We
have (OVF) just for the sake of -Wstrict-overflow warnings which in VRP are
implemeted in the worst possible way.
The issue with iterating is that you either can re-create the issue
with a different testcase or you blow up compile-time.
When somebody wants to improve VRP for SSA cycles then the way to go is
to compute the SSA SCC, classify it (in this case we only have assigns
from constants, not increments or decrements) and choose a solving
strathegy.
Oh, and of course strict-overflow warnings are all Ians fault ;)
[Bug tree-optimization/56488] [4.7 Regression] wrong code for loop at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56488 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code CC||rguenth at gcc dot gnu.org --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org 2013-03-01 12:20:21 UTC --- The fixing rev. doesn't make much sense ;) The issue must be still latent. But e = e + 5 is avaluated as e = (short) ((int) e + 5) not true before VRP2: short int e.2; short int e.4; ... bb 3: # e.2_4 = PHI e.4_18(3), 0(2) f = b; D.1777_45 = e.2_4 + 5; e.4_18 = D.1777_45; e = e.4_18; if (e.4_18 != 1) goto bb 3; else goto bb 4; which turns it into an endless loop. The FE shortened to e = (short int) ((short unsigned int) e + 5); but IVOPTs makes it short. There was a related bugfix by Zdenek for 4.8.
[Bug tree-optimization/56488] [4.7 Regression] wrong code for loop at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56488 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org 2013-03-01 12:23:57 UTC --- PR55481, backporting that fixes it. *** This bug has been marked as a duplicate of bug 55481 ***
[Bug middle-end/55481] [4.8 regression] -O2 generates a wrong-code infinite loop in C++Benchmark's simple_types_constant_folding int8 xor test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55481 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||dhazeghi at yahoo dot com --- Comment #19 from Richard Biener rguenth at gcc dot gnu.org 2013-03-01 12:23:57 UTC --- *** Bug 56488 has been marked as a duplicate of this bug. ***
[Bug middle-end/55481] [4.8 regression] -O2 generates a wrong-code infinite loop in C++Benchmark's simple_types_constant_folding int8 xor test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55481 --- Comment #20 from Richard Biener rguenth at gcc dot gnu.org 2013-03-01 12:29:46 UTC --- Author: rguenth Date: Fri Mar 1 12:29:39 2013 New Revision: 196377 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196377 Log: 2013-03-01 Richard Biener rguent...@suse.de PR tree-optimization/55481 * gcc.dg/torture/pr56488.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr56488.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug middle-end/52888] Unable to inline function pointer call with inexact signature match
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52888 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org 2013-03-01 12:46:17 UTC --- Author: rguenth Date: Fri Mar 1 12:46:12 2013 New Revision: 196378 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196378 Log: 2013-03-01 Richard Biener rguent...@suse.de Backport from mainline 2012-04-10 Richard Guenther rguent...@suse.de PR middle-end/52888 * gimple-low.c (gimple_check_call_args): Properly account for compatible aggregate types. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/gimple-low.c
[Bug middle-end/52888] Unable to inline function pointer call with inexact signature match
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52888 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.7.3, 4.8.0 Target Milestone|4.8.0 |4.7.3 Known to fail||4.7.2 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org 2013-03-01 13:09:58 UTC --- Fixed for 4.7.3, too.
[Bug c++/56493] New: Performance regression in google dense hashmap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56493 Bug #: 56493 Summary: Performance regression in google dense hashmap Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: andrew...@gmail.com When compared to gcc-4.6.2, gcc-4.7.1 shows about a 10-20% performance regression when inserting into a google dense hashmap in a tight loop. A small sample program is attached and was compiled with '-O3' and on a linux x86_64 box (using -std=gnu++0x, as required by sparsehash). Potentially related, the generated binary under gcc-4.7 is also over 50% bigger.
[Bug c++/56493] Performance regression in google dense hashmap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56493 --- Comment #1 from Andrew Gallagher andrewjcg at gmail dot com 2013-03-01 13:11:30 UTC --- Created attachment 29561 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29561 Sample program using dense hashmap
[Bug c++/56493] Performance regression in google dense hashmap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56493 --- Comment #2 from Andrew Gallagher andrewjcg at gmail dot com 2013-03-01 13:12:41 UTC --- I also see this same perf regression on trunk (as of r195725).
[Bug libstdc++/56475] Incorrect result of configure test for /dev/random (_GLIBCXX_USE_RANDOM_TR1) for MinGW platform (and others?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56475 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug libstdc++/56475] Incorrect result of configure test for /dev/random (_GLIBCXX_USE_RANDOM_TR1) for MinGW platform (and others?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56475 --- Comment #10 from Karlson2k k2k at narod dot ru 2013-03-01 13:29:40 UTC --- Could you fix 4.7 branch too?
[Bug middle-end/55481] [4.8 regression] -O2 generates a wrong-code infinite loop in C++Benchmark's simple_types_constant_folding int8 xor test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55481 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.8.0 |4.7.3 --- Comment #21 from Richard Biener rguenth at gcc dot gnu.org 2013-03-01 13:55:15 UTC --- Fixed for 4.7.3 as well.
[Bug middle-end/55481] [4.8 regression] -O2 generates a wrong-code infinite loop in C++Benchmark's simple_types_constant_folding int8 xor test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55481 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.8.0 |4.7.3 --- Comment #21 from Richard Biener rguenth at gcc dot gnu.org 2013-03-01 13:55:15 UTC --- Fixed for 4.7.3 as well. --- Comment #22 from Richard Biener rguenth at gcc dot gnu.org 2013-03-01 13:55:19 UTC --- Author: rguenth Date: Fri Mar 1 13:55:11 2013 New Revision: 196379 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196379 Log: 2013-03-01 Richard Biener rguent...@suse.de Backport from mainline 2012-12-12 Zdenek Dvorak o...@ucw.cz PR tree-optimization/55481 * tree-ssa-loop-ivopts.c (rewrite_use_nonlinear_expr): Fall back to general rewriting if we cannot leave an original biv definition alone. * gcc.dg/torture/pr55481.c: New testcase. * gcc.dg/torture/pr56488.c: Likewise. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr55481.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr56488.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/tree-ssa-loop-ivopts.c
[Bug tree-optimization/56494] New: ICE in simplify_truncation, at simplify-rtx.c:619
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56494
Bug #: 56494
Summary: ICE in simplify_truncation, at simplify-rtx.c:619
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: antoine.balest...@gmail.com
With GCC 4.8.0 as of 20130301 :
$ cat trunc.c
char a;
short b;
void f(void)
{
g((!!b ? : (a *= a / 0)) = (a = b));
}
$ xgcc -w -O2 -ftracer trunc.c
trunc.c: In function ‘f’:
trunc.c:7:1: internal compiler error: in simplify_truncation, at
simplify-rtx.c:619
}
^
0x8db526 simplify_truncation
../../srcdir/gcc/simplify-rtx.c:619
0x8dc6fa simplify_unary_operation_1
../../srcdir/gcc/simplify-rtx.c:1046
0x8dc6fa simplify_unary_operation(rtx_code, machine_mode, rtx_def*,
machine_mode)
../../srcdir/gcc/simplify-rtx.c:786
0x8de2ef simplify_gen_unary(rtx_code, machine_mode, rtx_def*, machine_mode)
../../srcdir/gcc/simplify-rtx.c:369
0x8dc6fa simplify_unary_operation_1
../../srcdir/gcc/simplify-rtx.c:1046
0x8dc6fa simplify_unary_operation(rtx_code, machine_mode, rtx_def*,
machine_mode)
../../srcdir/gcc/simplify-rtx.c:786
0x8de2ef simplify_gen_unary(rtx_code, machine_mode, rtx_def*, machine_mode)
../../srcdir/gcc/simplify-rtx.c:369
0x8db057 simplify_truncation
../../srcdir/gcc/simplify-rtx.c:648
0x8dbc2d simplify_gen_subreg(machine_mode, rtx_def*, machine_mode, unsigned
int)
../../srcdir/gcc/simplify-rtx.c:5942
0xce9dce gen_lowpart_for_combine
../../srcdir/gcc/combine.c:10732
0xcef08e expand_compound_operation
../../srcdir/gcc/combine.c:6808
0xcf481f simplify_comparison
../../srcdir/gcc/combine.c:11168
0xcf754e combine_simplify_rtx
../../srcdir/gcc/combine.c:5665
0xcf972a subst
../../srcdir/gcc/combine.c:5155
0xcf93da subst
../../srcdir/gcc/combine.c:5100
0xcfa92f try_combine
../../srcdir/gcc/combine.c:3146
0xcff76c combine_instructions
../../srcdir/gcc/combine.c:1368
0xcff76c rest_of_handle_combine
../../srcdir/gcc/combine.c:13793
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug ada/56474] [4.8 regression] bogus Storage_Error raised for record containing empty zero-based array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56474
--- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-01
14:25:56 UTC ---
This happens because 0 - 1 overflows in sizetype:
#6 0x00ac3e3d in size_binop_loc (loc=0, code=MINUS_EXPR,
arg0=0x76d65d60, arg1=0x76d65f00)
at /home/eric/svn/gcc/gcc/fold-const.c:1417
1417 return int_const_binop_1 (code, arg0, arg1, -1);
(gdb) p debug_tree(arg0)
integer_cst 0x76d65d60 type integer_type 0x76d710a8 sizetype
constant visited 0
$28 = void
(gdb) p debug_tree(arg1)
integer_cst 0x76d65f00 type integer_type 0x76d710a8 sizetype
constant visited 1
$29 = void
(gdb) frame 4
#4 0x00f28804 in force_fit_type_double (type=0x76d710a8, cst=...,
overflowable=-1, overflowed=false) at /home/eric/svn/gcc/gcc/tree.c:1109
1109 tree t = make_node (INTEGER_CST);
(gdb) p cst
$30 = {low = 18446744073709551615, high = -1}
Now it didn't overflow on the 4.7 branch:
Breakpoint 2, int_const_binop (code=MINUS_EXPR, arg1=0x76d66f00,
arg2=0x76d790a0) at /home/eric/svn/gcc-4_7-branch/gcc/fold-const.c:1085
1085 return t;
(gdb) p debug_tree(arg1)
integer_cst 0x76d66f00 type integer_type 0x76d77000 sizetype
constant visited 0
$4 = void
(gdb) p debug_tree(arg2)
integer_cst 0x76d790a0 type integer_type 0x76d77000 sizetype
constant visited 1
$5 = void
(gdb) p debug_tree(t)
integer_cst 0x76d66f20 type integer_type 0x76d77000 sizetype
constant visited -1
This low_bound - 1 idiom is pervasive in Ada and it will probably overflow only
for 0 so we could add a kludge to size_binop_loc, similarly to the kludge that
exists in layout_type:
Index: fold-const.c
===
--- fold-const.c(revision 196253)
+++ fold-const.c(working copy)
@@ -1389,9 +1389,13 @@ size_binop_loc (location_t loc, enum tre
gcc_assert (int_binop_types_match_p (code, TREE_TYPE (arg0),
TREE_TYPE (arg1)));
- /* Handle the special case of two integer constants faster. */
+ /* Handle general case of two integer constants. For sizetype constant
+ calculations, we always want to know about overflow, even in the
+ unsigned case. */
if (TREE_CODE (arg0) == INTEGER_CST TREE_CODE (arg1) == INTEGER_CST)
{
+ int overflowable = -1;
+
/* And some specific cases even faster than that. */
if (code == PLUS_EXPR)
{
@@ -1404,6 +1408,11 @@ size_binop_loc (location_t loc, enum tre
{
if (integer_zerop (arg1) !TREE_OVERFLOW (arg1))
return arg0;
+
+ /* ??? We make an exception for 0 - 1 because it's an idiom
+used in length calculations for zero-based arrays. */
+ if (integer_zerop (arg0) integer_onep (arg1))
+ overflowable = 1;
}
else if (code == MULT_EXPR)
{
@@ -1411,10 +1420,7 @@ size_binop_loc (location_t loc, enum tre
return arg1;
}
- /* Handle general case of two integer constants. For sizetype
- constant calculations we always want to know about overflow,
-even in the unsigned case. */
- return int_const_binop_1 (code, arg0, arg1, -1);
+ return int_const_binop_1 (code, arg0, arg1, overflowable);
}
return fold_build2_loc (loc, code, type, arg0, arg1);
What do you think Richard?
[Bug c++/56493] Performance regression in google dense hashmap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56493 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-03-01 Ever Confirmed|0 |1 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-01 14:29:24 UTC --- Instead of expecting everyone who looks at this bug to find and download the dense hash map code please provide preprocessed source as requested in the bug reporting guidelines that you were prominently asked to read before you entered this bug report: http://gcc.gnu.org/bugs/
[Bug middle-end/56474] [4.8 regression] bogus Storage_Error raised for record containing empty zero-based array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56474 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Component|ada |middle-end --- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-01 14:32:50 UTC --- Recategorizing.
[Bug c++/55135] [4.8 Regression] Segfault of gcc on a big file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135 --- Comment #16 from Steven Bosscher steven at gcc dot gnu.org 2013-03-01 14:35:20 UTC --- (In reply to comment #15) - Queue up to-be-removed EH regions, instead of removing them one-by-one. Removing them one at a time results in walking the list of EH regions repeatedly, thus taking O(# of EH regions ** 2) time. This (properly cleaned up) looks reasonable to me. It's not yet complete, I think I need to update the outer region pointers for the inner region if an outer region is removed. But I think this is the right approach. - Rewrite init_subregs_of_mode and subroutines to first collect the invalid mode change subregs in sbitmaps, and then converting the final sbitmap to a bitmap. This trades memory for time: the bitmap lookups are also potentially O(# of registers ** 2) and this test case has more than one million registers, many of them with invalid mode changes (to be fixed up by IRA/LRA). Hmm - this is because we hit the O(n) complexity we have on our bitmap implementation? Yes. Can't we improve init_subregs_of_mode by first collecting all mode changes we see for a pseudo (eventually using DF info?) and then do the processing in some more optimal order? Yes. That is the plan, this was just a proof-of-concept fix (I didn't call it a patch, I called it a hack - for the good reasons you mentioned :-). I also want to add a better way to lookup bits as random-access in bitmaps: change the view of the bitmap, much like what tree-ssa-live does with its maps).
[Bug lto/56495] New: ICE in lto_output_tree with -g -flto -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56495 Bug #: 56495 Summary: ICE in lto_output_tree with -g -flto -O2 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: spammeup2...@googlemail.com GCC segfaults while compiling the attached code from Parma Polyhedra Library. The testcase is huge, but reducing it led to a testcase that only failed in 1 of 10 cases or so. The error message sometimes changed to tree code '(some garbage)' is not supported in LTO streams but i could not reproduce that one. GCC 4.8.0 20130301 fails while GCC 4.7.2 works. Compiler output: gcc -O2 -flto -g -s ppl.ii ppl_c_Rational_Box.cc: In function 'Parma_Polyhedra_Library::operator(Parma_Polyhedra_Library::Linear_Expression const, __gmp_expr__mpz_struct [1], __mpz_struct [1] const)': ppl_c_Rational_Box.cc:1781:8302: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://bugs.gentoo.org/ for instructions. Backtrace: Program received signal SIGSEGV, Segmentation fault. lto_output_tree (ob=0x1ece9d0, expr=0xe0049, ref_p=true, this_ref_p=true) at ../.././gcc/lto-streamer-out.c:371 371../.././gcc/lto-streamer-out.c: No such file or directory. (gdb) bt #0 lto_output_tree (ob=0x1ece9d0, expr=0xe0049, ref_p=true, this_ref_p=true) at ../.././gcc/lto-streamer-out.c:371 #1 0x009ed78b in write_ts_block_tree_pointers (ref_p=true, expr=0x7491ca80, ob=0x1ece9d0) at ../.././gcc/tree-streamer-out.c:760 #2 streamer_write_tree_body (ob=0x1ece9d0, expr=0x7491ca80, ref_p=optimized out) at ../.././gcc/tree-streamer-out.c:887 #3 0x008194fd in lto_write_tree (ref_p=true, expr=0x7491ca80, ob=0x1ece9d0) at ../.././gcc/lto-streamer-out.c:321 #4 lto_output_tree (ob=0x1ece9d0, expr=0x7491ca80, ref_p=optimized out, this_ref_p=optimized out) at ../.././gcc/lto-streamer-out.c:410 #5 0x009ed176 in write_ts_common_tree_pointers (ref_p=true, expr=0x7fffe85aa0f0, ob=0x1ece9d0) at ../.././gcc/tree-streamer-out.c:514 #6 streamer_write_tree_body (ob=0x1ece9d0, expr=0x7fffe85aa0f0, ref_p=optimized out) at ../.././gcc/tree-streamer-out.c:845 #7 0x008194fd in lto_write_tree (ref_p=true, expr=0x7fffe85aa0f0, ob=0x1ece9d0) at ../.././gcc/lto-streamer-out.c:321 #8 lto_output_tree (ob=ob@entry=0x1ece9d0, expr=0x7fffe85aa0f0, ref_p=ref_p@entry=true, this_ref_p=this_ref_p@entry=true) at ../.././gcc/lto-streamer-out.c:410 #9 0x009ed82b in write_ts_exp_tree_pointers (ref_p=optimized out, expr=optimized out, ob=optimized out) at ../.././gcc/tree-streamer-out.c:747 #10 streamer_write_tree_body (ob=0x1ece9d0, expr=0x7fffe858d880, ---Type return to continue, or q return to quit--- ref_p=optimized out) at ../.././gcc/tree-streamer-out.c:884 #11 0x008194fd in lto_write_tree (ref_p=true, expr=0x7fffe858d880, ob=0x1ece9d0) at ../.././gcc/lto-streamer-out.c:321 #12 lto_output_tree (ob=0x1ece9d0, expr=0x7fffe858d880, ref_p=optimized out, this_ref_p=optimized out) at ../.././gcc/lto-streamer-out.c:410 #13 0x009ed7f5 in write_ts_exp_tree_pointers (ref_p=optimized out, expr=optimized out, ob=optimized out) at ../.././gcc/tree-streamer-out.c:746 #14 streamer_write_tree_body (ob=0x1ece9d0, expr=0x7fffe85a39d8, ref_p=optimized out) at ../.././gcc/tree-streamer-out.c:884 #15 0x008194fd in lto_write_tree (ref_p=true, expr=0x7fffe85a39d8, ob=0x1ece9d0) at ../.././gcc/lto-streamer-out.c:321 #16 lto_output_tree (ob=0x1ece9d0, expr=0x7fffe85a39d8, ref_p=optimized out, this_ref_p=optimized out) at ../.././gcc/lto-streamer-out.c:410 #17 0x009ed7f5 in write_ts_exp_tree_pointers (ref_p=optimized out, expr=optimized out, ob=optimized out) at ../.././gcc/tree-streamer-out.c:746 #18 streamer_write_tree_body (ob=0x1ece9d0, expr=0x7fffe859a300, ref_p=optimized out) at ../.././gcc/tree-streamer-out.c:884 #19 0x008194fd in lto_write_tree (ref_p=true, expr=0x7fffe859a300, ob=0x1ece9d0) at ../.././gcc/lto-streamer-out.c:321 #20 lto_output_tree (ob=ob@entry=0x1ece9d0, expr=0x7fffe859a300, ref_p=ref_p@entry=true, this_ref_p=this_ref_p@entry=true) ---Type return to continue, or q return to quit--- at ../.././gcc/lto-streamer-out.c:410 #21 0x009ed936 in write_ts_decl_common_tree_pointers (ref_p=true, expr=0x7fffe85ac5f0, ob=0x1ece9d0) at ../.././gcc/tree-streamer-out.c:584 #22 streamer_write_tree_body (ob=0x1ece9d0, expr=0x7fffe85ac5f0, ref_p=optimized out) at ../.././gcc/tree-streamer-out.c:857 #23 0x008194fd in lto_write_tree (ref_p=true, expr
[Bug lto/56495] ICE in lto_output_tree with -g -flto -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56495 --- Comment #1 from Florian Meyer spammeup2011 at googlemail dot com 2013-03-01 14:47:03 UTC --- Created attachment 29562 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29562 Zipped Preprocessed source Preprocessed source in zipped form. The file is 3mb unpacked.
[Bug tree-optimization/49234] [4.5/4.6/4.7/4.8 Regression] -Wstrict-overflow gives obviously unwarranted warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49234 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added CC||ian at airs dot com --- Comment #11 from Ian Lance Taylor ian at airs dot com 2013-03-01 14:52:53 UTC --- I suspect we can handle this case by observing that all the incoming values to the PHI node are constants. It's true that strict overflow warnings are my fault but I believe it was a necessary move to keep people from turning on -fwrapv.
[Bug fortran/56496] New: [OOP] ICE with TYPE(*) coarray and SELECT TYPE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56496 Bug #: 56496 Summary: [OOP] ICE with TYPE(*) coarray and SELECT TYPE Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: pa...@gcc.gnu.org The following program gives an ICE: $ gfortran -fcoarray=single test.f90 test.f90: In Funktion »MAIN__«: test.f90:5:0: interner Compiler-Fehler: Speicherzugriffsfehler a= 5 ^ 0x99dc9f crash_signal ../../gcc/toplev.c:332 0x5fde88 tree_class_check ../../gcc/tree.h:3801 0x5fde88 gfc_conv_array_data(tree_node*) ../../gcc/fortran/trans-array.c:2662 class(*), allocatable :: A[:] allocate(integer :: a[*]) select type(a) type is (integer) a= 5 print *, a end select end
[Bug c++/56497] New: comparison is always true due to limited range of data type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56497 Bug #: 56497 Summary: comparison is always true due to limited range of data type Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: mathieu.malate...@gmail.com Created attachment 29563 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29563 g++ -Wtype-limits test.cxx It would be really nice if -Wtype-limits would catch all occurences in the following test case. Steps: $ g++ -Wtype-limits test.cxx test.cxx: In function 'int main()': test.cxx:25:33: warning: comparison is always true due to limited range of data type [-Wtype-limits]
[Bug c++/55135] [4.8 Regression] Segfault of gcc on a big file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135 --- Comment #17 from Jan Hubicka hubicka at ucw dot cz 2013-03-01 16:14:08 UTC --- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135 --- Comment #12 from Steven Bosscher steven at gcc dot gnu.org 2013-03-01 07:50:43 UTC --- Last night's compilation at -O1 with my hacks applied finished after a whopping 6 hours. Top compile time consumers: early inlining heuristics: 12409.92 (55%) usr integration : 1417.65 ( 6%) usr tree eh : 1140.75 ( 5%) usr tree PTA : 309.46 ( 1%) usr tree SSA incremental : 6065.43 (27%) usr tree split crit edges: 515.67 ( 2%) usr TOTAL: 22448.04 Peak memory: 4294647808 (~4GB). I will take care of the early inlining problem. I wonder, you don't have oprofile of that, by any chance? Honza
[Bug c++/55135] [4.8 Regression] Segfault of gcc on a big file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135 --- Comment #18 from Jan Hubicka hubicka at ucw dot cz 2013-03-01 16:19:47 UTC --- I will take care of the early inlining problem. I wonder, you don't have oprofile of that, by any chance? Aha, callee walking in update_inline_summary. Perhaps I will really need to make this incremental despite the risk of accmulating roundoff errors.. I will play with this a bit more. Honza
[Bug c++/56312] Firefox 20.0a1 compilation with enabled LTO fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56312 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-03-01 CC||hubicka at gcc dot gnu.org AssignedTo|unassigned at gcc dot |hubicka at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org 2013-03-01 16:31:15 UTC --- Can you please run it in debugger and let me know where precisely it segfaults in can_refer_decl_in_current_unit_p? I will try to update my tree and see if it reproduces. Honza
[Bug target/47333] [4.6/4.8 regression] g++.dg/lto/20091219 FAILs on Solaris 2 with SUN as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47333 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #32 from Jan Hubicka hubicka at gcc dot gnu.org 2013-03-01 16:31:29 UTC --- mine.
[Bug fortran/56491] [OOP] Memory leak with vtab's type-bound-procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56491 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2013-03-01 16:45:01 UTC --- The VTAB issue is now fixed: http://gcc.gnu.org/ml/gcc-cvs/2013-03/msg00024.html However, another issue is still pending: 864 (192 direct, 672 indirect) bytes in 1 blocks are definitely lost in loss record 325 of 355 at 0x4C2A0B4: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) by 0xED30B0: xcalloc (xmalloc.c:162) by 0x571BBF: gfc_get_expr() (expr.c:47) by 0x57442B: gfc_get_variable_expr(gfc_symtree*) (expr.c:3936) by 0x5D06E2: resolve_code(gfc_code*, gfc_namespace*) (resolve.c:8536) by 0x5D1CEE: resolve_codes(gfc_namespace*) (resolve.c:14972) That's the following expression in resolve.c: st-n.sym-assoc-target = gfc_get_variable_expr (code-expr1-symtree);
[Bug c++/56498] New: invalid declaration of string iterator on comma separated list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56498
Bug #: 56498
Summary: invalid declaration of string iterator on comma
separated list
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hgkam...@hotmail.com
Trying to declare and initialize two iterators in a comma separated list
results in an invalid declaration error.
workaround, declare the iterator before the for statement.
a.cpp: In function ‘bool ispalindrome(std::string)’:
a.cpp:7:37: error: invalid declaration of
‘std::basic_stringchar::reverse_iterator’
a.cpp:7:62: error: expected ‘;’ before ‘i2’
a.cpp:7:62: error: ‘i2’ was not declared in this scope
a.cpp:7:89: error: expected ‘)’ before ‘;’ token
a.cpp:7:92: error: ‘i1’ was not declared in this scope
a.cpp:7:98: error: ‘i2’ was not declared in this scope
a.cpp:7:102: error: expected ‘;’ before ‘)’ token
#include iostream
#include string
using namespace std;
bool ispalindrome(string s){
// replace with below line to see the error.
// for(string::iterator i1=s.begin(),string::reverse_iterator i2=s.rbegin() ;
i1!=s.end(); i1++, i2++) {
string::reverse_iterator i2=s.rbegin();
for(string::iterator i1=s.begin() ; i1!=s.end(); i1++, i2++) {
if (*i1!=*i2) return false;
}
return true;
}
int main()
{
string s;
cin s ;
if (ispalindrome(s)) {
cout First\n;
}else{
cout Second\n;
}
return 0;
}
[Bug bootstrap/56499] New: mpfr subdirectory path mismatch and misnamed files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56499 Bug #: 56499 Summary: mpfr subdirectory path mismatch and misnamed files Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: gary.bar...@atego.com configure uses mpfr/.lib instead of mpfr/src/.lib. There are two Solaris 10 files named *.hp instead of *.hpp Makefile.in also has the incorrect mpfr/.lib path but it is not used. Configuration: gcc-4.7.2 gmp-5.1.1 inserted into gcc-4.7.2/gmp mpc-1.0.1 inserted into gcc-4.7.2/mpc mpfr-3.1.1 inserted into gcc-4.7.2/mpfr Solaris 10 x86_32bit ../gcc-4.7.2/configure \ --prefix=/ned/tools/i386_solaris2 \ --enable-languages=c,c++ \ --disable-nls Using gcc (GCC) 3.4.0 to build stage1. References to mpfr internal structure are incorrect in configure. 4.4.3d-ategovnc 460: diff configure gcc-4.7.2/configure 5201,5203c5201,5203 gmplibs='-L$$r/$(HOST_SUBDIR)/mpfr/src/'$lt_cv_objdir $gmplibs gmpinc='-I$$r/$(HOST_SUBDIR)/mpfr/src -I$$s/mpfr/src '$gmpinc extra_mpc_mpfr_configure_flags='--with-mpfr-include=$$s/mpfr/src --with-mpfr-lib=$$r/$(HOST_SUBDIR)/mpfr/src/'$lt_cv_objdir --- gmplibs='-L$$r/$(HOST_SUBDIR)/mpfr/'$lt_cv_objdir $gmplibs gmpinc='-I$$r/$(HOST_SUBDIR)/mpfr -I$$s/mpfr '$gmpinc extra_mpc_mpfr_configure_flags='--with-mpfr-include=$$s/mpfr --with-mpfr-lib=$$r/$(HOST_SUBDIR)/mpfr/'$lt_cv_objdir The references to mpfr internal structure in Makefile.in are also incorrect, but are not used anywhere so are harmless. mpfr/.libs = mpfr/src/.libs @if mpfr HOST_LIB_PATH_mpfr = \ $$r/$(HOST_SUBDIR)/mpfr/.libs:$$r/$(HOST_SUBDIR)/prev-mpfr/.libs: @endif mpfr These files appear to have an incorrect extension. These links allow gcc to locate them during compiltion. An mv might be more appropriate but I have not tested that. ln -s \ ./gcc-4.7.2/libstdc++-v3/include/ext/pb_ds/detail/resize_policy/hash_load_check_resize_trigger_imp.hp \ ./gcc-4.7.2/libstdc++-v3/include/ext/pb_ds/detail/resize_policy/hash_load_check_resize_trigger_imp.hpp ln -s \ ./gcc-4.7.2/libstdc++-v3/include/ext/pb_ds/detail/bin_search_tree_/constructors_destructor_fn_imps.hp \ ./gcc-4.7.2/libstdc++-v3/include/ext/pb_ds/detail/bin_search_tree_/constructors_destructor_fn_imps.hpp
[Bug c++/56497] comparison is always true due to limited range of data type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56497 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-03-01 17:20:38 UTC --- (In reply to comment #0) Created attachment 29563 [details] g++ -Wtype-limits test.cxx It would be really nice if -Wtype-limits would catch all occurences in the following test case. That seems nearly impossible. The warning is emitted in the FE, and this would require inlining and/or constant propagation into function calls. Not likely to ever happen in GCC. You need something like http://clang-analyzer.llvm.org/ or http://cppcheck.sourceforge.net/. Better report a bug to them.
[Bug bootstrap/56499] mpfr subdirectory path mismatch and misnamed files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56499 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2013-03-01 17:23:02 UTC --- There are two Solaris 10 files named *.hp instead of *.hpp Use gnu tar to extract the tar file otherwise you get the truncated names.
[Bug bootstrap/56499] mpfr subdirectory path mismatch and misnamed files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56499 --- Comment #2 from Gary Barnes gary.barnes at atego dot com 2013-03-01 17:29:26 UTC --- I did use gnu tar. Those are the only two files with incorrect names. Gary -Original Message- From: pinskia at gcc dot gnu.org [mailto:gcc-bugzi...@gcc.gnu.org] Sent: Friday, March 01, 2013 9:23 AM To: Gary Barnes Subject: [Bug bootstrap/56499] mpfr subdirectory path mismatch and misnamed files http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56499 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2013-03-01 17:23:02 UTC --- There are two Solaris 10 files named *.hp instead of *.hpp Use gnu tar to extract the tar file otherwise you get the truncated names. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug.
[Bug c++/56497] comparison is always true due to limited range of data type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56497 Mathieu Malaterre mathieu.malaterre at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Mathieu Malaterre mathieu.malaterre at gmail dot com 2013-03-01 17:40:15 UTC --- ok. closing then.
[Bug fortran/48636] Enable more inlining with -O2 and higher
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636 William J. Schmidt wschmidt at gcc dot gnu.org changed: What|Removed |Added CC||wschmidt at gcc dot gnu.org --- Comment #43 from William J. Schmidt wschmidt at gcc dot gnu.org 2013-03-01 17:48:51 UTC --- (In reply to comment #38) Looks like for x86 r193331 led to significant regression on 172.mgrid for -m32 -O3 -funroll-loops The same degradation was seen on powerpc64-unknown-linux-gnu with r193331. The fix by Martin Jambor for PR55334 did not help for -m32. It did give a slight bump to -m64, but did not return the performance to pre-r193331 levels. So there still seems to be a problem with 172.mgrid related to this change.
[Bug target/56484] [4.8 Regression] ICE in assign_by_spills, at lra-assigns.c:1268
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56484 --- Comment #6 from Uros Bizjak ubizjak at gmail dot com 2013-03-01 18:06:28 UTC --- (In reply to comment #4) and the combiner combines the r60 = flags = 0 ? ax : r59 instruction with r59 = r60 into r59 = flags = 0 ? ax : r59 instruction in the last spot, thus extending the lifetime of the ax and flags hard registers across various other instructions. But AX is member of likely spilled class, so combine should take some more care with this insn. Should we just prevent propagations of all insns that mention likely spilled hard regs?
[Bug fortran/56500] New: [OOP] IMPLICIT CLASS(...) wrongly rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56500 Bug #: 56500 Summary: [OOP] IMPLICIT CLASS(...) wrongly rejected Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: ja...@gcc.gnu.org Found at http://mailman.j3-fortran.org/pipermail/j3/2013-March/006167.html IMPLICIT CLASS(...) (...) does not properly work with gfortran. R560 implicit-stmt is IMPLICIT implicit-spec-list or IMPLICIT NONE R561 implicit-spec is declaration-type-spec ( letter-spec-list ) R403 declaration-type-spec is intrinsic-type-spec or TYPE ( intrinsic-type-spec ) or TYPE ( derived-type-spec ) or CLASS ( derived-type-spec ) or CLASS ( * ) Example by Reinhold Bader: module mod_upimp type :: foo integer :: i end type end module program upimp use mod_upimp implicit class(foo) (a-b) implicit class(*) (c) allocatable :: aaf, caf allocate(aaf, source=foo(2)) allocate(caf, source=foo(3)) select type (aaf) type is (foo) write(*,*) aaf end select select type (caf) type is (foo) write(*,*) caf end select end program
[Bug bootstrap/56499] mpfr subdirectory path mismatch and misnamed files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56499 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-01 18:17:35 UTC --- There's nothing wrong with the tarball, it works for everyone else, so either your copy is corrupted and you need to download it again or you didn't use a recent version of GNU tar to unpack it. This is not a bug though. Every time this happens it's on Solaris, and because someone didn't use GNU tar or used an ancient version of GNU tar: http://gcc.gnu.org/ml/gcc-help/2012-06/msg00291.html http://gcc.gnu.org/ml/gcc-bugs/2008-04/msg01469.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33511#c13 http://gcc.gnu.org/install/prerequisites.html says GNU tar 1.14 or later is needed
[Bug c++/56498] invalid declaration of string iterator on comma separated list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56498 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-01 18:20:49 UTC --- (In reply to comment #0) Trying to declare and initialize two iterators in a comma separated list results in an invalid declaration error. There's a very good reason for that, C++ doesn't allow it. You cannot declare two variables of different types in a single declaration
[Bug bootstrap/56499] mpfr subdirectory path mismatch and misnamed files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56499 --- Comment #4 from Gary Barnes gary.barnes at atego dot com 2013-03-01 18:36:46 UTC --- You are correct. I used tar 1.13. Updating the various gnu tools here is basically why I'm building gcc in the first place. Thank you, Gary -Original Message- From: redi at gcc dot gnu.org [mailto:gcc-bugzi...@gcc.gnu.org] Sent: Friday, March 01, 2013 10:18 AM To: Gary Barnes Subject: [Bug bootstrap/56499] mpfr subdirectory path mismatch and misnamed files http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56499 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-01 18:17:35 UTC --- There's nothing wrong with the tarball, it works for everyone else, so either your copy is corrupted and you need to download it again or you didn't use a recent version of GNU tar to unpack it. This is not a bug though. Every time this happens it's on Solaris, and because someone didn't use GNU tar or used an ancient version of GNU tar: http://gcc.gnu.org/ml/gcc-help/2012-06/msg00291.html http://gcc.gnu.org/ml/gcc-bugs/2008-04/msg01469.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33511#c13 http://gcc.gnu.org/install/prerequisites.html says GNU tar 1.14 or later is needed -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug.
[Bug tree-optimization/56501] New: gcc 4.6 ICE on noreturn function at -Os and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56501
Bug #: 56501
Summary: gcc 4.6 ICE on noreturn function at -Os and above
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dhaze...@yahoo.com
The following testcase (derived from gzip) triggers an internal compiler error
with gcc 4.6, 4.5 and 4.4 when compiled at -Os or higher on x86_64-linux. The
problem does not occur with 4.7 or newer, or with 4.3 or older.
$ gcc-4.6 --version
gcc-4.6 (GCC) 4.6.3
$ gcc-4.6 -O1 -w small.c
$ gcc-4.6 -Os -w small.c
small.c: In function ‘main’:
small.c:24:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
$ cat small.c
int a;
void try_help () __attribute__ ((__noreturn__));
void try_help ()
{
}
int main ()
{
switch (a)
{
case '1':
case '2':
case '3':
case '4':
case '5':
case '6':
case '7':
case '8':
case '9':
break;
default:
try_help ();
}
}
[Bug c++/55135] [4.8 Regression] Segfault of gcc on a big file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135 --- Comment #19 from Steven Bosscher steven at gcc dot gnu.org 2013-03-01 19:13:32 UTC --- (In reply to comment #18) I thought you had already done that, to handle attribute flatten for bug 54146 (http://gcc.gnu.org/PR54146#c43). This test case doesn't use the flatten attribute, but explodes in the same way as the test case for bug 54146.
[Bug tree-optimization/49234] [4.5/4.6/4.7/4.8 Regression] -Wstrict-overflow gives obviously unwarranted warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49234
--- Comment #12 from Aldy Hernandez aldyh at redhat dot com 2013-03-01
19:17:32 UTC ---
--- Comment #11 from Ian Lance Taylor ian at airs dot com 2013-03-01
14:52:53 UTC ---
I suspect we can handle this case by observing that all the incoming values to
the PHI node are constants.
Ian.
They're not all constants. In this particular case we have phis like this:
state_2 = PHI 0(6), state_3(12), 2(5)
I suppose we could chase the SSA def chain and if all the phi arguments
are either constants, or known to point to an SSA that has been
previously analyzed as constant, then we can avoid generating an
overflow. But we'd have to keep track of states across calls to
vrp_visit_phi_node. Is this what you had in mind, or am I
misunderstanding something?
Obviously, Richi's idea is much simpler :). With his suggestion we
could probably do with:
@@ -8111,11 +8109,9 @@ vrp_visit_phi_node (gimple phi)
if (cmp_max 0 || cmp_max 0)
{
if (!needs_overflow_infinity (TREE_TYPE (vr_result.max))
- || !vrp_var_may_overflow (lhs, phi))
+ || !vrp_var_may_overflow (lhs, phi)
+ || supports_overflow_infinity (TREE_TYPE (vr_result.max)))
vr_result.max = TYPE_MAX_VALUE (TREE_TYPE (vr_result.max));
- else if (supports_overflow_infinity (TREE_TYPE (vr_result.max)))
- vr_result.max =
- positive_overflow_infinity (TREE_TYPE (vr_result.max));
}
And similarly for MIN. In the above, supports_overflow_infinity is just
there to make sure we have a CONSTANT_CLASS_P. If that's not needed, we
could even do:
if (cmp_max 0 || cmp_max 0)
vr_result.max = TYPE_MAX_VALUE (TREE_TYPE (vr_result.max));
and be done with it.
Let me know. I am willing to entertain any approach y'all suggest.
[Bug bootstrap/56499] mpfr subdirectory path mismatch and misnamed files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56499 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-01 19:20:58 UTC --- .
[Bug tree-optimization/49234] [4.5/4.6/4.7/4.8 Regression] -Wstrict-overflow gives obviously unwarranted warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49234
--- Comment #13 from Ian Lance Taylor ian at airs dot com 2013-03-01 19:23:00
UTC ---
How hard would it be to test whether the values are all constant or have the
same SSA_NAME_VAR as the value we are setting?
My only concern about richi's suggestion is that it will miss some simple
cases.
for (i = 1; i = 0; i *= 2)
{
int j = fn1 () ? i : 1;
if (j = 0)
fn ();
}
Here i overflows and so does j, but I think your patch will teach VRP that j
does not overflow, so we will get no warning for j = 0.
Or something like that.
[Bug tree-optimization/49234] [4.5/4.6/4.7/4.8 Regression] -Wstrict-overflow gives obviously unwarranted warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49234 --- Comment #14 from Aldy Hernandez aldyh at redhat dot com 2013-03-01 19:33:47 UTC --- On 03/01/13 13:23, ian at airs dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49234 --- Comment #13 from Ian Lance Taylor ian at airs dot com 2013-03-01 19:23:00 UTC --- How hard would it be to test whether the values are all constant or have the same SSA_NAME_VAR as the value we are setting? That was actually my first idea, but it seemed too simple :). I will do so and report back. Thanks.
[Bug c++/52688] static local variable can accessed from local class of function template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52688
jared.cantwell at gmail dot com changed:
What|Removed |Added
CC||jared.cantwell at gmail dot
||com
--- Comment #8 from jared.cantwell at gmail dot com 2013-03-01 19:53:56 UTC ---
I just came across the same issue in the context of lambdas (for posterity,
since I spent time thinking this was specific to lambdas).
Consider the following source code:
---
templatetypename T
void Foo()
{
static int i = 5;
auto bar = []() { ++i; };
bar();
}
int main()
{
Fooint();
}
---
GCC 4.7.0 produces the following error:
# g++-4.7 -std=c++11 main.cpp
/tmp/ccbZwBzT.o: In function `void Fooint()::{lambda()#1}::operator()()
const':
main.cpp:(.text+0x1a): undefined reference to `i'
main.cpp:(.text+0x23): undefined reference to `i'
collect2: error: ld returned 1 exit status
However, when Foo is not a template there is no error.
[Bug c++/56247] [4.6/4.7/4.8 Regression] internal compiler error: in tsubst_copy, at cp/pt.c:12131
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56247 DS dsagald8 at gmail dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #7 from DS dsagald8 at gmail dot com 2013-03-01 19:59:04 UTC --- Awesome quick work. Very impressive -- thank you!
[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461 --- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-01 20:59:07 UTC --- Author: jakub Date: Fri Mar 1 20:58:59 2013 New Revision: 196393 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196393 Log: PR middle-end/56461 * tree-vect-stmts.c (vect_create_vectorized_promotion_stmts): Call vec_oprnds0-release (); rather than vec_oprnds0-truncate (0) before overwriting it. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-stmts.c
[Bug c++/55135] [4.8 Regression] Segfault of gcc on a big file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135 --- Comment #20 from Steven Bosscher steven at gcc dot gnu.org 2013-03-01 21:05:00 UTC --- (In reply to comment #15) Trading memory O(number of pseudos) with a large constant factor sounds like something waiting for trouble for other testcases ... FWIW, for this particular test case, almost all registers end up in the set. I'm not sure why. And since there are NUM_MACHINE_MODES bits per register (NUM_MACHINE_MODES==87 on x86) the supposed-to-be sparse bitmaps are huge (100,000 bitmap_elements). I have a fix proper for this problem in testing.
[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461 --- Comment #18 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-01 21:06:13 UTC --- Author: jakub Date: Fri Mar 1 21:06:04 2013 New Revision: 196394 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196394 Log: PR middle-end/56461 * files.c (_cpp_save_file_entries): Free result at the end. * pch.c (cpp_string_free): New function. (cpp_save_state): Use it in htab_create call. (cpp_write_pch_deps): Free ss-defs. Destroy ss-definedhash. Modified: trunk/libcpp/ChangeLog trunk/libcpp/files.c trunk/libcpp/pch.c
[Bug debug/56502] New: entry-value: Missing DW_AT_linkage_name for C-C++ calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56502
Bug #: 56502
Summary: entry-value: Missing DW_AT_linkage_name for C-C++
calls
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jan.kratoch...@redhat.com
Target: x86_64-unknown-linux-gnu
Created attachment 29564
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29564
FSF GDB HEAD patch before it is upstreamed.
gcc-4.8.0-0.14.fc19.x86_64
gdb FSF HEAD with attached patch (reproducer does not work without patched GDB)
gcc -o extcall3.o -c extcall3.c -Wall -g -O2; g++ -o extcall extcall3.o
extcall{,2}.C -Wall -g -O2
gdb ./extcall -ex 'b a' -ex 'b b' -ex 'set debug entry-values 1' -ex r
Breakpoint 1, Cannot find function f(int) for a call site target at 0x4004ce
in main
(gdb) bt
#0 a (y=1) at extcall3.c:2
#1 0x004004ce in main () at extcall.C:4
(gdb) c
[...]
(gdb) bt
#0 b (y=y@entry=2) at extcall2.C:2
#1 0x00400607 in g (x=x@entry=42) at extcall2.C:3
#2 0x004004d8 in main () at extcall.C:5
You can see the first case main-f-a is missing the tail call frame because:
Cannot find function f(int) for a call site target at 0x4004ce in main
0bb: Abbrev Number: 1 (DW_TAG_compile_unit)
c0 DW_AT_language: 4(C++)
c1 DW_AT_name: extcall.C
2fa: Abbrev Number: 3 (DW_TAG_GNU_call_site)
fb DW_AT_low_pc : 0x4004ce
103 DW_AT_abstract_origin: 0x12e
112e: Abbrev Number: 7 (DW_TAG_subprogram)
12f DW_AT_external: 1
12f DW_AT_name: f
133 DW_AT_declaration : 1
2137: Abbrev Number: 8 (DW_TAG_formal_parameter)
138 DW_AT_type: 0x127
213c: Abbrev Number: 0
As 12e is in C++ CU and it has no DW_AT_linkage_name GDB expects it is
f(int) but the C symbol is f.
== extcall.C ==
extern C { void f(int x); }
void g(int x);
int main() {
f(42);
g(42);
}
== extcall2.C ==
static volatile int j;
static __attribute__((noinline, noclone)) void b(int y) { j=y; }
void g(int x) { b(2); }
== extcall3.c ==
static volatile int i;
static __attribute__((noinline, noclone)) void a(int y) { i=y; }
void f(int x) { a(1); }
[Bug fortran/56503] New: Wrong compiler error message when compiling with default-real-8 option and using intrinsic dble
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56503 Bug #: 56503 Summary: Wrong compiler error message when compiling with default-real-8 option and using intrinsic dble Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: cmwiel...@gmx.de Hi! I compile the little program beneath with 'gfortran -fdefault-integer-8 -fdefault-real-8' command. I get: 'call t1 ( dble(r4)) 1 Error: Type mismatch in argument 'r' at (1); passed REAL(16) to REAL(8) ' Since r4 is a single precision variable the dble should make a real*8 of it, or? The same happens when activating the real*4::r4 declaration in the module. Thanks, Maarten Program, that produces the error: --- module test !real*4 :: r4 contains subroutine t1( r) real*8 :: r print*,' hallo r=',r return end subroutine t1 end module program t use test real*4 :: r4 r4 = 4 call t1 ( dble(r4)) end program ---
[Bug fortran/56503] Wrong compiler error message when compiling with default-real-8 option and using intrinsic dble
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56503 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||kargl at gcc dot gnu.org Resolution||INVALID --- Comment #1 from kargl at gcc dot gnu.org 2013-03-01 21:57:07 UTC --- (In reply to comment #0) Hi! I compile the little program beneath with 'gfortran -fdefault-integer-8 -fdefault-real-8' command. I get: 'call t1 ( dble(r4)) 1 Error: Type mismatch in argument 'r' at (1); passed REAL(16) to REAL(8) ' Since r4 is a single precision variable the dble should make a real*8 of it, or? The error message says 'r' not 'r4'. The 'r' here comes from the explicit interface for t1, which has a declaration of real*8. So, if you read the documentation that comes with your compiler, you see that 'r' has been promoted to real*16. `-fdefault-double-8' Set the `DOUBLE PRECISION' type to an 8 byte wide type. If `-fdefault-real-8' is given, `DOUBLE PRECISION' would instead be promoted to 16 bytes if possible, and `-fdefault-double-8' can be used to prevent this. You probably meant to use -freal-4-real-8. I recommend using none of these options and actually writing properly ported code.
[Bug middle-end/56504] New: -mveclibabi=... Support AMD's LibM 3.0 (sucessor of ACML)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56504 Bug #: 56504 Summary: -mveclibabi=... Support AMD's LibM 3.0 (sucessor of ACML) Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org GCC currently supports: -mveclibabi=type Specifies the ABI type to use for vectorizing intrinsics [...] and acml for the AMD math core library. [...] [...]and __vrd2_sin, __vrd2_cos, __vrd2_exp, __vrd2_log, __vrd2_log2, __vrd2_log10, __vrs4_sinf, __vrs4_cosf, __vrs4_expf, __vrs4_logf, __vrs4_log2f, __vrs4_log10f and __vrs4_powf for the corresponding function type when -mveclibabi=acml is used. The current AMD LibM version, however, supports much more: http://developer.amd.com/tools/cpu-development/libm/ From the release notes: Vector Functions Exponential --- * vrs4_expf, vrs4_exp2f, vrs4_exp10f, vrs4_expm1f * vrsa_expf, vrsa_exp2f, vrsa_exp10f, vrsa_expm1f * vrd2_exp, vrd2_exp2, vrd2_exp10, vrd2_expm1 * vrda_exp, vrda_exp2, vrda_exp10, vrda_expm1 Logarithmic --- * vrs4_logf, vrs4_log2f, vrs4_log10f, vrs4_log1pf * vrsa_logf, vrsa_log2f, vrsa_log10f, vrsa_log1pf * vrd2_log, vrd2_log2, vrd2_log10, vrd2_log1p * vrda_log, vrda_log2, vrda_log10, vrda_log1p Trigonometric - * vrs4_cosf, vrs4_sinf * vrsa_cosf, vrsa_sinf * vrd2_cos, vrd2_sin * vrda_cos, vrda_sin * vrd2_sincos,vrda_sincos * vrs4_sincosf,vrsa_sincosf * vrd2_tan, vrs4_tanf * vrd2_cosh Power - * vrs4_cbrtf, vrd2_cbrt, vrs4_powf, vrs4_powxf * vrsa_cbrtf, vrda_cbrt, vrsa_powf, vrsa_powxf * vrd2_pow The vector functions are the known (cf. include/amdlibm.h): __m128d amd_vrd2_exp(__m128d x); __m128 amd_vrs4_expf (__m128 x); etc. While the array version use: void amd_vrsa_expf (int len, float *src, float *dst); void amd_vrda_exp2 (int len, double *src, double *dst); void amd_vrda_exp (int len, double *src, double *dst); void amd_vrsa_expf (int len, float *src, float *dst); Unfortunately, no further documentation is available, telling whether, e.g., src and dst may be the same or not. Note that AMD LibM now uses amd_ as prefix to the vector functions. It contains the old version as weak symbols but only those: 0340 W __vrd2_cos 00e0 W __vrd2_exp 01a0 W __vrd2_log 01c0 W __vrd2_log10 01b0 W __vrd2_log2 0330 W __vrd2_sin 0390 W __vrs4_cosf 00a0 W __vrs4_expf 0200 W __vrs4_log10f 01f0 W __vrs4_log2f 01e0 W __vrs4_logf 03a0 W __vrs4_sinf
[Bug c++/56493] Performance regression in google dense hashmap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56493 --- Comment #4 from Andrew Gallagher andrewjcg at gmail dot com 2013-03-01 22:09:10 UTC --- Created attachment 29565 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29565 Preprocessed test program source
[Bug c++/56493] Performance regression in google dense hashmap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56493 --- Comment #5 from Andrew Gallagher andrewjcg at gmail dot com 2013-03-01 22:10:14 UTC --- Ah, sorry. Just attached preprocessed sources now (which had to be compressed to it in the 1K size limit).
[Bug middle-end/56504] -mveclibabi=... Support AMD's LibM 3.0 (sucessor of ACML)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56504 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2013-03-01 22:11:50 UTC --- For completeness, also Intel strongly extended the supported vectorizing intrinsics, cf. http://software.intel.com/sites/products/documentation/doclib/mkl_sa/11/mklman/GUID-7B3B6537-71E2-4BF5-A041-0365E72B211B.htm
[Bug middle-end/56490] [4.6/4.7/4.8 Regression] -Wall triggering infinite loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56490 davidxl xinliangli at gmail dot com changed: What|Removed |Added CC||xinliangli at gmail dot com --- Comment #2 from davidxl xinliangli at gmail dot com 2013-03-01 22:45:48 UTC --- The function has a control flow that post-dom chain is as long as 103. Limiting the max post-dom walk length solve the problem.
[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461 --- Comment #19 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-01 22:54:46 UTC --- Author: jakub Date: Fri Mar 1 22:54:39 2013 New Revision: 196396 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196396 Log: PR middle-end/56461 * tree-vect-data-refs.c (vect_permute_store_chain): Avoid using copy method on dr_chain and result_chain. * tree-vect-stmts.c (vectorizable_store): Only call result_chain.create if j == 0. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-data-refs.c trunk/gcc/tree-vect-stmts.c
[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461 --- Comment #20 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-01 22:55:38 UTC --- Author: jakub Date: Fri Mar 1 22:55:26 2013 New Revision: 196397 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196397 Log: PR middle-end/56461 * ira-build.c (ira_loop_nodes_count): New variable. (create_loop_tree_nodes): Initialize it. (finish_loop_tree_nodes): Use it instead of looking at current_loops. Modified: trunk/gcc/ChangeLog trunk/gcc/ira-build.c
[Bug middle-end/56461] [4.8 Regression] GCC is leaking lots of memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56461 --- Comment #21 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-01 22:56:34 UTC --- Author: jakub Date: Fri Mar 1 22:56:18 2013 New Revision: 196398 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196398 Log: PR middle-end/56461 * tree-ssa-loop-ivcanon.c (tree_estimate_loop_size): Release path vector even when returning true. Fix up function comment formatting. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-loop-ivcanon.c
[Bug c++/52688] static local variable can accessed from local class of function template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52688
--- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-01
23:08:40 UTC ---
(In reply to comment #8)
I just came across the same issue in the context of lambdas (for posterity,
since I spent time thinking this was specific to lambdas).
Consider the following source code:
---
templatetypename T
void Foo()
{
static int i = 5;
auto bar = []() { ++i; };
bar();
}
int main()
{
Fooint();
}
---
GCC 4.7.0 produces the following error:
# g++-4.7 -std=c++11 main.cpp
/tmp/ccbZwBzT.o: In function `void Fooint()::{lambda()#1}::operator()()
const':
main.cpp:(.text+0x1a): undefined reference to `i'
main.cpp:(.text+0x23): undefined reference to `i'
collect2: error: ld returned 1 exit status
Can't be exactly the same issue: mainline and 4.7.3 get this one right.
[Bug bootstrap/55644] bootstrap-lto fails on current trunk (with and without profiledbootstrap)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55644 --- Comment #10 from Matt Hargett matt at use dot net 2013-03-01 23:11:50 UTC --- I'll file a new bug for each warning false positive that results in a bootstrap failure. Feel free to close this one.
[Bug c++/52688] static local variable can accessed from local class of function template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52688 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.8.0 Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-01 23:15:22 UTC --- In fact this issue (in terms of Comment #0 and Comment #7) is fixed for 4.8.0.
[Bug c++/52688] static local variable can accessed from local class of function template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52688
--- Comment #11 from jared.cantwell at gmail dot com 2013-03-01 23:18:23 UTC ---
(In reply to comment #9)
(In reply to comment #8)
I just came across the same issue in the context of lambdas (for posterity,
since I spent time thinking this was specific to lambdas).
Consider the following source code:
---
templatetypename T
void Foo()
{
static int i = 5;
auto bar = []() { ++i; };
bar();
}
int main()
{
Fooint();
}
---
GCC 4.7.0 produces the following error:
# g++-4.7 -std=c++11 main.cpp
/tmp/ccbZwBzT.o: In function `void Fooint()::{lambda()#1}::operator()()
const':
main.cpp:(.text+0x1a): undefined reference to `i'
main.cpp:(.text+0x23): undefined reference to `i'
collect2: error: ld returned 1 exit status
Can't be exactly the same issue: mainline and 4.7.3 get this one right.
It seems my comment is more aligned with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54276 then this case.
[Bug c++/52688] static local variable can accessed from local class of function template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52688 --- Comment #12 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-01 23:23:40 UTC --- Yes, it seems your own issue is a duplicate of PR54276, which luckily is already fixed both in mainline and for 4.7.3.
[Bug bootstrap/55644] maybe-uninitialized false positive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55644 Matt Hargett matt at use dot net changed: What|Removed |Added Summary|bootstrap-lto fails on |maybe-uninitialized false |current trunk (with and |positive |without profiledbootstrap) | --- Comment #11 from Matt Hargett matt at use dot net 2013-03-01 23:34:53 UTC --- The current false positives emitted: mhargett@chert:/work/mhargett/gcc-trunk-lto-O3-debug/gcc$ /work/mhargett/gcc-trunk-lto-O3-debug/./prev-gcc/xg++ -B/work/mhargett/gcc-trunk-lto-O3-debug/./prev-gcc/ -B/u/mhargett/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/work/mhargett/gcc-trunk-lto-O3-debug/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/work/mhargett/gcc-trunk-lto-O3-debug/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/work/mhargett/gcc-trunk-lto-O3-debug/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/work/mhargett/gcc-trunk-lto-O3-debug/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/work/mhargett/gcc-trunk/libstdc++-v3/libsupc++ -L/work/mhargett/gcc-trunk-lto-O3-debug/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/work/mhargett/gcc-trunk-lto-O3-debug/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -O3 -g -flto=jobserver -flto-partition=none -frandom-seed=1 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc gcov-dump.o libcommon.a ../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -o gcov-dump ../../gcc-trunk/libbacktrace/elf.c: In function 'elf_add': ../../gcc-trunk/libbacktrace/mmapio.c:98:14: error: 'ehdr_view.len' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (munmap (const_cast.v, view-len) 0) ^ ../../gcc-trunk/libbacktrace/elf.c:476:25: note: 'ehdr_view.len' was declared here struct backtrace_view ehdr_view; ^ ../../gcc-trunk/libbacktrace/mmapio.c:98:14: error: 'ehdr_view.base' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (munmap (const_cast.v, view-len) 0) ^ ../../gcc-trunk/libbacktrace/elf.c:476:25: note: 'ehdr_view.base' was declared here struct backtrace_view ehdr_view; ^ ../../gcc-trunk/libbacktrace/elf.c:516:10: error: 'ehdr_view.data' may be used uninitialized in this function [-Werror=maybe-uninitialized] memcpy (ehdr, ehdr_view.data, sizeof ehdr); ^ ../../gcc-trunk/libbacktrace/elf.c:476:25: note: 'ehdr_view.data' was declared here struct backtrace_view ehdr_view; ^ which is a false positive, because ehdr_view's fields are correctly initialized via a call from elf_add() to backtrace_get_view() view-data = (char *) map + inpage; view-base = map; view-len = size; if the mmap() earlier in the backtrace_get_view() didn't fail, view is initialized and the backtrace_get_view() returns 1. if that mmap() fails, view remains uninitialized and backtrace_get_view() returns 0. elf_add()'s invocation checks the return value of backtrace_get_view(). in the 0 (failure) case, backtrace_release_view() is never invoked: if (!backtrace_get_view (state, descriptor, 0, sizeof ehdr, error_callback, data, ehdr_view)) goto fail; since backtrace_release_view() is never called in the case where the fields are uninitialized, the warning is a false positive. while it occurs here with the confluence of several optimizations, it looks like the same problem would happen in a contrived single-file case. attached are the temp files for the module the generated this false positive.
[Bug middle-end/55644] maybe-uninitialized false positive due to incorrect flow analysis when gotos are present
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55644 --- Comment #12 from Matt Hargett matt at use dot net 2013-03-01 23:38:51 UTC --- Created attachment 29566 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29566 files generated during compilation where false positive happens with save-temps
[Bug fortran/56500] [OOP] IMPLICIT CLASS(...) wrongly rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56500
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2013-03-02
00:06:45 UTC ---
The problem seems to be that class_ok is not true; the reason seems to be
that gfc_build_class_symbol does not get called.
I am not sure, when it has to be called but it currently fails for:
implicit class(*) (a-z)
allocatable :: foo
end
and for
subroutine foo(x)
implicit class(*) (a-z)
end
The error message is printed in resolve.c's resolve_fl_var_and_proc:
/* Constraints on polymorphic variables. */
...
if (!sym-attr.class_ok !sym-attr.use_assoc !sym-assoc)
{
gfc_error (CLASS variable '%s' at %L must be dummy, allocatable
or pointer, sym-name, sym-declared_at);
gfc_build_class_symbol is currently only called in decl.c via build_struct
and via attr_decl1. One probably has to call it in symbol.c's
gfc_set_default_type
[Bug c++/56493] Performance regression in google dense hashmap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56493 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever Confirmed|1 |0 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-02 00:56:53 UTC --- thanks
[Bug libstdc++/56505] New: [4.7 Regression] cannot construct std::thread with pointer to member and non-pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56505
Bug #: 56505
Summary: [4.7 Regression] cannot construct std::thread with
pointer to member and non-pointer
Classification: Unclassified
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: r...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
Switching std::thread to use __bind_simple broke this code, because std::mem_fn
can't handle rvalues:
#include thread
struct S {
void f() { }
} s;
std::thread t(S::f, s);
This was fixed on trunk by PR 55463 but is a regression since 4.6
[Bug libstdc++/56505] [4.7 Regression] cannot construct std::thread with pointer to member and non-pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56505 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-02 01:51:11 UTC --- note to self, the follow-up patch in http://gcc.gnu.org/r193879 was also needed on trunk
