[Bug c/34710] FORTIFY_SOURCE matches to many patterns
--- Comment #2 from steven at gcc dot gnu dot org 2008-01-08 08:37 --- Let's bring this problem to Jakub's attention... -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34710
[Bug target/34702] [4.3 Regression] 1.0 is not the inverse of 1.0 with -mrecip on x86
--- Comment #1 from ubizjak at gmail dot com 2008-01-08 08:42 --- Hm, I don't see the reason, why this is a regression. What this PR shows is the limitation of the precision of rcpss instruction. Actually, this 2ulp precision is the reason, why -mrecip is not enabled by default for -ffast-math. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34702
[Bug c/34710] FORTIFY_SOURCE matches to many patterns
--- Comment #3 from jakub at gcc dot gnu dot org 2008-01-08 08:46 ---
Just have to agree with Andrew, the code is buggy, fprintf etc. really are
allowed to be defined as macros. That said, glibc 2.7 and later when used with
gcc 4.3 and later uses inline functions instead of macros even for fprintf etc.
With older gccs that's not possible, as it lacks __builtin_va_arg_pack{,_len}
builtins.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34710
[Bug c/34710] FORTIFY_SOURCE matches to many patterns
--- Comment #4 from jakub at gcc dot gnu dot org 2008-01-08 08:49 --- The easiest fix is to use (p.fprintf)(&p, "%i", 123); instead of p.fprintf(&p, "%i", 123); whenever using some identifier which POSIX allows to be defined as function-like macro, BTW. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34710
[Bug fortran/34681] SAVEd derived type with allocatable components causes ICE
--- Comment #2 from burnus at gcc dot gnu dot org 2008-01-08 09:22 --- Patch by Paul: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00269.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34681
[Bug fortran/34704] [4.3 Regression] Derived-type initialization ignored unless save attribute is present
--- Comment #2 from burnus at gcc dot gnu dot org 2008-01-08 09:22 --- Patch by Paul: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00269.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34704
[Bug tree-optimization/34683] [4.3 Regression] Fortran FE generated IL pessimizes middle-end IL and analysis
--- Comment #25 from rguenth at gcc dot gnu dot org 2008-01-08 09:55 --- The unroll problem is that if you have multiple loops like for (i=0; i<3; ++i) a[i] = i; ... for (i=0; i<3; ++i) a[i] = i; then even though we are in loop closed SSA form, we rename all variables in the loop BBs after duplicating them for *every loop* we unroll. Which causes the complexity of renaming to be quadratic (you can easily see that for this testcase the number of SSA_NAMEs allocated by the renamer is quadratic with the number of loops in the testcase). Now what makes it so bad in this testcase is that we mostly deal with virtual operands during renaming. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug tree-optimization/31079] 20% difference between ifort/gfortran, missed vectorization
--- Comment #5 from jv244 at cam dot ac dot uk 2008-01-08 09:52 --- updated the summary after the analysis in comment #4, and and CCed Dorit for the vectorization issue. -- jv244 at cam dot ac dot uk changed: What|Removed |Added CC||dorit at il dot ibm dot com Summary|300% difference between |20% difference between |ifort/gfortran |ifort/gfortran, missed ||vectorization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31079
[Bug tree-optimization/34683] [4.3 Regression] Fortran FE generated IL pessimizes middle-end IL and analysis
--- Comment #24 from rguenth at gcc dot gnu dot org 2008-01-08 09:46 --- The patch in comment #14 reduces compile time from 120s to 80s. I'll try to get it into shape. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug target/34702] [4.3 Regression] 1.0 is not the inverse of 1.0 with -mrecip on x86
--- Comment #2 from dominiq at lps dot ens dot fr 2008-01-08 09:46 --- I don't think either that this is a regression, only a bad side effect. A possibility to overcome it would be to change the way theNewton-Raphson iteration is computed. Presently it seems to be x1=x0*(2.0-x*x0) which is bad when x*x0=nearest(1.0,-1.0) as the result of (2.0-x*x0) is 1.0. I see two ways to improve the accuracy: x1=2.0*x0-(x*x0*x0) and x1=x0+(x0*(1.0-x*x0)) (assuming the parentheses are obeyed). The first case add a multiply, but should not increase the latency if the multiply in 2.0*x0 is inserted between the first and the second multiplies of x*x0*x0. The second case would add the 'add' latency to the original one, but have a better balance between adds and multiplies and is probably the most accurate. Since I am not familiar enough with the x86, I cannot guess precisely what are the other effects of these implementations: extra moves, register pressure, ... . Naively I'll say that the first one would be better in codes having a deficit in multiplies while the second one would be better for long sequence of divisions. If anyone is interested to dig further this issue, I can test patches and timings on a core2duo. Anyway I think something should be said about this "feature" in the manual and there may be some need to have some (better?) "cost model" of replacing a division by "recip+NR" as I read it in a previous post. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34702
[Bug target/34702] [4.3 Regression] 1.0 is not the inverse of 1.0 with -mrecip on x86
--- Comment #3 from dominiq at lps dot ens dot fr 2008-01-08 10:17 --- I just had a look to the doc patch in http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00273.html: ... +Note that while the throughput of the sequence is higher than the throughput +of the non-reciprocal instruction, the precision of the sequence can be +decreased up to 2 ulp. It looks nice, but could you add (after converting my frenglish) something along the line "in particular the inverse of 1.0 is no longer 1.0, but 0.9994" (or nearest(1.0,-1.0) or its C* equivalent). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34702
[Bug fortran/34706] FE should reuse array temporaries, reduce temporaties and tell ME the array-size type
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-08 10:27 --- I have a working patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-01-07 19:59:51 |2008-01-08 10:27:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34706
[Bug tree-optimization/34708] Inlining heuristics issue
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-08 10:26 --- I think we want to account PHI nodes as real copies instead (d->count += PHI_NUM_ARGS (...)) -- if they involve real operands (not VOPs). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34708
[Bug target/34702] 1.0 is not the inverse of 1.0 with -mrecip on x86
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-08 10:17 --- I agree, this is not a regression, but a documentation issue (patch was posted). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords|wrong-code | Last reconfirmed|-00-00 00:00:00 |2008-01-08 10:17:57 date|| Summary|[4.3 Regression] 1.0 is not |1.0 is not the inverse of |the inverse of 1.0 with - |1.0 with -mrecip on x86 |mrecip on x86 | Target Milestone|4.3.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34702
[Bug target/34709] [4.3 regression]: revision 131342 miscompiled 481.wrf on Linux/Intel64
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-08 10:21 --- No idea if Uros has access to spec, so maybe you can quote the snippet where rsqrtss is used from the assembly of 481.wrf? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34709
[Bug fortran/34476] Parameters: Bogus out of bounds error in array constructor
--- Comment #4 from pault at gcc dot gnu dot org 2008-01-08 10:31 --- Created an attachment (id=14898) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14898&action=view) A fix and testcase for this PR This is regtesting right now. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34476
[Bug tree-optimization/34683] [4.3 Regression] Fortran FE generated IL pessimizes middle-end IL and analysis
--- Comment #26 from rguenth at gcc dot gnu dot org 2008-01-08 11:06 --- We do a _lot_ of calls to var_ann during the compilation: Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls s/call s/call name 39.79 30.1230.12 1311048 0.00 0.00 ggc_alloc_stat 12.62 39.67 9.55 34186814 0.00 0.00 add_vars_for_offset 5.77 44.04 4.37 331206978 0.00 0.00 var_ann so var_ann is not inlined despite of it being declared as such. 0.000.00 35522/331206978 add_to_addressable_set [318] 1.580.00 119702754/331206978 add_virtual_operand [12] 2.790.00 211468702/331206978 add_vars_for_offset [17] [39] 5.84.370.00 331206978 var_ann [39] 0.000.00 119615/96446282 htab_find_with_hash [46] So, the add_vars_for_offset loop is resposible for most of the calls (unsurprisingly), and most of the calls are not for global vars. Making sure this call gets inlined brings another 5s of compile-time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug target/34709] [4.3 regression]: revision 131342 miscompiled 481.wrf on Linux/Intel64
--- Comment #2 from ubizjak at gmail dot com 2008-01-08 11:23 ---
(In reply to comment #1)
> No idea if Uros has access to spec, so maybe you can quote the snippet where
> rsqrtss is used from the assembly of 481.wrf?
Unfortunatelly no... does this patch help:
Index: i386.c
===
--- i386.c (revision 131392)
+++ i386.c (working copy)
@@ -21449,7 +21449,7 @@ static tree
ix86_builtin_reciprocal (unsigned int fn, bool md_fn,
bool sqrt ATTRIBUTE_UNUSED)
{
- if (! (TARGET_SSE_MATH && !optimize_size
+ if (! (TARGET_SSE_MATH && TARGET_RECIP && !optimize_size
&& flag_finite_math_only && !flag_trapping_math
&& flag_unsafe_math_optimizations))
return NULL_TREE;
BTW: What happens if -mrecip is used to compile 481.wrf?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34709
[Bug tree-optimization/34683] [4.3 Regression] Fortran FE generated IL pessimizes middle-end IL and analysis
--- Comment #27 from rguenth at gcc dot gnu dot org 2008-01-08 12:13 --- Subject: Bug 34683 Author: rguenth Date: Tue Jan 8 12:12:56 2008 New Revision: 131393 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131393 Log: 2008-01-08 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/34683 * tree-flow-inline.h (var_ann): Remove overzealous asserts. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-flow-inline.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug tree-optimization/34683] [4.3 Regression] Fortran FE generated IL pessimizes middle-end IL and analysis
--- Comment #29 from steven at gcc dot gnu dot org 2008-01-08 12:18 --- Re. comment #26 More proof that assert checking _is_ expensive. I wonder how much compile time can be blamed overall on release checking (i.e. checking disabled vs. release checking). Have you ever compared e.g. build times of cc1-i files or a linux kernel with a non-checking compiler vs. a release-checking compiler? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug tree-optimization/34708] Inlining heuristics issue
--- Comment #5 from hubicka at ucw dot cz 2008-01-08 12:15 --- Subject: Re: Inlining heuristics issue > I think we want to account PHI nodes as real copies instead (d->count += > PHI_NUM_ARGS (...)) -- if they involve real operands (not VOPs). We ignore cost of MODIFY_EXPR in assumption that it will get quite likely optimized out (that is important for simple containers). So ignoring PHI nodes is consistent in this manner, but on the other hand PHIs are less often in containers and more likely to stay after inlining. I will add code for that. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34708
[Bug tree-optimization/34683] [4.3 Regression] Fortran FE generated IL pessimizes middle-end IL and analysis
--- Comment #28 from steven at gcc dot gnu dot org 2008-01-08 12:17 --- Re. comment #26 More proof that assert checking _is_ expensive. I wonder how much compile time can be blamed overall on release checking (i.e. checking disabled vs. release checking). Have you ever compared e.g. build times of cc1-i files or a linux kernel with a non-checking compiler vs. a release-checking compiler? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug tree-optimization/34708] Inlining heuristics issue
--- Comment #6 from rguenther at suse dot de 2008-01-08 12:21 --- Subject: Re: Inlining heuristics issue On Tue, 8 Jan 2008, hubicka at ucw dot cz wrote: > --- Comment #5 from hubicka at ucw dot cz 2008-01-08 12:15 --- > Subject: Re: Inlining heuristics issue > > > I think we want to account PHI nodes as real copies instead (d->count += > > PHI_NUM_ARGS (...)) -- if they involve real operands (not VOPs). > > We ignore cost of MODIFY_EXPR in assumption that it will get quite > likely optimized out (that is important for simple containers). So > ignoring PHI nodes is consistent in this manner, but on the other hand > PHIs are less often in containers and more likely to stay after > inlining. I will add code for that. Well, while register copies are likely to be optimized out, by definition a PHI node copy cannot be optimized out (unless, of course, clever optimization applies). Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34708
[Bug tree-optimization/34708] Inlining heuristics issue
--- Comment #7 from hubicka at ucw dot cz 2008-01-08 12:22 --- Subject: Re: Inlining heuristics issue With some experimentation, the PHI change makes the costs to go up in quite weird ways not taking into account that most of PHIs are elliminated by coalescing. So I will stay with the SWITCH cost * 2 approach. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34708
[Bug fortran/34429] Fails: character(len=use_associated_const) function foo()
--- Comment #1 from pault at gcc dot gnu dot org 2008-01-08 12:57 --- This is fixed in a patch that I am working on that sorts out the whole business of function characteristics in one go. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-12-11 11:09:22 |2008-01-08 12:57:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34429
[Bug debug/26364] [4.0/4.1/4.2/4.3 regression] [no unit-at-a-time mode] Uninlined function is marked as inlined
--- Comment #11 from steven at gcc dot gnu dot org 2008-01-08 12:53 --- Created an attachment (id=14899) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14899&action=view) Reject combination of -fno-unit-at-a-time and -finline-functions-called-once Untested, but shows how easy it should be to "fix" this bug by disallowing this strange combination of flags. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26364
[Bug tree-optimization/34683] [4.3 Regression] Fortran FE generated IL pessimizes middle-end IL and analysis
--- Comment #30 from rguenth at gcc dot gnu dot org 2008-01-08 12:30
---
No, I didn't. But yes, overzealous asserts in the simple inline accessor
functions are probably counter-productive. For example things like
static inline bool
gimple_aliases_computed_p (const struct function *fun)
{
gcc_assert (fun && fun->gimple_df);
return fun->gimple_df->aliases_computed_p;
}
would segfault anyway if fun or fun->gimple_df would be NULL. Or
static inline function_ann_t
function_ann (const_tree t)
{
gcc_assert (t);
gcc_assert (TREE_CODE (t) == FUNCTION_DECL);
gcc_assert (!t->base.ann
|| t->base.ann->common.type == FUNCTION_ANN);
return (function_ann_t) t->base.ann;
}
multiple asserts generate multiple diagnostic calls. Now, both of these
functions are not in hot code-paths.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug tree-optimization/33237] [4.3 Regression] Tree memory partitioning is spending 430 seconds of a 490 second compile.
--- Comment #5 from steven at gcc dot gnu dot org 2008-01-08 12:40 --- Would be nice if someone could analyze this, or at least reconfirm that the problem still exists. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33237
[Bug tree-optimization/34683] [4.3 Regression] Fortran FE generated IL pessimizes middle-end IL and analysis
--- Comment #31 from rguenth at gcc dot gnu dot org 2008-01-08 12:55
---
Another hot assert is
static inline tree
memory_partition (tree sym)
{
tree tag;
/* MPTs belong to their own partition. */
if (TREE_CODE (sym) == MEMORY_PARTITION_TAG)
return sym;
gcc_assert (!is_gimple_reg (sym));
and is_gimple_reg isn't cheap either. For this testcase two thirds of
the calls are attributed to add_vars_for_offset (through add_v{use,def}):
0.500.01 135234172/199610365 add_vars_for_offset [27]
[114]1.10.740.01 199610365 is_gimple_reg [114]
and it really isn't cheap:
CPU: AMD64 processors, speed 2000 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask
of 0x00 (No unit mask) count 10
samples %symbol name
545326 36.8318 ggc_alloc_stat
310838 20.9943 add_vars_for_offset
85655 5.7852 add_virtual_operand
69156 4.6709 finalize_ssa_stmt_operands
57057 3.8537 bitmap_set_bit
36755 2.4825 htab_find_with_hash
35915 2.4257 get_expr_operands
28207 1.9051 is_gimple_reg
23340 1.5764 referenced_var_lookup
wrapping the assert inside ENABLE_CHECKING buys us 2s or 2.5%. But this
is too much micro-optimizing for me ;)
I'd rather have the quadratic SSA rewriting in the unroller fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug fortran/34431] type(t) function with imported/use-associated "t" fails
--- Comment #2 from pault at gcc dot gnu dot org 2008-01-08 12:57 --- This is fixed in a patch that I am working on that sorts out the whole business of function characteristics in one go. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-12-11 12:20:12 |2008-01-08 12:57:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34431
[Bug fortran/34471] Wrong precedence of kinds in typespecs.
--- Comment #1 from pault at gcc dot gnu dot org 2008-01-08 12:58 --- This is fixed in a patch that I am working on that sorts out the whole business of function characteristics in one go. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-12-15 08:15:05 |2008-01-08 12:58:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34471
[Bug tree-optimization/34708] Inlining heuristics issue
--- Comment #9 from amacleod at redhat dot com 2008-01-08 13:27 --- yes, many PHIs are eliminated by coalescing. If you wanted to experiment at some point for more accuracy, you can look at the PHI arguments. Any argument which has a different base name than the LHS of the PHI, or is a constant, *will* be a copy if the PHI remains. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34708
[Bug tree-optimization/34683] [4.3 Regression] Fortran FE generated IL pessimizes middle-end IL and analysis
--- Comment #32 from steven at gcc dot gnu dot org 2008-01-08 13:08 --- You are of course right that for this test case the bigger win is in the algorithmic issues. On the other hand, for compile time in general, the gcc_asserts are IMHO the worst thing that happened to GCC since the introduction of the garbage allocator ;-) It is way too easy to write "gcc_assert (blah)" instead of "if (blah)\nabort ();", and people don't realize how expensive these "cheap" asserts are. This would then be a nice project for the Wiki beginners projects pages, perhaps: Audit the gcc_assert calls in small "inline" functions and see if there is any measurable gain to win from removing some that don't make sense (like e.g. the ones you identified in comment #30). But that's not relevant for this bug report, of course :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug tree-optimization/34708] Inlining heuristics issue
--- Comment #8 from jakub at gcc dot gnu dot org 2008-01-08 13:02 --- Created an attachment (id=14900) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14900&action=view) openbabel_perl.ii.bz2 Here is the original testcase, compile on ppc64-linux or with -> ppc64-linux cross, with -O2 -m64 -fPIC -mminimal-toc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34708
[Bug tree-optimization/33237] [4.3 Regression] Tree memory partitioning is spending 430 seconds of a 490 second compile.
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-08 13:35 --- Reconfirmed. Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls s/call s/call name 23.89 41.6141.61 445943529 0.00 0.00 pointer_map_insert 19.66 75.8534.24 445862120 0.00 0.00 get_mem_sym_stats_for 18.62108.2732.42 446338551 0.00 0.00 uid_decl_map_eq 8.17122.5014.233 4.7449.51 compute_memory_partitions 7.60135.7413.24 457347593 0.00 0.00 bitmap_set_bit 5.71145.69 9.95 449120494 0.00 0.00 htab_find_with_hash 1.98149.14 3.45 446137605 0.00 0.00 referenced_var_lookup 0.56150.11 0.97 2946899 0.00 0.00 pointer_set_insert 0.51151.00 0.89 346720 0.00 0.00 bitmap_and_into 0.48151.84 0.84 2068490 0.00 0.00 bitmap_ior_into 0.46152.64 0.80 42298017 0.00 0.00 bitmap_elt_insert_after 0.39153.32 0.69 137584 0.00 0.00 gimple_default_def 41.600.00 445862120/445943529 get_mem_sym_stats_for [10] [20]23.9 41.610.00 445943529 pointer_map_insert [20] 34.24 41.60 445804196/445862120 compute_memory_partitions [ 7] [10]43.6 34.24 41.60 445862120 get_mem_sym_stats_for [10] and there I at some point analyzed it to the quadratic loop in update_reference_counts. This is really Diegos bug. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2007-11-01 15:38:16 |2008-01-08 13:35:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33237
[Bug fortran/33375] ICE (segfault) gfortran.dg/common_6.f90
--- Comment #11 from hjl at lucon dot org 2008-01-08 13:56 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00294.html -- hjl at lucon dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||01/msg00294.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33375
[Bug target/34702] 1.0 is not the inverse of 1.0 with -mrecip on x86
--- Comment #5 from uros at gcc dot gnu dot org 2008-01-08 13:51 --- Subject: Bug 34702 Author: uros Date: Tue Jan 8 13:50:14 2008 New Revision: 131394 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131394 Log: PR target/34702 * doc/invoke.texi (i386 and x86-64 Options) [mrecip]: Document limitations of reciprocal sequences on x86 targets. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34702
[Bug tree-optimization/34708] Inlining heuristics issue
--- Comment #10 from hubicka at ucw dot cz 2008-01-08 14:14 --- Subject: Re: Inlining heuristics issue > yes, many PHIs are eliminated by coalescing. If you wanted to experiment at > some point for more accuracy, you can look at the PHI arguments. Any argument > which has a different base name than the LHS of the PHI, or is a constant, > *will* be a copy if the PHI remains. Hmm, good point, figuring out PHI arguemnts with constant or different bases is easy. Still we for reason don't account constants nor copy instructions in attempt to guess what will remain important after optimization and I am not sure we want to make PHIs an exception. This function is typical example that has chance to optimize well after inlining, so the decision is not that unreasonable. I guess for now I will stay with the simple SWITCH statement cost estimate (we don't want to copy too giant SWITCH and we don't want to overestimate very simple SWITChes as we do now) and play with this more with my patch that separate speed and size estiamtes for inliner I have in queue for next stage1. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34708
[Bug target/34702] 1.0 is not the inverse of 1.0 with -mrecip on x86
--- Comment #6 from ubizjak at gmail dot com 2008-01-08 14:02 ---
(In reply to comment #3)
> It looks nice, but could you add (after converting my frenglish) something
> along the line "in particular the inverse of 1.0 is no longer 1.0, but
> 0.9994" (or nearest(1.0,-1.0) or its C* equivalent).
I have added a small example you provided to the text:
--cut here--
... are generated only when @option{-funsafe-math-optimizations} is enabled
together with @option{-finite-math-only} and @option{-fno-trapping-math}.
Note that while the throughput of the sequence is higher than the throughput
of the non-reciprocal instruction, the precision of the sequence can be
decreased up to 2 ulp (i.e. the inverse of 1.0 equals 0.9994).
--cut here--
The point of -mrecip is to create the sequence with the fastest throughput
possible on the expense of the precision. Please note, that we operate on
SFmode here, so precision should be of no concern. While plain rcpss & friends
are not precise enough to be even remotely usable (and they can be accessed
using builtins anyway), the NR enhanced reciprocals provide adequate precision
with great speedup. However, it looks that none of them are good enough for
plain -ffast-math, mainly due to direct comparisons of FP values as in exmple
you provided.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34702
[Bug target/34702] 1.0 is not the inverse of 1.0 with -mrecip on x86
--- Comment #7 from dominiq at lps dot ens dot fr 2008-01-08 14:20 --- > the NR enhanced reciprocals provide adequate precision with great speedup Two quick remarks along this line: (1) On Core2Duo the speedup is not obvious for the polyhedron testsuite, excepted for gas_dyn 7.7s vs. 8.5s (also capacita 59.6s vs. 57s). (2) ifort seems to make an extensive use of this optimization (gas_dyn 4.1s), in general with "packed" code, but seems to use 'div' also in other places. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34702
[Bug tree-optimization/33237] [4.3 Regression] Tree memory partitioning is spending 430 seconds of a 490 second compile.
--- Comment #7 from dnovillo at gcc dot gnu dot org 2008-01-08 14:24 --- Will work on this. -- dnovillo at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot |dot org |org Status|WAITING |ASSIGNED Last reconfirmed|2008-01-08 13:35:38 |2008-01-08 14:24:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33237
[Bug fortran/34714] New: ICE-on-invalid in gfc_conv_descriptor_dtype
Current trunk (as well as the whole 4.2 branch, it seems), ICEs on the
following invalid code:
module foo
type bar
logical, pointer, dimension(:) :: baz
end type
contains
function func1()
type(bar) func1
allocate(func1%baz(1))
end function
function func2()
type(bar) func2
allocate(func1%baz(1))
end function
end module foo
~/tmp>gfortran -v bug.f90
Driving: gfortran -v bug.f90 -lgfortranbegin -lgfortran -lm -shared-libgcc
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /scratch/martin/gcc/configure
--prefix=/afs/mpa/data/martin/ugcc --with-mpfr-include=/usr/include
--with-mpfr-lib=/usr/lib --enable-languages=c++,fortran
--enable-checking=release
Thread model: posix
gcc version 4.3.0 20080108 (experimental) [trunk revision 131394] (GCC)
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic'
/afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/4.3.0/f951 bug.f90
-quiet -dumpbase bug.f90 -mtune=generic -auxbase bug -version
-fintrinsic-modules-path
/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.3.0/finclude -o
/tmp/ccOrwEru.s
GNU F95 (GCC) version 4.3.0 20080108 (experimental) [trunk revision 131394]
(i686-pc-linux-gnu)
compiled by GNU C version 4.3.0 20080108 (experimental) [trunk revision
131394], GMP version 4.2.1, MPFR version 2.3.0.
warning: GMP header version 4.2.1 differs from library version 4.2.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
bug.f90: In function 'func2':
bug.f90:8: internal compiler error: in gfc_conv_descriptor_dtype, at
fortran/trans-array.c:224
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
--
Summary: ICE-on-invalid in gfc_conv_descriptor_dtype
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martin at mpa-garching dot mpg dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34714
[Bug fortran/34681] SAVEd derived type with allocatable components causes ICE
--- Comment #3 from pault at gcc dot gnu dot org 2008-01-08 15:13 --- Subject: Bug 34681 Author: pault Date: Tue Jan 8 15:12:34 2008 New Revision: 131395 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131395 Log: 2008-01-08 Paul Thomas <[EMAIL PROTECTED]> PR fortran/34681 * trans_array.c (gfc_trans_deferred_array): Do not null the data pointer on entering scope, nor deallocate it on leaving scope, if the symbol has the 'save' attribute. PR fortran/34704 * trans_decl.c (gfc_finish_var_decl): Derived types with allocatable components and an initializer must be TREE_STATIC. 2008-01-08 Paul Thomas <[EMAIL PROTECTED]> PR fortran/34681 PR fortran/34704 * gfortran.dg/alloc_comp_default_init_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/alloc_comp_default_init_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34681
[Bug fortran/34704] [4.3 Regression] Derived-type initialization ignored unless save attribute is present
--- Comment #3 from pault at gcc dot gnu dot org 2008-01-08 15:13 --- Subject: Bug 34704 Author: pault Date: Tue Jan 8 15:12:34 2008 New Revision: 131395 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131395 Log: 2008-01-08 Paul Thomas <[EMAIL PROTECTED]> PR fortran/34681 * trans_array.c (gfc_trans_deferred_array): Do not null the data pointer on entering scope, nor deallocate it on leaving scope, if the symbol has the 'save' attribute. PR fortran/34704 * trans_decl.c (gfc_finish_var_decl): Derived types with allocatable components and an initializer must be TREE_STATIC. 2008-01-08 Paul Thomas <[EMAIL PROTECTED]> PR fortran/34681 PR fortran/34704 * gfortran.dg/alloc_comp_default_init_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/alloc_comp_default_init_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34704
[Bug fortran/34476] Parameters: Bogus out of bounds error in array constructor
--- Comment #5 from pault at gcc dot gnu dot org 2008-01-08 15:15 --- Subject: Bug 34476 Author: pault Date: Tue Jan 8 15:14:33 2008 New Revision: 131396 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131396 Log: 2008-01-08 Paul Thomas <[EMAIL PROTECTED]> PR fortran/34476 * expr.c (find_array_element): Check that the array bounds are constant before using them. Use lower, as well as upper bound. (check_restricted): Allow implied index variable. 2008-01-08 Paul Thomas <[EMAIL PROTECTED]> PR fortran/34476 * gfortran.dg/parameter_array_init_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/parameter_array_init_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34476
[Bug fortran/34704] [4.3 Regression] Derived-type initialization ignored unless save attribute is present
--- Comment #4 from pault at gcc dot gnu dot org 2008-01-08 15:15 --- Fixed on trunk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34704
[Bug fortran/34681] SAVEd derived type with allocatable components causes ICE
--- Comment #4 from pault at gcc dot gnu dot org 2008-01-08 15:16 --- Fixed on trunk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34681
[Bug fortran/34476] Parameters: Bogus out of bounds error in array constructor
--- Comment #6 from pault at gcc dot gnu dot org 2008-01-08 15:16 --- Fixed on trunk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34476
[Bug middle-end/28690] [4.2/4.3 Regression] Performace problem with indexed load/stores on powerpc
--- Comment #45 from bergner at gcc dot gnu dot org 2008-01-08 15:44 --- This has been fixed in mainline (4.3), but has not been fixed in 4.2. I'm ok with not back porting this to 4.2. I'll give everyone a few days to object, otherwise I'll change the Target Milestone to 4.3 and close as FIXED. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #30 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-08 15:51 --- Subject: Re: wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605 > Subject: Re: wo_prof_two_strs.c:56: internal compiler > error: in find_new_var_of_type, at ipa-struct-reorg.c:605 > > > Would you please try the Alon's patch for PR 34701. > > I did but the reported failures are still there. Too bad!-( Same on hppa2.0w-hp-hpux11.11. It doesn't help with the malloc related fails. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug c++/29469] [DR 224] [4.1/4.2/4.3 Regression] error: non-template 'pair' used as template
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-08 16:16:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29469
[Bug c++/29469] [DR 224] [4.1/4.2/4.3 Regression] error: non-template 'pair' used as template
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29469
[Bug c++/29607] [DR 224] [4.1/4.2/4.3 Regression] dependent name with base classes
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-08 16:17:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29607
[Bug gcov-profile/34610] [4.3 regression] ICE with "-fprofile-arcs -fopenmp"
--- Comment #7 from steven at gcc dot gnu dot org 2008-01-08 16:26 --- This is marked as a regression -- but from what? Did this work in GCC 4.2? -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.3.0 Last reconfirmed|-00-00 00:00:00 |2008-01-08 16:26:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34610
[Bug tree-optimization/30194] [4.3 Regression] alias set partitioning dependent on SFT DECL_UIDs
--- Comment #16 from steven at gcc dot gnu dot org 2008-01-08 16:20 --- Diego, Is this something you plan to work on for GCC 4.3? Does this still qualify as a "4.3 regression"? -- steven at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3 Regression]|[4.3 Regression] alias set |gcc.dg/pr19633-1.c fails on |partitioning dependent on |the mainline|SFT DECL_UIDs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30194
[Bug c++/29607] [DR 224] [4.1/4.2/4.3 Regression] dependent name with base classes
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29607
[Bug middle-end/34694] [4.3 regression] Wrong line number for uninitialized variable
--- Comment #2 from jakub at gcc dot gnu dot org 2008-01-08 16:11 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34694
[Bug c++/33890] [4.3 regression] ICE in tsubst_copy with OpenMP
--- Comment #5 from jakub at gcc dot gnu dot org 2008-01-08 16:11 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33890
[Bug middle-end/34694] [4.3 regression] Wrong line number for uninitialized variable
--- Comment #1 from jakub at gcc dot gnu dot org 2008-01-08 16:09 --- Subject: Bug 34694 Author: jakub Date: Tue Jan 8 16:08:24 2008 New Revision: 131398 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131398 Log: PR middle-end/34694 * omp-low.c (copy_var_decl): Copy also DECL_SOURCE_LOCATION. * gcc.dg/gomp/pr34694.c: New test. * g++.dg/gomp/pr34694.C: New test. Added: trunk/gcc/testsuite/g++.dg/gomp/pr34694.C trunk/gcc/testsuite/gcc.dg/gomp/pr34694.c Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34694
[Bug middle-end/28690] [4.2 Regression] Performace problem with indexed load/stores on powerpc
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Last reconfirmed|2006-08-11 13:29:43 |2008-01-08 15:59:22 date|| Summary|[4.2/4.3 Regression]|[4.2 Regression] Performace |Performace problem with |problem with indexed |indexed load/stores on |load/stores on powerpc |powerpc | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
[Bug c++/33890] [4.3 regression] ICE in tsubst_copy with OpenMP
--- Comment #4 from jakub at gcc dot gnu dot org 2008-01-08 16:07 --- Subject: Bug 33890 Author: jakub Date: Tue Jan 8 16:06:31 2008 New Revision: 131397 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131397 Log: PR c++/33890 * semantics.c (finish_omp_for): Don't call fold_build_cleanup_point_expr if processing_template_decl. * g++.dg/gomp/pr33890.C: New test. Added: trunk/gcc/testsuite/g++.dg/gomp/pr33890.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33890
[Bug rtl-optimization/31944] [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit 2.6.20 kernel
--- Comment #17 from steven at gcc dot gnu dot org 2008-01-08 16:14 --- Does anyone know how to reproduce this with a cross-compiler? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944
[Bug tree-optimization/30194] [4.3 Regression] alias set partitioning dependent on SFT DECL_UIDs
--- Comment #17 from dnovillo at google dot com 2008-01-08 16:23 --- Subject: Re: [4.3 Regression] alias set partitioning dependent on SFT DECL_UIDs On 8 Jan 2008 16:20:39 -, steven at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > Diego, > Is this something you plan to work on for GCC 4.3? I will do my best. > Does this still qualify as a "4.3 regression"? If it can't be reproduced with earlier versions, yes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30194
[Bug tree-optimization/33763] [4.1/4.2/4.3 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-01-08 16:49 --- I would suggest to go with the patch in comment #3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33763
[Bug rtl-optimization/31944] [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit 2.6.20 kernel
--- Comment #18 from rguenth at gcc dot gnu dot org 2008-01-08 16:29 --- The testcase reproduces for me on a x86_64 -> hppa64-linux cross on trunk with -O2 -fno-inline-small-functions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944
[Bug c++/34606] [4.3 regression] ICE with invalid specialization of variadic template
--- Comment #1 from steven at gcc dot gnu dot org 2008-01-08 17:08 --- *** This bug has been marked as a duplicate of 34314 *** -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34606
[Bug c++/34314] [4.3 Regression] ICE on invalid code (with variadic templates): tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in template_class_depth
--- Comment #2 from steven at gcc dot gnu dot org 2008-01-08 17:08 --- *** Bug 34606 has been marked as a duplicate of this bug. *** -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||reichelt at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34314
[Bug tree-optimization/30194] [4.3 Regression] alias set partitioning dependent on SFT DECL_UIDs
--- Comment #18 from rguenth at gcc dot gnu dot org 2008-01-08 16:40 --- I don't think anything is wrong with 'alias set partitioning dependent on SFT DECL_UIDs'. If two SFTs score equal we need to discriminate them somehow. DECL_UID is exactly the right thing to use for this. Note that 2007-10-25 Richard Guenther <[EMAIL PROTECTED]> ... * tree-ssa-alias.c (mem_sym_stats): ... here and make it static. ... (compare_mp_info_entries): Make sort stable by disambiguating on DECL_UID. might have improved the situation. Or worsened it. The question would be - why should the DECL_UIDs for SFTs change spontaneously? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30194
[Bug c++/31863] [4.1/4.2/4.3 Regression] g++-4.1: out of memory with -O1/-O2
--- Comment #20 from steven at gcc dot gnu dot org 2008-01-08 16:36 --- So this bug was worked around -- but can this be fixed properly for GCC 4.3? Richi, is this just another example of the SFT problems reported in other PRs? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31863
[Bug gcov-profile/34610] [4.3 regression] ICE with "-fprofile-arcs -fopenmp"
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-01-08 16:45 --- Yes, this doesn't ICE for me for 4.2. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34610
[Bug c++/31863] [4.1/4.2/4.3 Regression] g++-4.1: out of memory with -O1/-O2
--- Comment #21 from rguenth at gcc dot gnu dot org 2008-01-08 16:54 --- Well, the many SFTs don't help the situation for sure. But we can't do anything for 4.3 here, as only after walking all the fields in push_fields_to_fieldstack we figure out we better not generate SFTs here. Which is too late. But yes, I suppose I can simply early exit from that function now that we always punt if the number of fields is too large. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-05-08 15:47:11 |2008-01-08 16:54:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31863
[Bug tree-optimization/34683] [4.3 Regression] Fortran FE generated IL pessimizes middle-end IL and analysis
--- Comment #33 from rguenth at gcc dot gnu dot org 2008-01-08 16:29 --- Subject: Bug 34683 Author: rguenth Date: Tue Jan 8 16:29:14 2008 New Revision: 131400 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131400 Log: 2008-01-08 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/34683 * tree-ssa-operands.c (operand_build_cmp): Export. * tree-ssa-operands.h (operand_build_cmp): Declare. * tree-vn.c (vuses_compare): Remove. (sort_vuses): Use operand_build_cmp. (sort_vuses_heap): Likewise. * tree-ssa-sccvn.c (vuses_to_vec): Use VEC_reserve, not VEC_alloc to re-use old VEC if available. Do not sort already sorted VUSEs. (vdefs_to_vec): Do not sort already sorted VDEFs. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-operands.c trunk/gcc/tree-ssa-operands.h trunk/gcc/tree-ssa-sccvn.c trunk/gcc/tree-vn.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug tree-optimization/30194] [4.3 Regression] alias set partitioning dependent on SFT DECL_UIDs
--- Comment #20 from rguenth at gcc dot gnu dot org 2008-01-08 17:18 --- Lets just close this as fixed then, as the problem went away. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30194
[Bug tree-optimization/30194] [4.3 Regression] alias set partitioning dependent on SFT DECL_UIDs
--- Comment #21 from steven at gcc dot gnu dot org 2008-01-08 17:21 --- OK. I was asking because of the final remark in comment #11. Let's close this as fixed because the test suite failure is gone and it's unclear what's left to work on. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30194
[Bug other/34592] useless computation found
--- Comment #6 from manu at gcc dot gnu dot org 2008-01-08 17:26 --- (In reply to comment #3) > > I also counted about 300 similar cases where Intel > produced warning #593. I think there is quite a bit > of pointless computation going on. > Thanks. I think optimisers should remove all of them so they should not have any effect. Nonetheless, if they are not really used, they should be removed from the code. > I attach a patch again 4.3 snapshot 20071228. Unfortunately, GCC 4.3 is open only for regression and documentation fixes. Your patch would need to wait for GCC 4.4. Yet, you can submit it right now and there are chances that someone will review. To avoid conflicts between maintainer of different parts of the compiler, I would suggest one different submission per component (or if you cannot distinguish the components, one submission per file). > Hint: Perhaps if this patch gets into 4.3 it would encourage > me to look at the other 300 cases ? Patches must be bootstrapped+regression tested and sent to gcc-patches. Check http://gcc.gnu.org/contribute.html for further instructions. If you need help with a particular step, write me an email. Examples of submissions can be found in the archives of gcc-patches. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34592
[Bug tree-optimization/33763] [4.1/4.2/4.3 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining
--- Comment #7 from rguenther at suse dot de 2008-01-08 17:27 --- Subject: Re: [4.1/4.2/4.3 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining On Tue, 8 Jan 2008, jakub at gcc dot gnu dot org wrote: > --- Comment #6 from jakub at gcc dot gnu dot org 2008-01-08 17:25 --- > So do I and even am using that patch for quite some time in our gcc packages. So do I. > But Mark objected to that: > http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00589.html > The current state of things is bad, because with glibc 2.7+ several valid > programs don't compile. And this late in stage3 is probably dangerous to play > with two different bodies in cgraph. Right, this is something for stage1. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33763
[Bug web/34630] testing email to gcc-bugs
--- Comment #2 from manu at gcc dot gnu dot org 2008-01-08 17:13 --- It works. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34630
[Bug tree-optimization/33763] [4.1/4.2/4.3 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining
--- Comment #6 from jakub at gcc dot gnu dot org 2008-01-08 17:25 --- So do I and even am using that patch for quite some time in our gcc packages. But Mark objected to that: http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00589.html The current state of things is bad, because with glibc 2.7+ several valid programs don't compile. And this late in stage3 is probably dangerous to play with two different bodies in cgraph. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33763
[Bug tree-optimization/30194] [4.3 Regression] alias set partitioning dependent on SFT DECL_UIDs
--- Comment #19 from dnovillo at google dot com 2008-01-08 17:06 --- Subject: Re: [4.3 Regression] alias set partitioning dependent on SFT DECL_UIDs > I don't think anything is wrong with 'alias set partitioning dependent on SFT > DECL_UIDs'. If two SFTs score equal we need to discriminate them somehow. > DECL_UID is exactly the right thing to use for this. > > Note that > > 2007-10-25 Richard Guenther <[EMAIL PROTECTED]> > > ... > * tree-ssa-alias.c (mem_sym_stats): ... here and make it static. > ... > (compare_mp_info_entries): Make sort stable by disambiguating > on DECL_UID. > > might have improved the situation. Or worsened it. > > The question would be - why should the DECL_UIDs for SFTs change > spontaneously? Bother. I thought I was replying to a different PR (33237). No, I don't think I'll work on this PR. I agree with Richard's assessment. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30194
[Bug c++/34687] my gcc wont compile
--- Comment #3 from manu at gcc dot gnu dot org 2008-01-08 17:08 --- Waiting for feedback. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34687
[Bug middle-end/31309] 6 byte assignment at end of structure reads/writes past end of structure causing SEGV when that memory is not accessable.
--- Comment #17 from ebotcazou at gcc dot gnu dot org 2008-01-08 17:10
---
Michael, any reason for being so scrupulous and not forcing the mode?
Index: expr.c
===
--- expr.c (revision 131326)
+++ expr.c (working copy)
@@ -2061,6 +2061,7 @@ copy_blkmode_from_reg (rtx tgtblk, rtx s
rtx src = NULL, dst = NULL;
unsigned HOST_WIDE_INT bitsize = MIN (TYPE_ALIGN (type), BITS_PER_WORD);
unsigned HOST_WIDE_INT bitpos, xbitpos, padding_correction = 0;
+ enum machine_mode copy_mode;
if (tgtblk == 0)
{
@@ -2094,11 +2095,19 @@ copy_blkmode_from_reg (rtx tgtblk, rtx s
padding_correction
= (BITS_PER_WORD - ((bytes % UNITS_PER_WORD) * BITS_PER_UNIT));
- /* Copy the structure BITSIZE bites at a time.
+ /* Copy the structure BITSIZE bits at a time. If the target lives in
+ memory, take care of not reading/writing past its end by selecting
+ a copy mode suited to BITSIZE. This should always be possible given
+ how it is computed.
We could probably emit more efficient code for machines which do not use
strict alignment, but it doesn't seem worth the effort at the current
time. */
+
+ if (!MEM_P (tgtblk)
+ || ((copy_mode = mode_for_size (bitsize, MODE_INT, 1)) == BLKmode))
+copy_mode = word_mode;
+
for (bitpos = 0, xbitpos = padding_correction;
bitpos < bytes * BITS_PER_UNIT;
bitpos += bitsize, xbitpos += bitsize)
@@ -2117,11 +2126,11 @@ copy_blkmode_from_reg (rtx tgtblk, rtx s
dst = operand_subword (tgtblk, bitpos / BITS_PER_WORD, 1, BLKmode);
/* Use xbitpos for the source extraction (right justified) and
-xbitpos for the destination store (left justified). */
- store_bit_field (dst, bitsize, bitpos % BITS_PER_WORD, word_mode,
+bitpos for the destination store (left justified). */
+ store_bit_field (dst, bitsize, bitpos % BITS_PER_WORD, copy_mode,
extract_bit_field (src, bitsize,
xbitpos % BITS_PER_WORD, 1,
- NULL_RTX, word_mode, word_mode));
+ NULL_RTX, copy_mode, copy_mode));
}
return tgtblk;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31309
[Bug c/31348] Error in compilation
--- Comment #4 from manu at gcc dot gnu dot org 2008-01-08 17:46 --- Waiting for feedback. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31348
[Bug other/31359] 4.2 branch still generates abort for function casting
--- Comment #6 from manu at gcc dot gnu dot org 2008-01-08 17:55 --- I think the consensus is clear on what needs to be done. So this is confirmed. Just needs someone to do it. Unfortunately, given the huge amount of open issues, I would guess that making undefined code work is quite down the list. Thus, patches are welcome: http://gcc.gnu.org/contribute.html -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-08 17:55:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31359
[Bug middle-end/25547] 3 * dead data in compiler source code
--- Comment #4 from manu at gcc dot gnu dot org 2008-01-08 17:30 --- (In reply to comment #3) > Most of them will be fixed by: > http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00447.html > > I still have to decide if we want to remove ggc_stats or not. > As far as I can see this patch was never reviewed or committed. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25547
[Bug target/34709] [4.3 regression]: revision 131342 miscompiled 481.wrf on Linux/Intel64
--- Comment #3 from hjl at lucon dot org 2008-01-08 18:01 ---
(In reply to comment #2)
> (In reply to comment #1)
> > No idea if Uros has access to spec, so maybe you can quote the snippet where
> > rsqrtss is used from the assembly of 481.wrf?
>
> Unfortunatelly no... does this patch help:
>
> Index: i386.c
> ===
> --- i386.c (revision 131392)
> +++ i386.c (working copy)
> @@ -21449,7 +21449,7 @@ static tree
> ix86_builtin_reciprocal (unsigned int fn, bool md_fn,
> bool sqrt ATTRIBUTE_UNUSED)
> {
> - if (! (TARGET_SSE_MATH && !optimize_size
> + if (! (TARGET_SSE_MATH && TARGET_RECIP && !optimize_size
> && flag_finite_math_only && !flag_trapping_math
> && flag_unsafe_math_optimizations))
> return NULL_TREE;
It works.
> BTW: What happens if -mrecip is used to compile 481.wrf?
I will give it a try.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34709
[Bug c++/34715] New: always_inline does not seem to force inlining when used only in the definition of a function in a namespace
Snapshot gcc-4.3-20080104, gcc-4.3-20071109.
Test code below. When 'inline' modifier and 'always_inline' attribute are used
only in the definition of "min", inlining does not appear to happen (and no
error is output). When I add the modifier and attribute to the declaration of
"min", inlining does happen as expected.
Also: If I change X to a class, and min to a static function, inlining occurs
even if I mark only the declaration with 'inline' and 'always_inline'.
Note: I am assuming inlining hasn't happened due to the presence of the
following line in the assembly generated with the -S option:
call_ZN1X3minIiEERKT_S3_S3_
Apologies if that's not correct, or if I have misunderstood what's supposed to
happen with use of always_inline.
==
PREPROCESSED SOURCE #1
==
# 1 "y.cpp"
# 1 ""
# 1 ""
# 1 "y.cpp"
# 1 "try.h" 1
namespace X
{
template
const T& min(const T& a, const T& b);
}
template
inline __attribute__ ((always_inline)) const T& X::min(const T& a, const T& b)
{
return a < b ? a : b;
}
# 2 "y.cpp" 2
int main()
{
int a, b;
return X::min(a, b);
}
==
PREPROCESSED SOURCE #2
==
# 1 "y.cpp"
# 1 ""
# 1 ""
# 1 "y.cpp"
# 1 "try.h" 1
namespace X
{
template
inline __attribute__ ((always_inline)) const T& min(const T& a, const T& b);
}
template
inline __attribute__ ((always_inline)) const T& X::min(const T& a, const T& b)
{
return a < b ? a : b;
}
# 2 "y.cpp" 2
int main()
{
int a, b;
return X::min(a, b);
}
--
Summary: always_inline does not seem to force inlining when used
only in the definition of a function in a namespace
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lo at meep dot co dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34715
[Bug target/34709] [4.3 regression]: revision 131342 miscompiled 481.wrf on Linux/Intel64
--- Comment #4 from hjl at lucon dot org 2008-01-08 18:24 --- (In reply to comment #2) > BTW: What happens if -mrecip is used to compile 481.wrf? > "-O2 -mrecip -ffast-math" miscompiles 481.wrf on Linux/Intel64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34709
[Bug target/34709] [4.3 regression]: revision 131342 miscompiled 481.wrf on Linux/Intel64
--- Comment #5 from ubizjak at gmail dot com 2008-01-08 18:36 --- (In reply to comment #3) > It works. Ok, then we have the same issue with rsqrtss as with rcpss in PR target/34702. I'll disable -mrecip as default for -ffast-math. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-08 18:36:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34709
[Bug middle-end/34212] spurious warning: value computed is not used
--- Comment #6 from pluto at agmk dot net 2008-01-08 19:00 --- (In reply to comment #5) > Mine, but this will not get in until around the 25th. > ping ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34212
[Bug target/34709] [4.3 regression]: revision 131342 miscompiled 481.wrf on Linux/Intel64
--- Comment #6 from uros at gcc dot gnu dot org 2008-01-08 19:23 --- Subject: Bug 34709 Author: uros Date: Tue Jan 8 19:22:46 2008 New Revision: 131403 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131403 Log: PR target/34709 Revert: 2008-01-05 Uros Bizjak <[EMAIL PROTECTED]> * config/i386/i386.c (ix86_builtin_reciprocal): Remove check for TARGET_RECIP. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34709
[Bug target/34709] [4.3 regression]: revision 131342 miscompiled 481.wrf on Linux/Intel64
--- Comment #7 from ubizjak at gmail dot com 2008-01-08 19:27 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34709
[Bug rtl-optimization/34716] application segfaults when compiled with -O2, but works well with -O1
--- Comment #1 from aleksey dot shipilev at gmail dot com 2008-01-08 19:07 --- Created an attachment (id=14901) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14901&action=view) test used in issue This test was derived from powertweak code, which segfaults. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34716
[Bug rtl-optimization/34716] New: application segfaults when compiled with -O2, but works well with -O1
When building application (namely, powertweak) with gcc 4.1.2 using -02, application experiences segfault during startup. When building in the same configuration but using -O1, all works fine. Attached microtest (test.c) which resembles the problem: # gcc test.c && ./a.out before: output=bff74f74, buf=bff74d74 after: output=bff74f74, buf=bff74d74 sizeof(buf)=512 result=0 # gcc -O1 test.c && ./a.out before: output=bff0b700, buf=bff0b500 after: output=bff0b700, buf=bff0b500 sizeof(buf)=512 result=0 # gcc -O2 test.c && ./a.out before: output=bfd004fc, buf=bfd002fc after: output=bfd004fc, buf=bfd002fc sizeof(buf)=512 result=0 Segmentation fault<--- If I try to hunt down the differences between -O1 and -O2 as described at http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Optimize-Options.html: # gcc -O1 -fthread-jumps -fcrossjumping -foptimize-sibling-calls -fcse-follow-jumps -fcse-skip-blocks -fgcse -fgcse-lm -fexpensive-optimizations -fstrength-reduce -frerun-cse-after-loop -frerun-loop-opt -fcaller-saves -fpeephole2 -fschedule-insns -fschedule-insns2 -fsched-interblock -fsched-spec -fregmove -fstrict-aliasing -fdelete-null-pointer-checks -freorder-blocks -freorder-functions -falign-functions -falign-jumps -falign-loops -falign-labels -ftree-vrp -ftree-pre test.c && ./a.out before: output=bfd4ed60, buf=bfd4eb60 after: output=bfd4ed60, buf=bfd4eb60 sizeof(buf)=512 result=0 All is OK, so I have failed to find guilty optimization. Moreover, when I try to disable all optimizations described at http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Option-Summary.html under "Optimization options": # gcc -O2 -fno-align-functions -fno-align-jumps -fno-align-labels -fno-align-loops -fno-sched-stalled-insns -fno-bounds-check -fno-branch-probabilities -fno-profile-values -fno-vpt -fno-branch-target-load-optimize -fno-branch-target-load-optimize2 -fno-btr-bb-exclusive -fno-caller-saves -fno-cprop-registers -fno-cse-follow-jumps -fno-cse-skip-blocks -fno-cx-limited-range -fno-data-sections -fno-delete-null-pointer-checks -fno-early-inlining -fno-expensive-optimizations -fno-fast-math -fno-float-store -fno-force-addr -fno-function-sections -fno-gcse -fno-gcse-lm -fno-gcse-sm -fno-gcse-las -fno-gcse-after-reload -fno-loop-optimize -fno-crossjumping -fno-if-conversion -fno-if-conversion2 -fno-inline-functions -fno-inline-functions-called-once -fno-keep-inline-functions -fno-keep-static-consts -fno-merge-constants -fno-merge-all-constants -fno-modulo-sched -fno-branch-count-reg -fno-defer-pop -fno-loop-optimize2 -fno-move-loop-invariants -fno-function-cse -fno-guess-branch-probability -fno-inline -fno-math-errno -fno-peephole -fno-peephole2 -fno-unsafe-math-optimizations -fno-unsafe-loop-optimizations -fno-finite-math-only -fno-trapping-math -fno-zero-initialized-in-bss -fno-omit-frame-pointer -fno-optimize-register-move -fno-optimize-sibling-calls -fno-prefetch-loop-arrays -fno-profile-generate -fno-profile-use -fno-regmove -fno-rename-registers -fno-reorder-blocks -fno-reorder-blocks-and-partition -fno-reorder-functions -fno-rerun-cse-after-loop -fno-rerun-loop-opt -fno-rounding-math -fno-schedule-insns -fno-schedule-insns2 -fno-sched-interblock -fno-sched-spec -fno-sched-spec-load -fno-sched-spec-load-dangerous -fno-sched2-use-superblocks -fno-sched2-use-traces -fno-reschedule-modulo-scheduled-loops -fno-signaling-nans -fno-single-precision-constant -fno-stack-protector -fno-strength-reduce -fno-strict-aliasing -fno-tracer -fno-thread-jumps -fno-unroll-all-loops -fno-unroll-loops -fno-peel-loops -fno-split-ivs-in-unroller -fno-unswitch-loops -fno-variable-expansion-in-unroller -fno-tree-pre -fno-tree-ccp -fno-tree-dce -fno-tree-loop-optimize -fno-tree-loop-linear -fno-tree-loop-im -fno-tree-loop-ivcanon -fno-ivopts -fno-tree-dominator-opts -fno-tree-dse -fno-tree-copyrename -fno-tree-sink -fno-tree-ch -fno-tree-sra -fno-tree-ter -fno-tree-lrs -fno-tree-fre -fno-tree-vectorize -fno-tree-vect-loop-version -fno-tree-salias -fno-web -fno-tree-copy-prop -fno-tree-store-ccp -fno-tree-store-copy-prop -fno-whole-program test.c && ./a.out before: output=bfca84ac, buf=bfca82ac after: output=bfca84ac, buf=bfca82ac sizeof(buf)=512 result=0 Segmentation fault <--- Still, I have segmentation fault, but all optimization seem to be disabled. There is easy workaround though (not to compile with -O2), but I believe this issue worth fixing. -- Summary: application segfaults when compiled with -O2, but works well with -O1 Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aleksey dot shipilev at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.c
[Bug fortran/19925] Implied do-loop in an initialization expression is broken
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2008-01-08 19:04 --- This may be fixable employing gfc_trans_assignment at the right place similar to the fix Paul used in PR34438. I have not time to chase this. Un-assigning. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|jvdelisle at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19925
[Bug rtl-optimization/34716] application segfaults when compiled with -O2, but works well with -O1
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-08 19:35 --- I always get: before: output=bfda12b4, buf=bfda10b4 after: output=bfda12b4, buf=bfda10b4 sizeof(buf)=512 result=-1 I really don't think this is a GCC bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34716
[Bug middle-end/32395] false positive warning about use of uninitialized variable.
--- Comment #13 from pluto at agmk dot net 2008-01-08 19:44 --- Created an attachment (id=14903) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14903&action=view) testacase for /opt/gcc43/bin/g++ 32395.ii -Wall -c -O1 -m32 -- pluto at agmk dot net changed: What|Removed |Added Attachment #13789|0 |1 is obsolete|| Attachment #14095|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32395
[Bug rtl-optimization/34716] application segfaults when compiled with -O2, but works well with -O1
--- Comment #3 from aleksey dot shipilev at gmail dot com 2008-01-08 19:47 --- Sorry, Andrew, but result=-1 shows that ioctl failed to read enough data from the device (maybe your device does not support SMART?). I tried to get rid of any of such hardware-specific code, but can't eliminate that ioctl(). Sorry again. I still think that this is GCC bug, since compiler generates correct code in mode A and fails to do that in mode B. It's weird again that A + (B-A) != B, so it looks like general problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34716
[Bug target/31644] [avr] can't find a register in class 'BASE_POINTER_REGS' while reloading 'asm'
--- Comment #7 from sascha-web-gcc dot gnu dot org at silbe dot org 2008-01-08 19:29 --- Created an attachment (id=14902) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14902&action=view) another asm code block triggering the error Just been hit by this after upgrading to Ubuntu gutsy (avr-gcc 4.1.0). Custom asm snippet triggering the error (does NOT use movhi) is attached. This compiled fine previously. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31644
[Bug target/31644] [avr] can't find a register in class 'BASE_POINTER_REGS' while reloading 'asm'
--- Comment #8 from eric dot weddington at atmel dot com 2008-01-08 19:49 --- (In reply to comment #7) > Created an attachment (id=14902) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14902&action=view) [edit] > another asm code block triggering the error > > Just been hit by this after upgrading to Ubuntu gutsy (avr-gcc 4.1.0). Custom > asm snippet triggering the error (does NOT use movhi) is attached. This > compiled fine previously. > Could you post your command line for this test case? And can you please post a pre-processed source for your test case? This case produces additional errors other than the one described in the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31644
[Bug ada/34717] New: Ada runtime improvements for OpenBSD to enable tasking and related features
Ada runtime of gcc trunk (r131371) does not have OpenBSD specific sections, so the pthreads library and related features are not used/enabled on OpenBSD. Patch at http://iki.fi/tero.koskinen/gcc/gcc-ada-gnattools-tasking.diff adds files a-intnam-openbsd.ads, g-soccon-openbsd.ads, s-osinte-openbsd.adb, s-osinte-openbsd.ads and system-openbsd-x86.ads, and modifies the build system to use them on OpenBSD/x86. (gcc/ada/gsocket.h is also modified to avoid some build errors.) After the patch, configure option "--with-threads=gnat" enables tasking for OpenBSD on x86 platform. Mentioned *openbsd*.ad[bs] files are almost direct copies of FreeBSD equivalents. Only few magic numbers/constants are changed. The patch is tested on OpenBSD/x86 4.2-current. Earlier version of this patch (for gcc 4.2) was joint work with Markus Hennecke. (See http://marc.info/?l=openbsd-ports&m=117679065130354&w=2 for details.) -- Summary: Ada runtime improvements for OpenBSD to enable tasking and related features Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tero dot koskinen at iki dot fi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34717
