[Bug debug/37022] internal compiler error: in compute_barrier_args_size
--- Comment #18 from jakub at gcc dot gnu dot org 2010-01-25 08:22 --- It is no longer marged regression, so no longer release critical. Anyway, the goal should be to reenable the asserts in dwarf2out.c and fix the issues, because they really result in wrong unwind info. Only the unwinder uses it though (DW_CFA_GNU_args_size), so the question is if we can come up with a testcase that actually misbehaves of it. There are two known cases which triggered the assertions - one is alloca with an argument that ends up to be constant in the end, and the other is crossjumping of noreturn sequences with different stack push depth. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |major Priority|P1 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37022
[Bug c++/42824] c++ compilation complains about error: call of overloaded
--- Comment #8 from mario-baumann at web dot de 2010-01-25 08:24 --- Hi Jonathan, thanks for the hint! I attached a version (goo.cpp) without boost. > g++ -c goo.cpp goo.cpp: In member function 'void Eval::eval(int_<0>) [with int V = 0, T = Mtrl]': goo.cpp:42:9: instantiated from 'void Eval::eval() [with int V = 0, T = Mtrl]' goo.cpp:65:20: instantiated from here goo.cpp:57:9: error: call of overloaded 'value(Eval::Wrap >)' is ambiguous goo.cpp:49:10: note: candidates are: void Eval::value(Eval::Wrap >) [with int V = 0, int V2 = 0, T = Mtrl] goo.cpp:52:10: note: void Eval::value(Eval::Wrap >) [with int V = 0, T = Mtrl] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42824
[Bug c++/42824] c++ compilation complains about error: call of overloaded
--- Comment #9 from mario-baumann at web dot de 2010-01-25 08:26 --- Created an attachment (id=19702) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19702&action=view) new c++ source file (independent of boost) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42824
[Bug fortran/42848] compiler crashes and asks for this bug report
--- Comment #4 from burnus at gcc dot gnu dot org 2010-01-25 08:30 --- (In reply to comment #3) > Today I am not able to reproduce the error. The compiler is working. Where > exactly does the file m.mod reside? In the user directory or in a compiler > directory? By default in the current directory - unless you used the option -J to specify a different one. Note: In order to help writing makefiles which have dependencies on the .mod files, gfortran only overwrites the .mod files if they have changed. Thus, to reproduce the problem, you could compile the program with a different compiler or an older version of GCC - or simply create in any editor the .mod file. (Modifying the Fortran module + running gfortran also produces a new .mod file, but I think works also without the patch of PR 40195.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42848
[Bug fortran/42848] compiler crashes and asks for this bug report
--- Comment #5 from frank dot braun at rz dot uni-regensburg dot de 2010-01-25 08:36 --- 've got it. Modifying the .mod file by hand makes the compiler crash. Deleting it lets it work correctly. The compiler shouldn't crash anyway. But with a new version this problem should be solved too, isn't it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42848
[Bug libgcj/40860] [4.4/4.5 regression] regressions in libjava testsuite on arm-linux
--- Comment #2 from mikpe at it dot uu dot se 2010-01-25 09:33 --- I had very recently updated binutils from 2.19.1 to 2.20 + branch updates + some fixes from trunk. Going back to binutils 2.19.1 while changing nothing else eliminated the StackTrace2 and Throw_3 failures from gcc-4.3. My last gcc-4.4 build and test suite run was probably still with binutils-2.19.1, which might explain why I didn't see those errors there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40860
[Bug fortran/42858] [4.5 Regression] ICE in gfc_array_dimen_size at ../../trunk/gcc/fortran/array.c:2063
--- Comment #4 from burnus at gcc dot gnu dot org 2010-01-25 09:37 ---
(In reply to comment #3)
> This appears to fix this: regression tested on x86-64
I think the following patch is better. My intrinsic check was bogus.
Index: array.c
===
--- array.c (revision 156196)
+++ array.c (working copy)
@@ -2054,7 +2054,7 @@ gfc_array_dimen_size (gfc_expr *array, i
}
if (array->symtree->n.sym->attr.generic
- && !array->symtree->n.sym->attr.intrinsic)
+ && array->value.function.esym != NULL)
{
if (spec_dimen_size (array->value.function.esym->as, dimen, result)
== FAILURE)
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2010-01-25 01:18:04 |2010-01-25 09:37:46
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42858
[Bug middle-end/42859] [4.5 regression] ICE in verify_flow_info
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-25 09:56 --- Confirmed. Reducing. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-01-25 09:56:22 date|| Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42859
[Bug middle-end/42859] [4.5 regression] ICE in verify_flow_info
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-25 10:06 ---
I suppose this is from rths exception rewrite.
void start (void);
void ptw32_terminate (void)
{
try {
start ();
}
catch( int ) { }
catch( int ) { }
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rth at gcc dot gnu dot org
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42859
[Bug libstdc++/42832] Revisit std::function for aliasing issues
--- Comment #5 from paolo dot carlini at oracle dot com 2010-01-25 10:10 --- Ok, I see that asking was a good idea, the tangle of issues is quite complex. Anyway, this is my current proposal: let' use for now your mildly optimized and in any case correct solution using a loop of char-wise std::swap, the first solution you proposed on the gcc-patches discussion. For both std and tr1. Likely tr1 will stay like that forever. Let's remove the dependency of this bug on the overzealous memcpy optimization bug and the blocking of the optimization issue which started this discussion; let's add instead dependency on the "uninitialized_swap" enhancement. Let's keep the present bug open of course, as enhancement. Are you willing to prepare a patch including a comment, better two different comments one simpler for the tr1 version and one slightly longer for the std version? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42832
[Bug fortran/42852] gfortran -Wall warns about truncated lines when only a continuation character is truncated
--- Comment #4 from bugs at 59A2 dot org 2010-01-25 10:33 --- (In reply to comment #3) > So it's gfortran's fault you write non-portable code, and instead > of dealing with it on your end, you think that gfortran developers > should do the work to make your code compile. Actually, gfortran versions up to and including 4.4.2 do not complain about this usage (but it looks like that was due to -Wline-truncation being defective). All versions of gfortran compile this hybrid source "correctly", it's only (what I consider) a spurious warning with -Wline-truncation, and only in the 4.5 snapshot. > I'll note that I stated that I felt it should be closed with a > WONTFIX, but changed it to an enhancement request. In lieu of receiving > a patch from you to address the issue, someone may someday in the > distant future, when there are less important bugs to fix, might > address the issue. I'm not familiar with the project, but if you tell me where to look, I may be able to submit a patch. > The Note in the Standard is assuming a specific behavior for a > processor-dependent behavior. gfortran currently does not > assume that specific choice. Based on the way the source is compiled, as opposed to warnings under -Wline-truncation, gfortran *does* make that specific choice. If you are saying that this may change in the future (making such source an error instead of a warning), then the warning is completely valid (but anticipate user complaints if such a change happens). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42852
[Bug tree-optimization/42585] [4.5 Regression] SRA is not good for structure copies with one replacement any more
--- Comment #7 from jamborm at gcc dot gnu dot org 2010-01-25 10:38 --- I understand that the bootstrap problem is PR 42836 and is now fixed (thanks for that). SRA now removes the structures in the testcase from bug description and so I consider this to be fixed. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42585
[Bug debug/42861] New: [4.4/4.5 Regression] Spill slots not tracked during var-tracking
PR37815 introduced a regression - no decls are tracked in spill slots, as they have MEM_EXPR set to get_spill_slot_decl (false) instead of the real decl. On the testcase I'm going to attach, the tok argument is (and clearly has to be) live through the whole function except maybe last few instructions in epilogue, but as gcc decides to use regparm(2) calling convention, var-tracking thinks the parameter isn't live in most of the function. I'm afraid we'll need to track what values live in the spill slots during var-tracking. Easy hack to get at least something working would be just to handle spill slots that have at most one decl stored to it - then just one vector mapping byte offsets in the spill area to decls or REG_EXPRs would be sufficient. We'd just walk the whole function, note what is stored into the spill slots and if there are any conflicts, just remember that we can't use it. Or we could actually track what is currently stored in each spill slot even if the slot isn't for the same decl in all places. -- Summary: [4.4/4.5 Regression] Spill slots not tracked during var- tracking Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at gcc dot gnu dot org GCC target triplet: i686-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42861
[Bug debug/42861] [4.4/4.5 Regression] Spill slots not tracked during var-tracking
--- Comment #1 from jakub at gcc dot gnu dot org 2010-01-25 11:45 --- Created an attachment (id=19703) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19703&action=view) parsetok.c.bz2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42861
[Bug testsuite/42854] [4.4/4.5 Regression] FAIL: gcc.dg/darwin-weakimport-[13].c scan-assembler-not *
--- Comment #1 from jakub at gcc dot gnu dot org 2010-01-25 12:03 --- This is completely undocumented attribute, so you first need to get Apple to actually document what it does and get the documentation into doc/extend.texi. Especially nothing explains the relationship between weak attribute, weak_import attribute and #pragma weak. Unless this is clarified, there is nothing that can be done about this, complain to Apple. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42854
[Bug debug/42861] [4.4/4.5 Regression] Spill slots not tracked during var-tracking
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42861
[Bug target/38697] gcc.target/arm/neon/neon.exp tests for vmov fail on arm-linux-eabi
--- Comment #9 from ramana at gcc dot gnu dot org 2010-01-25 12:29 ---
Subject: Bug 38697
Author: ramana
Date: Mon Jan 25 12:29:25 2010
New Revision: 156206
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156206
Log:
Backport target/38697
Backport from trunk.
2010-01-19 Ramana Radhakrishnan
PR target/38697
* config/arm/neon-testgen.m (emit_automatics): New parameter
features. Adjust for Fixed_return_reg feature.
(test_intrinsic): Call emit_automatics with new feature.
* config/arm/neon.ml: Update copyright years.
(features): New Fixed_return_reg feature.
(ops): Update feature for Vget_low.
Backport from mainline.
2010-01-19 Ramana Radhakrishnan
PR target/38697.
* gcc.target/arm/neon/vget_lowf32.c: Regenerate.
* gcc.target/arm/neon/vget_lowp16.c: Likewise.
* gcc.target/arm/neon/vget_lowp8.c: Likewise.
* gcc.target/arm/neon/vget_lows16.c: Likewise.
* gcc.target/arm/neon/vget_lows32.c: Likewise.
* gcc.target/arm/neon/vget_lows64.c: Likewise.
* gcc.target/arm/neon/vget_lows8.c: Likewise.
* gcc.target/arm/neon/vget_lowu16.c: Likewise.
* gcc.target/arm/neon/vget_lowu32.c: Likewise.
* gcc.target/arm/neon/vget_lowu64.c: Likewise.
* gcc.target/arm/neon/vget_lowu8.c: Likewise.
Modified:
branches/gcc-4_4-branch/ (props changed)
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/config/arm/neon-testgen.ml
branches/gcc-4_4-branch/gcc/config/arm/neon.ml
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/arm/neon/vget_lowf32.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/arm/neon/vget_lowp16.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/arm/neon/vget_lowp8.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/arm/neon/vget_lows16.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/arm/neon/vget_lows32.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/arm/neon/vget_lows64.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/arm/neon/vget_lows8.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/arm/neon/vget_lowu16.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/arm/neon/vget_lowu32.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/arm/neon/vget_lowu64.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/arm/neon/vget_lowu8.c
Propchange: branches/gcc-4_4-branch/
('svn:mergeinfo' added)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38697
[Bug target/38697] gcc.target/arm/neon/neon.exp tests for vmov fail on arm-linux-eabi
--- Comment #10 from ramana at gcc dot gnu dot org 2010-01-25 12:30 --- Fixed on branch . -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38697
[Bug testsuite/42854] [4.4/4.5 Regression] FAIL: gcc.dg/darwin-weakimport-[13].c scan-assembler-not *
--- Comment #2 from dominiq at lps dot ens dot fr 2010-01-25 12:53 --- > This is completely undocumented attribute ... What is the "undocumented attribute"? If you mean "-fno-asynchronous-unwind-tables", you don't need it for the tests to fail. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42854
[Bug testsuite/42854] [4.4/4.5 Regression] FAIL: gcc.dg/darwin-weakimport-[13].c scan-assembler-not *
--- Comment #3 from jakub at gcc dot gnu dot org 2010-01-25 12:59 --- I mean that grep weak_import doc/* yields nothing at all (and google for weak_import doesn't show up any useful documentation either). It seems that Geoff Keating's implementation of the attribute (how could it be committed without documentation nor at least some words on what it is meant to do?) basically ignored it if weak attribute was also specified. Just removing those lookup_attribute (, "weak") tests would cure this. That really depends on what __attribute__((weak, weak_import)) is supposed to mean (if anything). Or what means combination of #pragma weak and weak_import attribute for the same decl name. Also, what matters is if undefined weak_import symbols are supposed to generate weak directives or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42854
[Bug testsuite/41522] gcc.c-torture/compile/pr38789.c fails on Solaris/SPARC with native assembler
--- Comment #2 from ro at gcc dot gnu dot org 2010-01-25 14:54 --- Subject: Bug 41522 Author: ro Date: Mon Jan 25 14:54:15 2010 New Revision: 156213 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156213 Log: PR testsuite/41522 * gcc.c-torture/compile/pr38789.c: Change to dg-do compile. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/compile/pr38789.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41522
[Bug testsuite/41522] gcc.c-torture/compile/pr38789.c fails on Solaris/SPARC with native assembler
--- Comment #3 from ro at gcc dot gnu dot org 2010-01-25 14:55 --- Mine. -- ro at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ro at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-01-25 14:55:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41522
[Bug testsuite/41522] gcc.c-torture/compile/pr38789.c fails on Solaris/SPARC with native assembler
--- Comment #4 from ro at gcc dot gnu dot org 2010-01-25 14:56 --- Fixed for 4.5.0: http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01255.html -- ro at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41522
[Bug fortran/42858] [4.5 Regression] ICE in gfc_array_dimen_size at ../../trunk/gcc/fortran/array.c:2063
--- Comment #5 from burnus at gcc dot gnu dot org 2010-01-25 16:22 --- Subject: Bug 42858 Author: burnus Date: Mon Jan 25 16:21:42 2010 New Revision: 156214 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156214 Log: 2010-01-25 Tobias Burnus PR fortran/42858 * array.c (gfc_array_dimen_size): Fix intrinsic procedure check. 2010-01-25 Tobias Burnus PR fortran/42858 * gfortran.dg/generic_21.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/generic_21.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42858
[Bug fortran/42858] [4.5 Regression] ICE in gfc_array_dimen_size at ../../trunk/gcc/fortran/array.c:2063
--- Comment #6 from burnus at gcc dot gnu dot org 2010-01-25 16:24 --- And FIXED. Thanks a lot for the report and sorry for breaking the code! -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Keywords||ice-on-valid-code Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42858
[Bug libstdc++/42832] Revisit std::function for aliasing issues
--- Comment #6 from rguenther at suse dot de 2010-01-25 16:29 --- Subject: Re: Revisit std::function for aliasing issues On Mon, 25 Jan 2010, paolo dot carlini at oracle dot com wrote: > --- Comment #5 from paolo dot carlini at oracle dot com 2010-01-25 10:10 > --- > Ok, I see that asking was a good idea, the tangle of issues is quite complex. > Anyway, this is my current proposal: let' use for now your mildly optimized > and > in any case correct solution using a loop of char-wise std::swap, the first > solution you proposed on the gcc-patches discussion. For both std and tr1. > Likely tr1 will stay like that forever. Let's remove the dependency of this > bug > on the overzealous memcpy optimization bug and the blocking of the > optimization > issue which started this discussion; let's add instead dependency on the > "uninitialized_swap" enhancement. Let's keep the present bug open of course, > as > enhancement. > > Are you willing to prepare a patch including a comment, better two different > comments one simpler for the tr1 version and one slightly longer for the std > version? I'll let the dust settle a bit on the gcc-patches discussion; I can then post a patch along the above lines. Thanks, Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42832
[Bug tree-optimization/42771] [4.5 Regression] ICE: in graphite_loop_normal_form, at graphite-sese-to-poly.c (2)
--- Comment #4 from uramakrishna at gmail dot com 2010-01-25 16:30 --- Created an attachment (id=19704) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19704&action=view) A further reduced case to show the ICE Unable to find non-zero value for 'known_niter'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42771
[Bug c++/42862] New: Anonymous Structures: Incorrect DWARF data generated
GCC Version: 3.4.4 and 4.1.2
The GNU 4.1.2 C++ compiler is not generating the proper typedef DIEs in the
DWARF data.
For example, the type definition BASE_UNION is defined as
typedef union
{
char ch;
int iVal;
long IVal;
} BASE_UNION;
The GNU 4.1.2 compiler generates the following DWARF data for this type
<1><1279>: Abbrev Number: 35 (DW_TAG_union_type)
<127a> DW_AT_sibling : <12a8>
<127e> DW_AT_name: $_4
<1282> DW_AT_byte_size : 4
<1283> DW_AT_decl_file : 35
<1284> DW_AT_decl_line : 29
<2><1285>: Abbrev Number: 36 (DW_TAG_member)
<1286> DW_AT_name: ch
<1289> DW_AT_decl_file : 35
<128a> DW_AT_decl_line : 30
<128b> DW_AT_type:
<2><128f>: Abbrev Number: 36 (DW_TAG_member)
<1290> DW_AT_name: iVal
<1295> DW_AT_decl_file : 35
<1296> DW_AT_decl_line : 31
<1297> DW_AT_type:
<2><129b>: Abbrev Number: 36 (DW_TAG_member)
<129c> DW_AT_name: IVal
<12a1> DW_AT_decl_file : 35
<12a2> DW_AT_decl_line : 32
<12a3> DW_AT_type:
Notice that the union name has been set to "$_4" in DIE <1279>. The correct
DWARF data would have no name attribute for the union DIE <1279> and it would
have a type-def DIE which pointed to the union die such as:
<1>: DW_TAG_typedef
DW_AT_name: BASE_UNION
DW_AT_decl_line : 26
DW_AT_decl_column : 3
DW_AT_decl_file : 9
DW_AT_type: <0x1279>
Interestingly enough, the GNU 3.4.4 compiler generates the following DWARF data
from the same source code and this is also incomplete:
<1><11d0>: Abbrev Number: 27 (DW_TAG_union_type)
DW_AT_sibling : <123f>
DW_AT_name: (indirect string, offset: 0x6e): BASE_UNION
DW_AT_byte_size : 4
DW_AT_decl_file : 3
DW_AT_decl_line : 29
--
Summary: Anonymous Structures: Incorrect DWARF data generated
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: louzonr at yahoo dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42862
[Bug tree-optimization/42771] [4.5 Regression] ICE: in graphite_loop_normal_form, at graphite-sese-to-poly.c (2)
--- Comment #5 from amonakov at gcc dot gnu dot org 2010-01-25 17:06
---
We fail to find number of iterations after rewriting reductions out of SSA.
Before graphite pass, IR looks like (for the previous testcase, "pr42771.c"):
:
# j_26 = PHI
:
# j_33 = PHI
D.2747_16 = B[j_33][0];
D.2748_17 = j_33 + -1;
D.2749_18 = B[D.2748_17][0];
D.2750_19 = D.2749_18 ^ D.2747_16;
B[j_33][0] = D.2750_19;
j_20 = j_33 + 1;
if (jm_14(D) > j_20)
goto ;
else
goto ;
At the time of the ICE, IR is transformed to
(gdb) call debug_loop(use_loop, 3)
loop_3 (header = 10, latch = 9, niter = (unsigned int) jm_14(D) + 4294967294,
upper_bound = 2147483646)
{
bb_9 (preds = {bb_10 }, succs = {bb_10 })
{
:
# .MEM_24 = PHI <.MEM_78(10)>
# VUSE <.MEM_24>
j_26 = Close_Phi.13[0];
# .MEM_79 = VDEF <.MEM_24>
General_Reduction.14[0] = j_26;
}
bb_10 (preds = {bb_9 bb_16 }, succs = {bb_9 bb_11 })
{
:
# .MEM_15 = PHI <.MEM_79(9), .MEM_77(16)>
# VUSE <.MEM_15>
D.2766_76 = General_Reduction.14[0];
j_33 = D.2766_76;
# VUSE <.MEM_15>
D.2747_16 = B[j_33][0];
D.2748_17 = j_33 + -1;
# VUSE <.MEM_15>
D.2749_18 = B[D.2748_17][0];
D.2750_19 = D.2749_18 ^ D.2747_16;
# .MEM_30 = VDEF <.MEM_15>
B[j_33][0] = D.2750_19;
j_20 = j_33 + 1;
# .MEM_78 = VDEF <.MEM_30>
Close_Phi.13[0] = j_20;
if (jm_14(D) > j_20)
goto ;
else
goto ;
}
}
We would fail to discover scalar evolution of j_33.
--
amonakov at gcc dot gnu dot org changed:
What|Removed |Added
CC||amonakov at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42771
[Bug tree-optimization/42806] "-fcompare-debug failure (length)" at -O1 in recent builds
--- Comment #2 from zsojka at seznam dot cz 2010-01-25 17:34 --- Since: r155937 | rguenth | 2010-01-15 12:53:26 +0100 (Fri, 15 Jan 2010) | 10 lines 2010-01-15 Richard Guenther PR middle-end/42739 * tree-cfgcleanup.c (remove_forwarder_block): Move destination labels of computed or non-local gotos to the destination. * tree-cfg.c (gimple_verify_flow_info): Verify that a EH landing pad label is the first label. * g++.dg/torture/pr42739.C: New testcase. -- zsojka at seznam dot cz changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42806
[Bug libstdc++/42832] Revisit std::function for aliasing issues
--- Comment #7 from paolo dot carlini at oracle dot com 2010-01-25 17:36 --- Ageeed. Indeed, I see there is a discussion ongoing. In the present time frame let's figure out something minimally invasive, decently (if not perfectly) optimized, and minimally coupled one way or the other to the other open issues. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42832
[Bug c++/42748] warnings about 'mangling of 'va_list' has changed in GCC 4.4' not suppressed in sytem headers
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42748
[Bug tree-optimization/42586] load-modify-store on x86 should be a single instruction
--- Comment #20 from jamborm at gcc dot gnu dot org 2010-01-25 17:51 --- (In reply to comment #6) > I think if we get the old SRA behavior back for this code, we will get this > optimization in 4.5 since we remove the sptr->base and the other unnecessary > store during PRE. > We now should have the "old SRA behavior" back (this was PR 42585). I have checked only very briefly but I believe that this testcase is now compiled as requested in the bug summary. I'd be grateful if someone could double-check this and close this bug if it is indeed so. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42586
[Bug libstdc++/36101] deps on other host libraries incorrect
--- Comment #29 from amylaar at gcc dot gnu dot org 2010-01-25 18:01 --- Subject: Bug 36101 Author: amylaar Date: Mon Jan 25 18:01:29 2010 New Revision: 156218 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156218 Log: PR libstdc++/36101, PR libstdc++/42813 * configure.ac (bootstrap_target_libs): Make inclusion of target-libgomp conditional on libgomb being in target_configdirs. * configure: Regenerate. Modified: trunk/ChangeLog trunk/configure trunk/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36101
[Bug libstdc++/42813] --enable-build-with-cxx libstdc++-v3 is incomplete
--- Comment #8 from amylaar at gcc dot gnu dot org 2010-01-25 18:01 --- Subject: Bug 42813 Author: amylaar Date: Mon Jan 25 18:01:29 2010 New Revision: 156218 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156218 Log: PR libstdc++/36101, PR libstdc++/42813 * configure.ac (bootstrap_target_libs): Make inclusion of target-libgomp conditional on libgomb being in target_configdirs. * configure: Regenerate. Modified: trunk/ChangeLog trunk/configure trunk/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42813
[Bug middle-end/42590] unnecessary stack frame set up
--- Comment #1 from jamborm at gcc dot gnu dot org 2010-01-25 18:02 --- Since PR 42585 is fixed, the optimized dump (at -O2) is : _T2$curr_12 = sptr_1(D)->curr; D.1966_7 = _T2$curr_12 + -1; sptr_1(D)->curr = D.1966_7; return 0; } The generated assembly is: Cyc_string_ungetc: pushl %ebp movl%esp, %ebp movl12(%ebp), %eax subl$1, (%eax) xorl%eax, %eax popl%ebp ret With -O2 -fomit-frame-pointer it is: Cyc_string_ungetc: movl8(%esp), %eax subl$1, (%eax) xorl%eax, %eax ret (Which is weird because the manual says that -fomit-frame-pointer is enabled at -O2 by default - maybe this is the actual bug here now?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42590
[Bug middle-end/42590] unnecessary stack frame set up
--- Comment #2 from jakub at gcc dot gnu dot org 2010-01-25 18:24 --- On i?86-linux -fomit-frame-pointer is not the default, on the contrary. info gcc says: `-O' also turns on `-fomit-frame-pointer' on machines where doing so does not interfere with debugging. and i?86-linux is not considered such machine (unlike e.g. x86_64-linux). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42590
[Bug middle-end/42590] unnecessary stack frame set up
--- Comment #3 from jamborm at gcc dot gnu dot org 2010-01-25 18:30 --- I have found the sentence you quoted in the manual too but it refers only to -O1 (as far as I understand it). And the description of -fomit-frame-pointer simply states that "Enabled at levels -O, -O2, -O3, -Os." So I'd say that at least the documentation is slightly confusing. Anyway, does this mean that this issue is also resolved now? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42590
[Bug c++/42824] c++ compilation complains about error: call of overloaded
--- Comment #10 from bangerth at gmail dot com 2010-01-25 18:39 --- This works with gcc 4.3 and 4.4 I don't have mainline lying around here but if it really fails there it would be a 4.5 regression which should get it P1 status. Can someone try? W. -- bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42824
[Bug c++/42768] ICE: libstdc++-v3/libsupc++/vec.cc:354
--- Comment #3 from bangerth at gmail dot com 2010-01-25 18:42 --- Someone on a win64 machine may have to check this. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42768
[Bug middle-end/42863] New: [4.5] Regression whith auto increments
This is a general m68k code generation regression. Starting with revision
150588 GCC for m68k generates "surprising" code for auto increments, eg.
for a strlcpy implementation. Compiling this code with the 4.5.0 snapshot
from 20100107 yields:
-- 4.5.0 --
_strlcpy:
movel d3,s...@-
movel d2,s...@-
movel sp@(16),d0
movel sp@(20),d1
jeq L7
movel d0,a0
movel sp@(12),a1
L3:
movel a0,d2
subql #1,d1
jeq L11
moveb a...@+,d2
moveb d2,a...@+
movel a0,d3 | <--
tstb d2 | <--
jne L3
L4:
subl d3,d0
notl d0
movel s...@+,d2
movel s...@+,d3
rts
L7:
movel d0,d2
movel d2,a0
L6:
moveb a...@+,d1
movel a0,d3 | <--
tstb d1 | <--
jeq L4
moveb a...@+,d1
movel a0,d3 | <--
tstb d1 | <--
jne L6
jra L4
L11:
clrb a1@
movel d2,a0
jra L6
-- cut --
Suddenly GCC inserts "useless" moves and because of these moves has also
to generate explicit tst instructions. Older GCC versions generated better
code by using tst.b incrementing an address register without extra move
instructions, i.e. 4.4.0:
-- 4.4.0 (release) --
_strlcpy:
movel d2,s...@-
movel sp@(8),a1
movel sp@(12),d0
movel sp@(16),d1
jne L2
movel d0,a0
L8:
tstb a...@+
jne L8
L5:
subl a0,d0
notl d0
movel s...@+,d2
rts
L2:
movel d0,a0
subql #1,d1
jeq L11
L6:
moveb a...@+,d2
moveb d2,a1@
jeq L5
addql #1,a1
subql #1,d1
jne L6
L11:
clrb a1@
tstb a...@+
jne L8
jra L5
-- cut --
Environment:
System: FreeBSD 6.3-STABLE #0: Sat Mar 1 11:12:32 CET 2008
r...@sirius:/usr/obj/usr/src/sys/SIRIUS i386
host: i386-unknown-freebsd6.3
build: i386-unknown-freebsd6.3
target: m68k-unknown-amigaos
configured with: ../gcc-4.5-gg/configure --disable-nls --disable-libssp
--enable-languages=c --with-gmp=/usr/local --disable-tls --target=m68k-amigaos
How-To-Repeat:
Compiling the following code with
gcc-4.5.0 -O2 -fomit-frame-pointer strlcpy.c -o -
demonstrates the problem. FWIW, m68k-elf exhibits the very same problem!
-- cut --
typedef unsigned long size_t;
size_t
strlcpy(char *dst, const char *src, size_t n)
{ const char *s = src;
if (n) {
while (--n)
if ((*dst++ = *s++) == '\0')
goto out;
*dst = '\0';
}
while (*s++ != '\0')
continue;
out:
return ~(src - s);
}
-- cut --
--- Comment #1 from gnikl at users dot sourceforge dot net 2010-01-25
19:34 ---
Fix:
Reverting rev 150588 restores the previous behaviour.
--
Summary: [4.5] Regression whith auto increments
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gnikl at users dot sourceforge dot net
GCC build triplet: i386-unknown-freebsd6.3
GCC host triplet: i386-unknown-freebsd6.3
GCC target triplet: m68k-unknown-amigaos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42863
[Bug c++/42824] [4.5 regression] c++ compilation complains about error: call of overloaded
--- Comment #11 from redi at gcc dot gnu dot org 2010-01-25 19:44 --- Confirmed pr42824.cc: In member function void Eval::eval(int_<0>) [with int V = 0, T = Mtrl]: pr42824.cc:42:9: instantiated from void Eval::eval() [with int V = 0, T = Mtrl] pr42824.cc:65:20: instantiated from here pr42824.cc:57:9: error: call of overloaded value(Eval::Wrap >) is ambiguous pr42824.cc:49:10: note: candidates are: void Eval::value(Eval::Wrap >) [with int V = 0, int V2 = 0, T = Mtrl] pr42824.cc:52:10: note: void Eval::value(Eval::Wrap >) [with int V = 0, T = Mtrl] -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to work||4.4.2 Last reconfirmed|-00-00 00:00:00 |2010-01-25 19:44:07 date|| Summary|c++ compilation complains |[4.5 regression] c++ |about error: call of|compilation complains about |overloaded |error: call of overloaded http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42824
[Bug middle-end/42863] [4.5] Regression whith auto increments
--- Comment #2 from schwab at linux-m68k dot org 2010-01-25 19:44 --- m68k-unknown-amigaos is not a valid target. -- schwab at linux-m68k dot org changed: What|Removed |Added GCC build triplet|i386-unknown-freebsd6.3 | GCC host triplet|i386-unknown-freebsd6.3 | GCC target triplet|m68k-unknown-amigaos|m68k-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42863
[Bug debug/42861] [4.4/4.5 Regression] Spill slots not tracked during var-tracking
--- Comment #2 from aoliva at gcc dot gnu dot org 2010-01-25 19:46 --- Mine. Got a patch. -- aoliva at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot |dot org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42861
[Bug c++/42824] [4.5 regression] c++ compilation complains about error: call of overloaded
--- Comment #12 from redi at gcc dot gnu dot org 2010-01-25 19:47 --- CC'ing a release manager -- redi at gcc dot gnu dot org changed: What|Removed |Added CC||jakub at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42824
[Bug c++/42824] [4.5 regression] c++ compilation complains about error: call of overloaded
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42824
[Bug testsuite/42854] [4.4/4.5 Regression] FAIL: gcc.dg/darwin-weakimport-[13].c scan-assembler-not *
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2010-01-25 20:20 --- Mike Stump's comment on Geoff's implementation of the attribute weak_import in FSF gcc is... > Not earth shattering, it just sets .weak_definition or .weak_reference for > the assembler. google can find tidbits about the programming model, how > they are used and the assembler manual and so on... if your curious. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42854
[Bug c++/42864] New: std::String Constructor segfault
$ cat test.cpp
#include
int main()
{
std::string( (unsigned) 2, (unsigned) 'M' );
}
$ gcc -v
Using built-in specs.
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.3-5ubuntu4'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --disable-libssp --disable-sjlj-exceptions
--with-arch=armv5t --with-tune=cortex-a8 --enable-checking=release
--build=arm-linux-gnueabi --host=arm-linux-gnueabi --target=arm-linux-gnueabi
Thread model: posix
gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4)
$ g++ -v -save-temps test.cpp && ./a.out
Using built-in specs.
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.3-5ubuntu4'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --disable-libssp --disable-sjlj-exceptions
--with-arch=armv5t --with-tune=cortex-a8 --enable-checking=release
--build=arm-linux-gnueabi --host=arm-linux-gnueabi --target=arm-linux-gnueabi
Thread model: posix
gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-march=armv5t'
'-mtune=cortex-a8'
/usr/lib/gcc/arm-linux-gnueabi/4.3.3/cc1plus -E -quiet -v -D_GNU_SOURCE
test.cpp -D_FORTIFY_SOURCE=2 -march=armv5t -mtune=cortex-a8 -fpch-preprocess -o
test.ii
ignoring nonexistent directory "/usr/local/include/arm-linux-gnueabi"
ignoring nonexistent directory
"/usr/lib/gcc/arm-linux-gnueabi/4.3.3/../../../../arm-linux-gnueabi/include"
ignoring nonexistent directory "/usr/include/arm-linux-gnueabi"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/4.3
/usr/include/c++/4.3/arm-linux-gnueabi
/usr/include/c++/4.3/backward
/usr/local/include
/usr/lib/gcc/arm-linux-gnueabi/4.3.3/include
/usr/lib/gcc/arm-linux-gnueabi/4.3.3/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-march=armv5t'
'-mtune=cortex-a8'
/usr/lib/gcc/arm-linux-gnueabi/4.3.3/cc1plus -fpreprocessed test.ii -quiet
-dumpbase test.cpp -march=armv5t -mtune=cortex-a8 -auxbase test -version -o
test.s
GNU C++ (Ubuntu 4.3.3-5ubuntu4) version 4.3.3 (arm-linux-gnueabi)
compiled by GNU C version 4.3.3, GMP version 4.2.4, MPFR version 2.4.0.
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64454
Compiler executable checksum: adaaa2547d753dbc1889caf45cfd272e
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-march=armv5t'
'-mtune=cortex-a8'
as -march=armv5t -meabi=4 -o test.o test.s
COMPILER_PATH=/usr/lib/gcc/arm-linux-gnueabi/4.3.3/:/usr/lib/gcc/arm-linux-gnueabi/4.3.3/:/usr/lib/gcc/arm-linux-gnueabi/:/usr/lib/gcc/arm-linux-gnueabi/4.3.3/:/usr/lib/gcc/arm-linux-gnueabi/:/usr/lib/gcc/arm-linux-gnueabi/4.3.3/:/usr/lib/gcc/arm-linux-gnueabi/
LIBRARY_PATH=/usr/lib/gcc/arm-linux-gnueabi/4.3.3/:/usr/lib/gcc/arm-linux-gnueabi/4.3.3/:/usr/lib/gcc/arm-linux-gnueabi/4.3.3/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-march=armv5t'
'-mtune=cortex-a8'
/usr/lib/gcc/arm-linux-gnueabi/4.3.3/collect2 --eh-frame-hdr -dynamic-linker
/lib/ld-linux.so.3 -X -m armelf_linux_eabi -z relro
/usr/lib/gcc/arm-linux-gnueabi/4.3.3/../../../crt1.o
/usr/lib/gcc/arm-linux-gnueabi/4.3.3/../../../crti.o
/usr/lib/gcc/arm-linux-gnueabi/4.3.3/crtbegin.o
-L/usr/lib/gcc/arm-linux-gnueabi/4.3.3 -L/usr/lib/gcc/arm-linux-gnueabi/4.3.3
-L/usr/lib/gcc/arm-linux-gnueabi/4.3.3/../../.. test.o -lstdc++ -lm -lgcc_s
-lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/arm-linux-gnueabi/4.3.3/crtend.o
/usr/lib/gcc/arm-linux-gnueabi/4.3.3/../../../crtn.o
Segmentation fault
--
Summary: std::String Constructor segfault
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kasey dot erickson at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42864
[Bug c++/42864] std::String Constructor segfault
--- Comment #1 from kasey dot erickson at gmail dot com 2010-01-25 20:23 --- Created an attachment (id=19705) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19705&action=view) preprocessed file output from -save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42864
[Bug rtl-optimization/36712] Inefficient loop unrolling
--- Comment #8 from froydnj at gcc dot gnu dot org 2010-01-25 21:10 ---
First, something has gotten better; an arm-eabi gcc (-O2 -std=c99 -mcpu=arm9
-funroll-loops) from 20091209 gives:
Unroll:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
stmfd sp!, {r4, r5, r6, r7, r8}
add r8, r1, #256
.L2:
ldr ip, [r1, #0]
mov r7, r1
mul r2, ip, r0
str r2, [r7], #4
ldr r3, [r1, #4]
ldr r5, [r7, #4]
mul r6, r3, r0
str r6, [r7, #0]
ldr r4, [r1, #12]
ldr ip, [r1, #16]
add r2, r1, #20
ldmia r2, {r2, r3, r7}@ phole ldm
mul r6, r5, r0
mul r5, r4, r0
mul r4, ip, r0
mul ip, r2, r0
mul r2, r3, r0
mul r3, r7, r0
str r6, [r1, #8]
str r5, [r1, #12]
str r4, [r1, #16]
str ip, [r1, #20]
str r2, [r1, #24]
add r1, r1, #32
cmp r1, r8
str r3, [r1, #-4]
bne .L2
ldmfd sp!, {r4, r5, r6, r7, r8}
bx lr
.size Unroll, .-Unroll
.ident "GCC: (GNU) 4.5.0 20091209 (experimental)"
which, if not close to ManualUnroll from the first comment, is much better than
the initial example.
Second, the problem Daniel mentioned concerning auto-inc/dec not doing the
right thing is because of the cleverness of
loop-unroll.c:analyze_iv_to_split_insn. It breaks the code shape that
auto-inc/dec needs. (You can see its effects in the assembly above; the
spurious move to r7 at the top of the loop.) Even if you disable that bit of
RTL loop unrolling, you also need to disable the web pass so as to not really
break the code shape for auto-inc/dec and introduce spurious moves into the
RTL. Once you do that, you get:
Unroll:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
add ip, r1, #256
.L2:
ldr r2, [r1, #0]
mul r3, r2, r0
str r3, [r1], #4
ldr r2, [r1, #0]
mul r3, r2, r0
str r3, [r1], #4
ldr r2, [r1, #0]
mul r3, r2, r0
str r3, [r1], #4
ldr r2, [r1, #0]
mul r3, r2, r0
str r3, [r1], #4
ldr r2, [r1, #0]
mul r3, r2, r0
str r3, [r1], #4
ldr r2, [r1, #0]
mul r3, r2, r0
str r3, [r1], #4
ldr r2, [r1, #0]
mul r3, r2, r0
str r3, [r1], #4
ldr r2, [r1, #0]
mul r3, r2, r0
str r3, [r1], #4
cmp r1, ip
bne .L2
bx lr
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36712
[Bug fortran/42865] New: OpenMP threadprivate allocatable saved variable -> seg fault
For this code:
program F03_2_9_4_1_1a
implicit none
logical :: fail = .false.
call sub1(fail)
if (fail) stop 1
contains
subroutine sub1(fail)
use omp_lib
implicit none
integer, parameter :: NT = 4
logical :: fail
integer :: i
real, allocatable, save :: A(:)
real :: correct_result(NT) ! if (A = correct_result) then test passes
!$omp threadprivate(A)
allocate(A(NT))
call omp_set_num_threads(NT)
call omp_set_dynamic(.false.)
call random_number(correct_result)
A = correct_result
!$omp parallel copyin(A)
! Each thread checks its threadprivate copy of A in a "critical" region to
! attempt to avoid mangling any output.
!$omp critical
do i = 1,NT
! correct_result has "shared" data-sharing attribute by default
if (A(i) /= correct_result(i)) then
print *, 'FAIL: omp_get_thread_num() == ', omp_get_thread_num(), &
' A(', i, ') = ', A(i), '(expected ', correct_result(i), ')'
fail = .true.
end if
end do
!$omp end critical
!$omp end parallel
end subroutine sub1
end program F03_2_9_4_1_1a
>
> gfortran -fopenmp test.f90
> ./a.out
Segmentation fault
>
Information from the OpenMP testers:
! NOTES
! In OpenMP 2.5, ALLOCATABLE arrays were not allowed in a copyin clause.
!
! OpenMP 3.0, p. 102, line 17 states "Each thread's copy of that array must
! be allocated with the same bounds." This seems to imply that the
! programmer must explicitly allocate each thread's copy of the array, but
! p. 101, lines 22-24 states "On entry to any parallel region, each
thread's
! copy of a variable that is affected by a copyin clause for the parallel
! region will acquire the allocation... status of the master thread's copy.
!
! REFERENCES
!OpenMP 3.0, p. 85, lines 12-13 (SAVE attribute needed if not in module
! or main (F08))
!OpenMP 3.0, p. 102, line 17
!OpenMP 3.0, p. 316, lines 18-20
The error appears to be internal to the OpenMP library:
Program terminated with signal 11, Segmentation fault.
#0 0x0044f150 in memcpy ()
(gdb) where
#0 0x0044f150 in memcpy ()
#1 0x0040077e in sub1.1533.omp_fn.0 (.omp_data_i=0x7fffbbc0) at
ISU3230.f90:46
#2 0x0041eea6 in gomp_thread_start (xdata=)
at ../../../xt-gcc-4.4.2/libgomp/team.c:115
#3 0x004163d3 in start_thread ()
#4 0x00454eb9 in clone ()
#5 0x in ?? ()
(gdb) q
The code does execute without error with another compiler.
--
Summary: OpenMP threadprivate allocatable saved variable -> seg
fault
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: longb at cray dot com
GCC build triplet: x86_64-suse-linux
GCC host triplet: x86_64-suse-linux
GCC target triplet: x86_64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42865
[Bug c++/42864] std::String Constructor segfault
--- Comment #2 from redi at gcc dot gnu dot org 2010-01-25 21:29 --- *** This bug has been marked as a duplicate of 42261 *** -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42864
[Bug libstdc++/42261] infinite recursion from string(string::size_type(6), string::size_type('f'))
--- Comment #15 from redi at gcc dot gnu dot org 2010-01-25 21:29 --- *** Bug 42864 has been marked as a duplicate of this bug. *** -- redi at gcc dot gnu dot org changed: What|Removed |Added CC||kasey dot erickson at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42261
[Bug fortran/42866] New: ICE for REDUCTION with ALLOCATABLE array as variable on SECTIONS
For this test case:
program F03_2_9_3_6_2c
! derived from OpenMP test omp3f/F03_2_9_3_6_2c.f90
! REFERENCES
! OpenMP 3.0, p. 100, lines 10-12
! OpenMP 3.0, p. 316, lines 18-22
use omp_lib
implicit none
integer, parameter :: NT = 4
integer :: thread_num1, thread_num2, thread_num3
integer, allocatable :: thread_num_sums(:)
integer :: i
call omp_set_dynamic(.false.)
call omp_set_num_threads(NT)
allocate(thread_num_sums(NT))
thread_num_sums = 0
!$omp parallel
!$omp sections reduction(+:thread_num_sums)
!$omp section
thread_num_sums = omp_get_thread_num()
thread_num1 = omp_get_thread_num()
!$omp section
thread_num_sums = omp_get_thread_num()
thread_num2 = omp_get_thread_num()
!$omp section
thread_num_sums = omp_get_thread_num()
thread_num3 = omp_get_thread_num()
!$omp end sections
!$omp end parallel
do i = 1, NT
if (thread_num_sums(i) /= thread_num1+thread_num2+thread_num3) then
write (*,fmt="('FAIL - thread_num_sums(',i2, ') == ',i10, &
' (expected',i2,')')") &
i, thread_num_sums(i), thread_num1+thread_num2+thread_num3
else
write (*,fmt="('thread',i2,' thread_num_sums(i) = ',i2)") &
i, thread_num_sums(i)
end if
end do
end program F03_2_9_3_6_2c
the compiler aborts:
> gfortran -fopenmp test.f90
test.f90: In function 'f03_2_9_3_6_2c':
test.f90:20: internal compiler error: in single_pred_edge, at basic-block.h:658
Please submit a full bug report,
with preprocessed source if appropriate.
Additional comment from the OpenMP testers:
The GNU gfortran compiler gets an internal error when compiling this
test case when the REDUCTION appears on a SECTIONS.
The OpenMP API version 3 (May 2008) p. 316 lines 18-20 states:
"In Version 3.0, Fortran allocatable arrays may appear in ...
reduction ... clauses."
The API also states on p. 100 line 10-23:
"An original list item with the ALLOCATABLE attribute must be in the
allocated state at entry to the construct containing the reduction clause.
Additionally, the list item must not be deallocated and/or allocated
within the region."
--
Summary: ICE for REDUCTION with ALLOCATABLE array as variable on
SECTIONS
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: longb at cray dot com
GCC build triplet: x86_64-suse-linux
GCC host triplet: x86_64-suse-linux
GCC target triplet: x86_64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42866
[Bug testsuite/42854] [4.4/4.5 Regression] FAIL: gcc.dg/darwin-weakimport-[13].c scan-assembler-not *
--- Comment #5 from dominiq at lps dot ens dot fr 2010-01-25 21:59 --- > Mike Stump's comment on Geoff's implementation of the attribute weak_import in > FSF gcc is... Could you give a pointer? The first test was introduced by this patch http://gcc.gnu.org/ml/gcc-patches/2004-10/msg02441.html and updated by this one http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00146.html The second test was introduce by this patch http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00378.html Note the introduction: > weak_import is more-or-less deprecated on Darwin, by which I mean that > it has a bunch of known bugs but we aren't trying very hard to convince > people to stop using it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42854
[Bug c/42867] New: isfinite macro defined for 4.4.1 but not for 4.3.3
The problem is that the definition of isfinite() macro is not consistent
between version of GCC 4.3.3 and 4.4.1.
Simple test program:
include
#ifdef isfinite
#error isfinite defined
#else
#error isfinite NOT defined
#endif
int main() { return 0; }
1) Test with GCC 4.4.1 (Ubuntu 9.10 x86-64)
mlos...@dog:~/tmp$ gcc --version
gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1
mlos...@dog:~/tmp$ gcc isfinite.c
isfinite.c:3:2: error: #error isfinite defined
mlos...@dog:~/tmp$
2) Test with GCC 4.3.3 (Ubuntu 9.04 x86-32)
mlos...@vb-ubuntu904:~/tmp$ gcc --version
gcc (Ubuntu 4.3.3-5ubuntu4) 4.3.3
mlos...@vb-ubuntu904:~/tmp$ gcc isfinite.c
isfinite.c:5:2: error: #error isfinite NOT defined
In the 2nd case, it seems to be required to use compiler option -std=c99 to
enable the macro:
mlos...@vb-ubuntu904:~/tmp$ gcc -std=c99 isfinite.c
isfinite.c:3:2: error: #error isfinite defined
I think the behaviour of version 4.3.3. is incorrect.
I didn't find any related reports, except the one for C++ use of iostream.h
together with math.h (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14608).
But I am sure it is not related to this report.
--
Summary: isfinite macro defined for 4.4.1 but not for 4.3.3
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mateusz at loskot dot net
GCC host triplet: x86_64-*-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42867
[Bug c/42867] isfinite macro defined for 4.4.1 but not for 4.3.3
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-01-25 22:26 --- isfinite is C99 only. Plus math.h is controlled by libc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42867
[Bug c++/42864] std::String Constructor segfault
--- Comment #3 from paolo dot carlini at oracle dot com 2010-01-25 22:30 --- Boy, this curious way of constructing strings seems rather fancy lately ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42864
[Bug c/42867] isfinite macro defined for 4.4.1 but not for 4.3.3
--- Comment #2 from mateusz at loskot dot net 2010-01-25 22:34 --- (In reply to comment #1) > isfinite is C99 only. Yes, of course it is and I understand it, but I'm trying to understand why the GCC 4.3 and 4.4. behave differently? Does it mean GCC 4.4 makes C99 elements available without explicit request? It looks as such, then it is a bug and GCC 4.3 is correct. > Plus math.h is controlled by libc. Means, I reported to wrong place? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42867
[Bug c/42867] isfinite macro defined for 4.4.1 but not for 4.3.3
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-01-25 22:37 --- It depends. But really you did report it to us rather than Ubuntu first as both are modified versions of GCC. Also you should look to see if they are using the same version of glibc. Because maybe glibc was fixed with newer versions glibc. If that is the case there is nothing we can do really. And this bug is invalid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42867
[Bug middle-end/42694] Compiler could optimize pow (x, 0.75) into sqrt (x) * sqrt (sqrt (x))
--- Comment #3 from meissner at gcc dot gnu dot org 2010-01-26 00:40 --- Created an attachment (id=19706) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19706&action=view) Proposed patch to fix the problem Patch to add 3 new switches to tune whether to use a combination of sqrt/cbrt to replace pow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42694
[Bug target/42868] New: 4.4.3 ICE in change_address_1 on sparc64
The following test case ICEs gcc-4.4.3 on sparc64 when compiled with -fPIC -m64
and any optimization level >= -O1.
> cat cpu_stats.i
extern int end, etext, edata;
long util_print_cpu_stats(void)
{
long vm_text, vm_init_data, vm_uninit_data, vm_sbrk_data;
vm_text = (long) (((long) (&etext)) / 1024.0 + 0.5);
vm_init_data = (long) (((long) (&edata) - (long) (&etext)) / 1024.0 + 0.5);
vm_uninit_data = (long) (((long) (&end) - (long) (&edata)) / 1024.0 + 0.5);
vm_sbrk_data = (long) (((long) sbrk(0) - (long) (&end)) / 1024.0 + 0.5);
return vm_text + vm_init_data + vm_uninit_data + vm_sbrk_data;
}
> sparc64-unknown-linux-gcc -O3 -fPIC -m64 -c cpu_stats.i
cpu_stats.i: In function 'util_print_cpu_stats':
cpu_stats.i:13: internal compiler error: in change_address_1, at
emit-rtl.c:1954
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
> sparc64-unknown-linux-gcc -v
Using built-in specs.
Target: sparc64-unknown-linux
Configured with: /tmp/gcc-4.4.3/configure --target=sparc64-unknown-linux
--with-cpu=ultrasparc --prefix=/home/mikpe/pkgs/linux-x86_64/cross-sparc64
--with-gmp=/home/mikpe/pkgs/linux-x86_64/gmp-4.3.2
--with-mpfr=/home/mikpe/pkgs/linux-x86_64/mpfr-2.4.2 --disable-nls
--disable-shared --disable-libmudflap --disable-multilib --enable-threads=posix
--enable-checking=release --enable-languages=c
Thread model: posix
gcc version 4.4.3 (GCC)
Replacing -m64 with -m32 or dropping -fPIC eliminates the ICE.
4.3.4 and current 4.5.0 do not ICE. For 4.5.0 the ICE was cured by r149082 (the
fix for PR40416), however applying that fix to 4.4.3 does not eliminate the ICE
there.
Above I used a cross hosted on x86, but the ICE also occurs in a native sparc64
build.
The bug was first reported to Debian (#566242). I reduced the test case and did
a reghunt on trunk in the hope finding a backportable fix.
--
Summary: 4.4.3 ICE in change_address_1 on sparc64
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at it dot uu dot se
GCC target triplet: sparc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42868
[Bug target/42868] 4.4.3 ICE in change_address_1 on sparc64
--- Comment #1 from mikpe at it dot uu dot se 2010-01-26 01:36 --- Created an attachment (id=19707) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19707&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42868
[Bug c/42869] New: GOMP_critical_start wrong on Itanium due to __sync miscompilation
The Itanium code for GOMP_start_critical starts 0x20334900 : [MMI] alloc r16=ar.pfs,1,1,0 0x20334901 : addl r32=840,r1 0x20334902 : nop.i 0x0 0x20334910 :[MMI] mf;; 0x20334911 :mov.m ar.ccv=0 0x20334912 :mov r14=1;; 0x20334920 :[MMI] nop.m 0x0 0x20334921 : cmpxchg4.rel r14=[r32],r14,ar.ccv 0x20334922 :nop.i 0x0;; 0x20334930 :[MIB] nop.m 0x0 0x20334931 :cmp.eq p6,p7=0,r14 0x20334932 : (p06) br.ret.dptk.many b0;; Note the mf followed by a cmxchg4.rel. I don't believe this enforces sufficient memory ordering constraints. A subsequent store from inside the critical section may become visible to other threads before the cmpxchg4.rel, which is only intended to prevent reordering in the OTHER direction. Thus a store inside the critical section can become visible before the lock is really acquired, which is, at least theoretically, very bad. I do not know whether current hardware may actually execute these out of order. I observed this while trying to understand the GNU OpenMP support. I also don't know whether this problem is limited to Itanium. I expect it doesn't exist on X86. It may exist onother weakly-ordered architectures. I believe that this is due to incorrect code generated for the __sync_bool_compare_and_swap in gomp_mutex_lock(). -- Summary: GOMP_critical_start wrong on Itanium due to __sync miscompilation Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Hans dot Boehm at hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42869
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #11 from chrbr at gcc dot gnu dot org 2010-01-26 07:20 --- Subject: Bug 42841 Author: chrbr Date: Tue Jan 26 07:20:27 2010 New Revision: 156229 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156229 Log: fix PR target/42841 Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #12 from chrbr at gcc dot gnu dot org 2010-01-26 07:22 --- Subject: Bug 42841 Author: chrbr Date: Tue Jan 26 07:21:57 2010 New Revision: 156230 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156230 Log: fix PR target/42841 Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/sh/sh.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #13 from chrbr at gcc dot gnu dot org 2010-01-26 07:28 --- Subject: Bug 42841 Author: chrbr Date: Tue Jan 26 07:28:05 2010 New Revision: 156231 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156231 Log: fix PR target/42841 Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/sh/sh.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #14 from chrbr at gcc dot gnu dot org 2010-01-26 07:29 --- fixed in 4.5, 4.3 and 4.4 -- chrbr at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42868] [4.4 regression] ICE in change_address_1 at -O -fPIC -mcpu=ultrasparc
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-01-26 07:59 --- It even fails with -m32 for me. Looking into it. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-01-26 07:59:20 date|| Summary|4.4.3 ICE in|[4.4 regression] ICE in |change_address_1 on sparc64 |change_address_1 at -O -fPIC ||-mcpu=ultrasparc Target Milestone|--- |4.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42868
