../gcc-4.2.2/libstdc++-v3/configure can't determine version of ld 2.18
Hello,
I have binutils 2.18
$ ld --version
GNU ld (GNU Binutils) 2.18
...
But during compilation I get following:
configure: WARNING: === Linker version 1800 is too old for
configure: WARNING: === full symbol versioning support in this release of GCC.
configure: WARNING: === You would need to upgrade your binutils to version
configure: WARNING: === 21400 or later and rebuild GCC.
configure: WARNING: === Symbol versioning will be disabled.
I've found out that in two configure scripts linker version is
determined with following regexp:
../gcc-4.2.2/libstdc++-v3/configure (this script contains a few similar lines
with linker definition)
ldver=`$LD --version 2/dev/null | head -1 | \
sed -e 's/GNU ld \(version \)\{0,1\}\(([^)]*)
\)\{0,1\}\([0-9.][0-9.]*\).*/\3/'`
../gcc-4.2.2/libgomp/configure
ldver=`$LD --version 2/dev/null | head -1 | \
sed -e 's/GNU ld \(version \)\{0,1\}\(([^)]*)
\)\{0,1\}\([0-9.][0-9.]*\).*/\3/'`
That regexps are incorrect for ld 2.18.
I think it is better to use following regexp:
ldver=`$LD --version 2/dev/null | head -1 | sed -e 's/GNU .*
\([0-9][0-9.]*\)[. ]*$/\1/'`
or to be stricter and handle only ld:
ldver=`$LD --version 2/dev/null | head -1 | sed -e 's/GNU ld .*
\([0-9][0-9.]*\)[. ]*$/\1/'`
It takes last word that starts and ends with digit and consist of digits and
dots.
And this (first example) regexp can be applied to many GNU programs (as, ar,
nm, etc)
Best regards.
~
Yevgeniy Litvinenko
~
[Bug rtl-optimization/34628] [4.2/4.3 Regression] problems with inlining on ARM
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2008-01-10 14:03 --- Created an attachment (id=14907) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14907action=view) Lightly tested fix. I'll give it a whirl on IA-64 but it would be nice to test it on ARM too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34628
[Bug fortran/34721] Output statements fool the -Wuninitialized option
--- Comment #1 from manu at gcc dot gnu dot org 2008-01-10 14:07 ---
This is an example that shows that small differences in code lead to quite
different SSA representations. Without print we have a PHI node, where one of
the operands is the uninitialized value, so we warn. However, with the print
statement, we don't generate such PHI node, so we don't warn:
* With the print statement:
# BLOCK 7, starting at line 5
# PRED: 5 (false) 6 (fallthru)
# STORES: { dt_parm.5D.883 }
[pr34721.f90 : 5] dt_parm.5D.883.commonD.821.filenameD.743 ={v}
pr34721.f90[1]{lb: 1 sz: 1};
# STORES: { dt_parm.5D.883 }
[pr34721.f90 : 5] dt_parm.5D.883.commonD.821.lineD.744 ={v} 5;
# STORES: { dt_parm.5D.883 }
[pr34721.f90 : 5] dt_parm.5D.883.commonD.821.flagsD.741 ={v} 128;
# STORES: { dt_parm.5D.883 }
[pr34721.f90 : 5] dt_parm.5D.883.commonD.821.unitD.742 ={v} 6;
[pr34721.f90 : 5] _gfortran_st_write (dt_parm.5D.883);
[pr34721.f90 : 5] _gfortran_transfer_integer (dt_parm.5D.883, nD.872, 4);
== PASSED BY REFERENCE!!
[pr34721.f90 : 5] _gfortran_st_write_done (dt_parm.5D.883);
# LOADS: { nD.872 }
[pr34721.f90 : 6] D.884_31 = nD.872;= NO PHI NODE!!
[pr34721.f90 : 6] iD.871_32 = 1;
[pr34721.f90 : 6] if (iD.871_32 = D.884_31)
goto bb 8;
else
goto bb 9;
# SUCC: 8 (true) 9 (false)
* Without the print statement
# BLOCK 7, starting at line 6
# PRED: 5 (false) 6 (fallthru)
# nD.872_2 = PHI nD.872_26(D)(5), nD.872_32(6) == PHI NODE WITH
UNINITIALIZED VALUE!!
[pr34721.f90 : 6] D.883_33 = nD.872_2;
[pr34721.f90 : 6] iD.871_34 = 1;
[pr34721.f90 : 6] if (iD.871_34 = D.883_33)
goto bb 8;
else
goto bb 9;
# SUCC: 8 (true) 9 (false)
I have no idea why print generates loads/stores but if the variable is passed
by reference to a function, it is very risky to warn, since the function may
initialize the variable.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
CC||manu at gcc dot gnu dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-01-10 14:07:44
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34721
[Bug tree-optimization/34651] [4.3 Regression] ICE in set_value_range, at tree-vrp.c:321
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-01-10 14:28 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34651
[Bug tree-optimization/34651] [4.3 Regression] ICE in set_value_range, at tree-vrp.c:321
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-10 14:29 --- Subject: Bug 34651 Author: rguenth Date: Thu Jan 10 14:28:40 2008 New Revision: 131442 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131442 Log: 2008-01-10 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/34651 * tree-sra.c (sra_build_assignment): Sanitize. Use the correct types and ordering for masking and converting. * g++.dg/torture/pr34651.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr34651.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-sra.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34651
[Bug fortran/34729] New: Localization of run-time error messages, written into the executable
I saw that gfortran writes (at least sometimes) a localized run-time error
message:
_gfortran_runtime_error (Attempt to allocate a negative amount of
memory.[1]{lb: 1 sz: 1});
_gfortran_os_error (Memory allocation failed[1]{lb: 1 sz: 1});
becomes then (LANG=de_DE.UTF-8):
_gfortran_runtime_error (Versuch, einen negativen Betrag von Speicher zu
r[1]{lb: 1 sz: 1});
_gfortran_os_error (Speicherreservierung gesc[1]{lb: 1 sz: 1});
The first string should be:
Versuch, einen negativen Betrag von Speicher zu reservieren.
and the second
Speicherreservierung gescheitert
one sees that the strings are truncated.
Expected:
Either the localized message should not be truncated - or the English version
of the string should be used throughout.
--
Summary: Localization of run-time error messages, written into
the executable
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34729
[Bug c/34668] [4.3 Regression] ICE in find_compatible_field with -combine
--- Comment #9 from jakub at gcc dot gnu dot org 2008-01-10 14:50 --- http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00404.html http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00408.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34668
[Bug tree-optimization/34683] [4.3 Regression] SSA rewriting in the loop unroller causes quadratic behavior
--- Comment #38 from rguenth at gcc dot gnu dot org 2008-01-10 14:36 --- Created an attachment (id=14908) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14908action=view) hack to disable rewriting of VOPs I tried to change the unroller doing only SSA_NAME replacement update after each unrolling and leave rewriting the virtual operands to after the whole pass but either I messed up or this even makes it worse ;) See the prototype hack. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug tree-optimization/34683] [4.3 Regression] SSA rewriting in the loop unroller causes quadratic behavior
--- Comment #39 from rguenth at gcc dot gnu dot org 2008-01-10 15:01
---
Hmm, looks I was compeltely wrong about the cause of the slowdown. We actually
run cfg_cleanup after cunroll and merge blocks like
BB1
...
BB2
# SFT.1_2 = PHI SFT.1_1 (BB1)
...
# SFT.1000_2 = PHI SFT.1000_1 (BB1)
# SFT.1_3 = VDEF SFT.1_2
...
# SFT.1000_3 = VDEF SFT.1_2
*mem = x;
and in merging the blocks we do (tree_merge_blocks):
/* Remove all single-valued PHI nodes from block B of the form
V_i = PHI V_j by propagating V_j to all the uses of V_i. */
for (phi = phi_nodes (b); phi; phi = phi_nodes (b))
{
...
replace_uses_by (def, use);
remove_phi_node (phi, NULL, true);
BUT! replace_uses_by will for _each_ phi-node we replace its uses update
the target stmt! And fold it! We can do better with VOPs
Preparing a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug rtl-optimization/30957] Misscompare with variable expansion optimization
--- Comment #14 from eres at il dot ibm dot com 2008-01-10 15:05 --- -fassociative-math and -fsigned-zeros flags can not co-exist. I guess this testcase should be removed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30957
[Bug fortran/34721] Output statements fool the -Wuninitialized option
--- Comment #2 from burnus at gcc dot gnu dot org 2008-01-10 15:08 --- Related to PR 31094, PR 31279, and PR 23169. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34721
[Bug libstdc++/34730] New: Legal program doesn't compile with -D_GLIBCXX_DEBUG
The attached C++ source is AFAICS legal C++. However it doesn't compile with the debug libstdc++, as the debug code assumes that each given set can be compared with the passed compare operator. -- Summary: Legal program doesn't compile with -D_GLIBCXX_DEBUG Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominik dot strasser at onespin-solutions dot com GCC build triplet: x86_64-redhat-linux GCC host triplet: x86_64-redhat-linux GCC target triplet: x86_64-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34730
[Bug libstdc++/34730] Legal program doesn't compile with -D_GLIBCXX_DEBUG
--- Comment #1 from dominik dot strasser at onespin-solutions dot com 2008-01-10 15:28 --- Created an attachment (id=14909) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14909action=view) Source code showing the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34730
[Bug tree-optimization/34683] [4.3 Regression] SSA rewriting in the loop unroller causes quadratic behavior
--- Comment #40 from rguenth at gcc dot gnu dot org 2008-01-10 15:32 --- After you fix this, we're back to SCCVN is slow with lots of virtual operands. For -O2 (which appearantly is the worst case) we now have the following profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls s/call s/call name 10.33 3.08 3.08 313563133 0.00 0.00 VN_INFO 8.85 5.72 2.64 365 0.01 0.04 DFS 7.17 7.86 2.14 96368081 0.00 0.00 iterative_hash_expr 5.77 9.58 1.72 472085 0.00 0.00 valueize_vuses 5.43 11.20 1.62 216407 0.00 0.00 visit_reference_op_store 4.93 12.67 1.47 2093493 0.00 0.00 ggc_alloc_stat 3.15 13.61 0.94 17042636 0.00 0.00 set_bb_for_stmt 2.63 14.40 0.79 2442685 0.00 0.00 add_vars_for_offset 1.74 14.92 0.52 operand_build_cmp 1.54 15.38 0.46 226140 0.00 0.00 shared_vuses_from_stmt 1.48 15.82 0.44 245792 0.00 0.00 vn_reference_lookup 1.27 16.20 0.38 5272581 0.00 0.00 mark_all_vars_used_1 1.24 16.57 0.37 16115332 0.00 0.00 bitmap_set_bit 1.14 16.91 0.34 58 0.01 0.02 remove_unused_locals 1.14 17.25 0.34 6878571 0.00 0.00 htab_find_slot_with_hash 1.04 17.56 0.31 4286747 0.00 0.00 add_virtual_operand 1.04 17.87 0.31 255362 0.00 0.00 vec_gc_o_reserve_1 ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug target/34299] [avr] ICE on function attribute syntax for main()
--- Comment #3 from j at uriah dot heep dot sax dot de 2008-01-10 15:56
---
Some bugs appear to re-appear. :-(
While I get
__attribute__((naked))
int main(void)
{
// ...
return 42;
}
to compile with the current compiler, the following piece of code:
__attribute__((signal, naked))
void __vector_42(void)
{
static unsigned char x;
x++;
}
still triggers the ICE:
% avr-gcc -mmcu=attiny2313 -S foo.c
foo.c:3: internal compiler error: in start_function, at c-decl.c:6177
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34299
[Bug middle-end/31094] Support annotating function parameters as read-only and/or non-escaping
--- Comment #2 from manu at gcc dot gnu dot org 2008-01-10 15:38 ---
Isn't this similar to
include stdio.h
main()
{
char foo[10];
printf(%s, foo);
}
and other functions that we know for sure don't modify their arguments. It
seems a missed optimisation not only for Fortran.
--
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=31094
[Bug middle-end/31094] Support annotating function parameters as read-only and/or non-escaping
--- Comment #3 from manu at gcc dot gnu dot org 2008-01-10 15:40 ---
Actually, that is for Wuninitialized. For a missed optimisation:
#include stdio.h
char foo()
{
char str[] = Hola;
char c;
printf(%s, str);
c = str[0];
return c;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31094
[Bug libstdc++/34730] Legal program doesn't compile with -D_GLIBCXX_DEBUG
--- Comment #2 from pcarlini at suse dot de 2008-01-10 15:59 --- Interesting. I agree the code is legal, on the other hand, we want to check the required ordering... Would it be ok to you to have the check moved to _GLIBCXX_DEBUG_PEDANTIC?? -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-10 15:59:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34730
[Bug libstdc++/34730] Legal program doesn't compile with -D_GLIBCXX_DEBUG
--- Comment #3 from pcarlini at suse dot de 2008-01-10 16:10 --- Hi Doug. As the main author of our debug-mode, I'd like to know your opinion about this issue... On one hand, in the actual algorithm we are not comparing values from the same range, on the other hand, clearly the specifications require ordering, thus we may want to check it... -- pcarlini at suse dot de changed: What|Removed |Added CC||doug dot gregor at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34730
[Bug target/34641] [4.3 Regression] ICE in reload_cse_simplify_operands, at postreload.c:395
--- Comment #6 from krebbel at gcc dot gnu dot org 2008-01-10 16:47 --- Subject: Bug 34641 Author: krebbel Date: Thu Jan 10 16:46:26 2008 New Revision: 131445 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131445 Log: 2008-01-10 Andreas Krebbel [EMAIL PROTECTED] PR middle-end/34641 * reload.c (push_reload): Add assertions. All constants from reg_equiv_constant should have been used for replacing the respective pseudo earlier. (find_reloads_address): Invoke find_reloads_address_part for constant taken from the reg_equiv_constant array. 2008-01-10 Andreas Krebbel [EMAIL PROTECTED] PR middle-end/34641 * g++.dg/torture/pr34641.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr34641.C Modified: trunk/gcc/ChangeLog trunk/gcc/reload.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34641
[Bug tree-optimization/34683] [4.3 Regression] SSA rewriting in the loop unroller causes quadratic behavior
--- Comment #41 from rguenth at gcc dot gnu dot org 2008-01-10 16:59 --- Subject: Bug 34683 Author: rguenth Date: Thu Jan 10 16:59:06 2008 New Revision: 131446 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131446 Log: 2008-01-10 Richard Guenther [EMAIL PROTECTED] PR middle-end/34683 * tree-cfg.c (tree_merge_blocks): Do not go through the full-blown folding and stmt updating path if we just deal with virtual operands. * tree-ssa-copy.c (may_propagate_copy): Do not short-cut test for abnormal SSA_NAMEs. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-cfg.c trunk/gcc/tree-ssa-copy.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug tree-optimization/34683] SSA rewriting in the loop unroller causes quadratic behavior
--- Comment #43 from rguenth at gcc dot gnu dot org 2008-01-10 17:05 --- Actually this is not a regression against a released compiler, as both the 4.1 and the 4.2 branches ICE for this testcase: gfortran-4.2 -S -o /dev/null t.f90 -O -fstrict-aliasing t.f90: In function 'ampli': t.f90:83: internal compiler error: in gfc_trans_array_constructor, at fortran/trans-array.c:1466 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://bugs.opensuse.org for instructions. so, can we declare this as fixed (the huge number of VOPs we have special PRs for)? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3 Regression] SSA|SSA rewriting in the loop |rewriting in the loop |unroller causes quadratic |unroller causes quadratic |behavior |behavior| Target Milestone|4.3.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug tree-optimization/34683] [4.3 Regression] SSA rewriting in the loop unroller causes quadratic behavior
--- Comment #42 from rguenth at gcc dot gnu dot org 2008-01-10 17:02 --- This is probably all we can get for now - maybe another few % with minor tweaks, but nothing earth-shattering. After all, we _do_ have a much larger IL due to the number of VOPs not partitioned. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug tree-optimization/34683] SSA rewriting in the loop unroller causes quadratic behavior
--- Comment #44 from steven at gcc dot gnu dot org 2008-01-10 17:39 --- Yes, fixed. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug target/34299] [avr] ICE on function attribute syntax for main()
--- Comment #4 from eric dot weddington at atmel dot com 2008-01-10 17:56
---
(In reply to comment #3)
__attribute__((signal, naked))
void __vector_42(void)
{
static unsigned char x;
x++;
}
still triggers the ICE:
However, if there is a function prototype, and the attributes are placed on the
prototype, there is no bug:
__attribute__((signal, naked))
void __vector_42(void);
void __vector_42(void)
{
static unsigned char x;
x++;
}
Is it really a bug?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34299
[Bug target/34299] [avr] ICE on function attribute syntax for main()
-- eric dot weddington at atmel dot com changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-10 18:07:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34299
[Bug tree-optimization/30927] tree-nested creates pointless static chains and trampolines when the callgraph is non-trivial
--- Comment #8 from baldrick at gcc dot gnu dot org 2008-01-10 18:25 --- Your solution seems to be somewhat complex though. Can't we get away with an iterative propagation algorithm for the DECL_NO_STATIC_CHAIN flag? Yes, but it is less efficient: in the worst case the number of node visits goes up by a factor of the nesting depth. Since this depth is sure to be fairly small (typically 2 or 3) this probably is of no consequence. I am now working on a revised patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30927
[Bug target/34299] [avr] ICE on function attribute syntax for main()
--- Comment #5 from steven at gcc dot gnu dot org 2008-01-10 18:05 --- If there is an ICE, there is a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34299
[Bug rtl-optimization/30957] Misscompare with variable expansion optimization
--- Comment #15 from ubizjak at gmail dot com 2008-01-10 18:23 ---
(In reply to comment #13)
This testcase has an execution failure on i686-pc-linux-gnu when using
-fpic/-fPIC.
They also fail for non-pic compilations when the testcase _really_ executes the
test:
Index: testsuite/gcc.dg/pr30957-1.c
===
--- testsuite/gcc.dg/pr30957-1.c(revision 131441)
+++ testsuite/gcc.dg/pr30957-1.c(working copy)
@@ -7,7 +7,7 @@
extern void abort (void);
extern void exit (int);
-float
+float __attribute__((noinline))
foo (float d, int n)
{
unsigned i;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30957
[Bug rtl-optimization/30957] Misscompare with variable expansion optimization
--- Comment #16 from eres at il dot ibm dot com 2008-01-10 18:32 --- This is because the test requires -fassociative-math for enabling the variable-expansion as well as -fsigned-zeros for honor the sign of zero; but they can not co-exist; also under -funsafe-math-optimizations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30957
[Bug middle-end/34400] [4.3 regression] bad interaction between DF and SJLJ exceptions
--- Comment #48 from zadeck at naturalbridge dot com 2008-01-10 18:44
---
Subject: Re:
I do not want to commit this patch until after seongbae gets the new
node visiting sorted out.
This patch does for the rd problem what
http://gcc.gnu.org/bugzilla/attachment.cgi?id=14729
does for the live problem. The gains on the test cases are less dramatic.
There has also been a small amount of cleanup in this patch (the rename
of *local_finalize to *finalize.
Other issues with the patch:
The patch adds a flag for the rd problem to either trim the sets with
the lr information (as we always do with the live problem) or to leave
it as it was (setting the DF_RD_NO_TRIM flag.)
The loop optimizations need this flag since they only compute the
solution over a subset of the cfg. The problem with using a subset is
that def that occurs inside the subset whose only use occurs outside the
subset will look dead if you trim the sets with the lr infomation. This
causes the rtl loop passes, which are the only passes to still compute
dataflow over a subset of the function, to make mistakes. If you are
computing rd over the entire program, this flag should not be set.
There is also code in here not to consider the invalidated_by_call sets
in the confluence function unless you are do not want the sets trimmed.
This saves a little time. The point is that the lr problem already
considers the invalidated_by_call sets so when you trim, you get the
result of this and it is not necessary for the forwards case.
I also added a quickout if the confluence function is called on an fake
edge (as in the live confluence function). This is a latent bug that
does not show up because the passes that use this problem currently do
not use fake edges.
When bootstrapping this patch is a mild win in terms of time. The main
reason for it are the really large or badly structured programs in which
it should help (see the prs).
This patch is part of at least three patches that each make headway on
these two prs. There is still some room for more improvement so it is
not clear that these prs should close when all of these patches are
applied.
I have at least one more idea to attack the space in 26854, but
(assuming i even do the patch before the end of stage 3), it will be up
to Mitchell to decide if that is too much code for this late date.
i have bootstrapped and regression tested this patch on x86-64, ppc-32,
ia-64.
ok for commit after seonbae gets his patch in?
kenny
2008-01-05 Kenneth Zadeck [EMAIL PROTECTED]
PR rtl-optimization/26854
PR rtl-optimization/34400
* ddg.c (create_ddg_dep_from_intra_loop_link): Do not use
DF_RD-gen.
* df.h (df_changeable_flags.DF_RD_NO_TRIM): New.
(df_rd_bb_info.expanded_lr_out): New.
* loop_invariant.c (find_defs): Added DF_RD_NO_TRIM flag.
* loop_iv.c (iv_analysis_loop_init): Ditto.
* df-problems.c (df_rd_free_bb_info, df_rd_alloc, df_rd_confluence_n,
df_rd_bb_local_compute, df_rd_transfer_function, df_rd_free):
Added code to allocate, initialize or free expanded_lr_out.
(df_rd_bb_local_compute_process_def): Restructured to make
more understandable.
(df_rd_confluence_n): Add code to do nothing with fake edges and
code to no apply invalidate_by_call sets if the sets are being trimmed.
(df_lr_local_finalize): Renamed to df_lr_finalize.
(df_live_local_finalize): Renamed to df_live_finalize.
Index: ddg.c
===
--- ddg.c (revision 131439)
+++ ddg.c (working copy)
@@ -184,12 +184,13 @@ create_ddg_dep_from_intra_loop_link (ddg
{
int regno = REGNO (SET_DEST (set));
struct df_ref *first_def;
- struct df_rd_bb_info *bb_info = DF_RD_BB_INFO (g-bb);
+ struct df_ref *last_def;
first_def = df_bb_regno_first_def_find (g-bb, regno);
gcc_assert (first_def);
- if (bitmap_bit_p (bb_info-gen, first_def-id))
+ last_def = df_bb_regno_last_def_find (g-bb, regno);
+ if (first_def == last_def)
return;
}
}
Index: df.h
===
--- df.h(revision 131439)
+++ df.h(working copy)
@@ -402,22 +402,30 @@ enum df_changeable_flags
{
/* Scanning flags. */
/* Flag to control the running of dce as a side effect of building LR. */
- DF_LR_RUN_DCE = 1, /* Run DCE. */
- DF_NO_HARD_REGS = 2, /* Skip hard registers in RD and CHAIN
Building. */
- DF_EQ_NOTES = 4, /* Build chains with uses present in
EQUIV/EQUAL notes. */
- DF_NO_REGS_EVER_LIVE= 8, /* Do not compute the regs_ever_live. */
+ DF_LR_RUN_DCE = 1 0, /* Run DCE. */
+ DF_NO_HARD_REGS = 1 1, /* Skip hard registers in RD and CHAIN
Building. */
+
+ /* Do not trim the solution using the LR result. This can make the
+ solution take much longer and
[Bug fortran/34396] Length of substrings defined by expressions not correctly computed in constructors
--- Comment #9 from pault at gcc dot gnu dot org 2008-01-10 19:11 --- Subject: Bug 34396 Author: pault Date: Thu Jan 10 19:10:48 2008 New Revision: 131448 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131448 Log: 2008-01-10 Paul Thomas [EMAIL PROTECTED] PR fortran/34396 * trans-array.c (gfc_trans_array_ctor_element): Use gfc_trans_string_copy to assign strings and perform bounds checks on the string length. (get_array_ctor_strlen): Remove bounds checking. (gfc_trans_array_constructor): Initialize string length checking. * trans-array.h : Add prototype for gfc_trans_string_copy. 2008-01-10 Paul Thomas [EMAIL PROTECTED] PR fortran/34396 * gfortran.dg/bounds_check_12.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/bounds_check_12.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-array.h trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34396
[Bug fortran/34396] Length of substrings defined by expressions not correctly computed in constructors
--- Comment #10 from pault at gcc dot gnu dot org 2008-01-10 19:13 --- 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=34396
[Bug middle-end/30905] [4.3 Regression] Fails to cross-jump
--- Comment #8 from steven at gcc dot gnu dot org 2008-01-10 19:18 --- We start with a CFG that looks like this (all edges directed down): ENTRY | 2 |\ | \ 3 5 |\ \ | \ \ 7 4--6 \ / \ / 8 | EXIT where basic block 4 is a forwarder block. Insns in blocks 6 and 7 match and are cross-jumped, to give a new CFG: ENTRY | 2 |\ | \ 3 5 |\ \ | \ \ | 4--6 \ / \ / 7 | 8 | EXIT where basic blocks 4 *and* 6 are now forwarder blocks. try_optimize_cfg then removes the redundant forwarders, which results in the following simpler CFG: ENTRY | 2 |\ 3 5 |/ 7 | EXIT where basic blocks 3 and 5 have matching insns that could be cross-jumped, except that there is a dead (set (reg:CCZ 17 flags) (compare ...)) in the way that the delete_trivially_dead_insns() call in cleanup_cfg() can obviously not delete. If that dead SET is deleted, blocks 3 and 5 are merged and we get the same code as previous releases. In pre-DF gcc releases, a liveness update would run a liveness update with dead code elimination. Copying that code from the GCC 4.2 release branch: /* Cleaning up CFG introduces more opportunities for dead code removal that in turn may introduce more opportunities for cleaning up the CFG. */ if (!update_life_info_in_dirty_blocks (UPDATE_LIFE_GLOBAL_RM_NOTES, PROP_DEATH_NOTES | PROP_SCAN_DEAD_CODE | PROP_KILL_DEAD_CODE | ((mode CLEANUP_LOG_LINKS) ? PROP_LOG_LINKS : 0))) I don't believe we have to aggressively delete dead code on every cleanup_cfg() iteration. We did plenty experiments with that on the DF branch, and running DCE all the time just loses in the cost/benefit trade-off. As I've noted before, we should remove dead code when it is beneficial. In this case, when we remove the forwarder edges and turn a conditional jump into a non-conditional jump, we should kill the code that computes the condition if the condition is dead at the end of the basic block. We can do this if we have liveness information available during cleanup_cfg(). -- steven at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2007-02-21 20:59:58 |2008-01-10 19:18:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30905
[Bug c/34732] New: Optimization flag trigger unexpected crash
This is the core of the problem (at comp_0.c):
...
for(j = 0;j 3;j++) {
comp_0_fptr[j][1]();
}
...
comp_0_fptr holds pointers to void functions. When compiling with -g,
everything works ok. Compiling with -O2, or any other, the effect that I get
is:
comp_0_fptr[0][1]();
comp_0_fptr[1][1]();
comp_0_fptr[1][1]();
and not comp_0_fptr[2][1](); at the last statement.
--
Summary: Optimization flag trigger unexpected crash
Product: gcc
Version: 4.1.3
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ijeukens at yahoo dot com dot br
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34732
[Bug c/34732] Optimization flag trigger unexpected crash
--- Comment #1 from ijeukens at yahoo dot com dot br 2008-01-10 19:24 --- Created an attachment (id=14910) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14910action=view) execution output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34732
[Bug middle-end/34732] Optimization flag trigger unexpected crash
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34732
[Bug middle-end/34732] Optimization flag trigger unexpected crash
--- Comment #2 from ijeukens at yahoo dot com dot br 2008-01-10 19:26 --- Created an attachment (id=14911) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14911action=view) source 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34732
[Bug middle-end/34732] Optimization flag trigger unexpected crash
--- Comment #3 from ijeukens at yahoo dot com dot br 2008-01-10 19:27 --- Created an attachment (id=14912) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14912action=view) source 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34732
[Bug middle-end/34732] Optimization flag trigger unexpected crash
--- Comment #4 from ijeukens at yahoo dot com dot br 2008-01-10 19:27 --- Created an attachment (id=14913) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14913action=view) source 3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34732
[Bug middle-end/34732] Optimization flag trigger unexpected crash
--- Comment #5 from ijeukens at yahoo dot com dot br 2008-01-10 19:28 --- Created an attachment (id=14914) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14914action=view) source 4 .. and last one -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34732
[Bug target/32895] Clobber list isn't working
--- Comment #4 from wvangulik at xs4all dot nl 2008-01-10 19:00 ---
In 4.2.2 there is still no warning when compiling without -O.
void main(void)
{
volatile struct
{
int a, b, c, d, e, f;
} x;
x.d = 5;
asm volatile(in r28, 0x2F : : : r28);
x.d = 6;
}
Using:
avr-gcc -Wall -g -S test.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32895
[Bug libstdc++/34730] Legal program doesn't compile with -D_GLIBCXX_DEBUG
--- Comment #4 from pcarlini at suse dot de 2008-01-10 20:04 --- Thinking more about this issue, probably a more sophisticated solution would be running the checks only when the value_types are equal. I'll try to prepare something. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34730
[Bug tree-optimization/34683] SSA rewriting in the loop unroller causes quadratic behavior
--- Comment #45 from jaydub66 at gmail dot com 2008-01-10 20:14 --- (In reply to comment #42) This is probably all we can get for now - maybe another few % with minor tweaks, but nothing earth-shattering. After all, we _do_ have a much larger IL due to the number of VOPs not partitioned. Well, it may not be earth-shattering, but it's still a solid improvement - of more than a few %! With rev. 131446 I get the following numbers: -O1 -fstrict-aliasing: 11sec, 201825 kB -O2: 22sec, 392166 kB -O3: 24sec, 388802 kB Compile time is reduced by a factor of 4 for -O2, and memory usage is halved for -O1! Nice job, Richard. So I'd say compile time really isn't an issue any more. But memory consumption is still a factor of 10 above what it was last year. Most of that comes from 'tree FRE' (~140MB), but all the junk in 'tree operand scan' is gone. For -O2 and -O3 another large chunk appears in 'tree PRE' (~160MB). Are you sure you want to close this bug? For me memory consumption is still an issue, and I would really like to see this fixed at some point. And if there is another bug which is a duplicate of this, could you point me to it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug middle-end/30905] [4.3 Regression] Fails to cross-jump
--- Comment #9 from steven at gcc dot gnu dot org 2008-01-10 20:16 --- Created an attachment (id=14915) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14915action=view) Fix using run_fast_dce I see no way around running run_fast_DCE. But at least let's try to run it only when really necessary, and try to avoid unnecessary repetitive work if CLEANUP_CROSSJUMP is set. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30905
[Bug tree-optimization/34683] SSA rewriting in the loop unroller causes quadratic behavior
--- Comment #46 from steven at gcc dot gnu dot org 2008-01-10 20:21 --- See e.g. bug 27004 and bug 33974. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug rtl-optimization/31944] [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit 2.6.20 kernel
--- Comment #22 from janis at gcc dot gnu dot org 2008-01-10 21:24 --- Steven asked for a regression hunt, but will not be pleased by the results. A hunt using a hppa64-linux cross cc1 on powerpc-linux identified http://gcc.gnu.org/viewcvs?view=revrev=81764 r81764 | dnovillo | 2004-05-13 06:41:07 + (Thu, 13 May 2004) which is the merge of tree-ssa-20020619-branch into mainline. If it would be helpful I could do a hunt on that branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944
[Bug rtl-optimization/31944] [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit 2.6.20 kernel
--- Comment #23 from steven at gcc dot gnu dot org 2008-01-10 22:18 --- Created an attachment (id=14916) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14916action=view) new test case that fails before the tree-ssa merge I made a new test case out of the .final_cleanup dump, and Janis confirmed it hangs even before the tree-ssa merge. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944
[Bug rtl-optimization/31944] [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit 2.6.20 kernel
--- Comment #24 from janis at gcc dot gnu dot org 2008-01-10 23:17 --- A regression test using the test added in comment #23 identified: http://gcc.gnu.org/viewcvs?view=revrev=74332 r74332 | sayle | 2003-12-05 14:06:46 + (Fri, 05 Dec 2003) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944
[Bug rtl-optimization/31944] [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit 2.6.20 kernel
--- Comment #25 from steven at gcc dot gnu dot org 2008-01-10 23:44 --- So this has been failing since at least GCC 3.4. And I see nothing in the identified patch that is related to how CSE handles its values, so I suspect this bug exists in older compilers as well (just needs another test case, maybe). And I still have no idea what is really going wrong here... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944
[Bug rtl-optimization/31944] [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit 2.6.20 kernel
--- Comment #26 from steven at gcc dot gnu dot org 2008-01-10 23:58 --- Mark, wrt. the release, I recommend this PR shouldn't be a blocker. The problem is old and is currently latent on the trunk, where it is only exposed with non-default options (-fno-inline-small-functions). Obviously, the problem is that the hash of reg 66 is changed after a hash table element is created for it in the bucket for the original hash. I have no idea yet whether this is expected, or if not, what is going wrong. Messing with CSE at this stage may be more dangerous than accepting the status quo. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944
[Bug ada/34466] s-tasinf.ads:81:42: cpu_set_t not declared in OS_Interface
--- Comment #1 from danglin at gcc dot gnu dot org 2008-01-11 01:01 --- Subject: Bug 34466 Author: danglin Date: Fri Jan 11 01:00:48 2008 New Revision: 131457 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131457 Log: PR ada/34466 * s-osinte-linux-hppa.ads (SC_NPROCESSORS_ONLN): New constant for sysconf call. (bit_field): New packed boolean type used by cpu_set_t. (cpu_set_t): New type corresponding to the C type with the same name. Note that on the Ada side we use a bit field array for the affinity mask. There is not need for the C macro for setting individual bit. (pthread_setaffinity_np): New imported routine. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/s-osinte-linux-hppa.ads -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34466
[Bug libstdc++/34733] New: numpunct::grouping() doesn't match libc value for Bulgarian (bg_BG) locale
I came across this while investigating (most likely) a related problem in
Apache stdcxx. Btw., I suspect the bg_BG locale is incorrect in defining
thousands_sep to NUL and filed
http://sources.redhat.com/bugzilla/show_bug.cgi?id=5599
$ cat t.cpp g++ -dumpversion g++ t.cpp LC_NUMERIC=bg_BG locale -ck
LC_NUMERIC ./a.out bg_BG | od -c
#include cassert
#include clocale
#include cstdio
#include locale
#include string
int main (int argc, char *argv[])
{
const char* const name = 1 argc ? argv [1] : bg_BG;
const std::locale bg (name);
const std::numpunctchar np =
std::use_facetstd::numpunctchar (bg);
const char ts = np.thousands_sep ();
const std::string grp = np.grouping ();
std::setlocale (LC_ALL, name);
const lconv* const pconv = std::localeconv ();
std::printf ('\\x%02x' == '\\x%02x'\n, ts, *pconv-thousands_sep);
std::printf (\%s\ == \%s\\n, grp.c_str (), pconv-grouping);
assert (ts == *pconv-thousands_sep);
assert (grp == pconv-grouping);
}
4.1.2
LC_NUMERIC
decimal_point=,
thousands_sep=
grouping=3;3
numeric-decimal-point-wc=44
numeric-thousands-sep-wc=0
numeric-codeset=CP1251
a.out: t.cpp:26: int main(int, char**): Assertion `grp == pconv-grouping'
failed.
000 ' \ x 0 0 ' = = ' \ x 0 0 '
020 \n = =003 003 \n
034
--
Summary: numpunct::grouping() doesn't match libc value for
Bulgarian (bg_BG) locale
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34733
[Bug ada/34466] s-tasinf.ads:81:42: cpu_set_t not declared in OS_Interface
--- Comment #2 from danglin at gcc dot gnu dot org 2008-01-11 01:07 --- Fixed. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34466
[Bug c++/34734] New: attribute((progmem)) not handled properly in C++ for AVRs
Using the progmem attribute in C++ sources produce warning messages about uninitialized variables. The following preprocessor output works correctly under 4.1 but produces said warnings (in every warning level): # 1 is.cpp # 1 built-in # 1 command-line # 1 is.cpp int i1 __attribute__((__progmem__)) = 1; int __attribute__((__progmem__)) i2 = 2; __attribute__((__progmem__)) int i3 = 3; extern int i4 __attribute__((__progmem__)); int i4 = 4; extern int __attribute__((__progmem__)) i5; int i5 = 5; extern __attribute__((__progmem__)) int i6; int i6 = 6; typedef int i7_t __attribute__((__progmem__)); i7_t i7 = 7; typedef int __attribute__((__progmem__)) i8_t; i8_t i8 = 8; typedef __attribute__((__progmem__)) int i9_t; i9_t i9 = 9; const char s1[] __attribute__((__progmem__)) = string 1; const char __attribute__((__progmem__)) s2[] = string 2; const __attribute__((__progmem__)) char s3[] = string 3; __attribute__((__progmem__)) const char s4[] = string 4; extern const char s5[] __attribute__((__progmem__)); const char s5[] = string 5; extern const char __attribute__((__progmem__)) s6[]; const char s6[] = string 6; extern const __attribute__((__progmem__)) char s7[]; const char s7[] = string 7; extern __attribute__((__progmem__)) const char s8[]; const char s8[] = string 8; typedef const char s9_t __attribute__((__progmem__)); const s9_t s9[] = string 9; typedef const char __attribute__((__progmem__)) s10_t; const s10_t s10[] = string 10; typedef const __attribute__((__progmem__)) char s11_t; const s11_t s11[] = string 11; typedef __attribute__((__progmem__)) const char s12_t; const s12_t s12[] = string 12; This is the used command line and the compiler output: /usr/local/avr-4.2.2/bin/avr-gcc -Wall -save-temps -mmcu=atmega88 -Os -c -o /tmp/x.o is.cpp is.cpp:1: warning: only initialized variables can be placed into program memory area is.cpp:2: warning: only initialized variables can be placed into program memory area is.cpp:3: warning: only initialized variables can be placed into program memory area is.cpp:10: warning: only initialized variables can be placed into program memory area is.cpp:11: warning: only initialized variables can be placed into program memory area is.cpp:12: warning: only initialized variables can be placed into program memory area is.cpp:13: warning: only initialized variables can be placed into program memory area Please note that the same source compiled as C works properly without any warnings. -- Summary: attribute((progmem)) not handled properly in C++ for AVRs Product: gcc Version: 4.2.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: markuslampert at yahoo dot com GCC host triplet: x86 GCC target triplet: avr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34734
[Bug libstdc++/34733] numpunct::grouping() doesn't match libc value for Bulgarian (bg_BG) locale
--- Comment #1 from pcarlini at suse dot de 2008-01-11 01:54 --- Yes, I think we want to suspend this, waiting for the resolution of the glibc issue. Because, I clearly remember adjusting the code basing on feedback from people working on glibc: I learned that an empty thousand separator implies no grouping (i.e., the langinfo entry for GROUPING is not relevant in that case) and we even added a comment about that in the code. I think Andreas Schwab may remember something... -- pcarlini at suse dot de changed: What|Removed |Added CC||schwab at suse dot de, ||pcarlini at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34733
[Bug libstdc++/34733] numpunct::grouping() doesn't match libc value for Bulgarian (bg_BG) locale
--- Comment #2 from sebor at roguewave dot com 2008-01-11 02:09 --- Right, in C it does mean that (because thousands_sep is a multibyte string, and so the value is really ). The problem is that in C++ a NUL thousands_sep is a perfectly valid single-byte character, i.e., '\0'. IMO, the way to fix it is by somehow distinguishing a NUL thousands_sep that comes from the system locale (e.g., via localeconv()) and a NUL thousands_sep intentionally supplied by the user (read test suite writer ;-) because they want to see it on output. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34733
[Bug libstdc++/34733] numpunct::grouping() doesn't match libc value for Bulgarian (bg_BG) locale
--- Comment #3 from pcarlini at suse dot de 2008-01-11 02:18 --- (In reply to comment #2) Right, in C it does mean that (because thousands_sep is a multibyte string, and so the value is really ). The problem is that in C++ a NUL thousands_sep is a perfectly valid single-byte character, i.e., '\0'. IMO, the way to fix it is by somehow distinguishing a NUL thousands_sep that comes from the system locale (e.g., via localeconv()) and a NUL thousands_sep intentionally supplied by the user (read test suite writer ;-) because they want to see it on output. I do not understand. When v3 sees a NUL thousand separator in a system locale (like bg_BG or what else), it understands no grouping, consistently with C, as you are saying. In that case, what it would see as GROUPING with langinfo is simply not relevant, I would say random garbage. Therefore, there is no point in comparing anything. What should we change? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34733
[Bug libstdc++/34733] numpunct::grouping() doesn't match libc value for Bulgarian (bg_BG) locale
--- Comment #4 from pcarlini at suse dot de 2008-01-11 02:27 --- In other terms, on the v3 side, we are not grouping anything in such cases, therefore grouping() can only be the empty string, consistently with 22.2.3.1.2. As for the thousands separator, a '\0' seems a good character as anything else, in that case. I don't see what could v3 do in order to improve the conformance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34733
[Bug target/34641] [4.3 Regression] ICE in reload_cse_simplify_operands, at postreload.c:395
--- Comment #7 from ismail at pardus dot org dot tr 2008-01-11 02:31
---
Added testcase doesn't compile on i686-linux :
gcc/testsuite/g++.dg/torture/pr34641.C:16: error: 'operator new' takes type
'size_t' ('unsigned int') as first parameter
--
ismail at pardus dot org dot tr changed:
What|Removed |Added
CC||ismail at pardus dot org dot
||tr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34641
[Bug libstdc++/34733] numpunct::grouping() doesn't match libc value for Bulgarian (bg_BG) locale
--- Comment #5 from sebor at roguewave dot com 2008-01-11 03:09 --- It's irrelevant to the implementation but it could be relevant to user-defined formatting (or parsing) code that bypasses num_put (or num_get) but uses numpunct to get the expected formats. IMO, the improvement in any Linux implementation (libstdc++ or stdcxx) lies in figuring out how to preserve the \3\3 grouping and NUL thousands_sep for bg_BG (and expose each via numpunct::grouping() and numpunct::thousdands_sep()) without causing num_put to insert NUL every three digits. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34733
[Bug libstdc++/34733] numpunct::grouping() doesn't match libc value for Bulgarian (bg_BG) locale
--- Comment #6 from pcarlini at suse dot de 2008-01-11 03:17 --- (In reply to comment #5) It's irrelevant to the implementation but it could be relevant to user-defined formatting (or parsing) code that bypasses num_put (or num_get) but uses numpunct to get the expected formats. I'm not questioning that. IMO, the improvement in any Linux implementation (libstdc++ or stdcxx) lies in figuring out how to preserve the \3\3 grouping and NUL thousands_sep for bg_BG (and expose each via numpunct::grouping() and numpunct::thousdands_sep()) without causing num_put to insert NUL every three digits. Frankly, I think it's impossible. Because the underlying glibc info says the C++ library to not group. The locale does not group. In that case, I don't think grouping() can be anything but the empty string. And I think 22.2.3.1.2/3 (and the rest of 22.2) almost enforces that explicitly. If you disagree with that, I think we should file a DR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34733
[Bug libstdc++/34733] numpunct::grouping() doesn't match libc value for Bulgarian (bg_BG) locale
--- Comment #7 from sebor at roguewave dot com 2008-01-11 03:37 --- But that's just the libstdc++ interpretation of grouping and thousands_sep (no offense). The C library paints a different picture. If I want to write my own formatter/parser for numbers in the Bulgarian locale that inserts '@' as my own thousands separator every 3 digits I can do it but I have to drop down to C and get the grouping data from localeconv(). Not that there's anything wrong with it but it would be nice if I could also do it in C++ as well. What I'm saying is that if the C library says localeconv()-grouping is \3\3 the C++ numpunct::grouping() shouldn't say it's something else. I'm not sure this is something the C++ standard can do anything about except acknowledge it as a limitation. But that doesn't mean that implementations couldn't do better. For instance, numpunct could append some harmless special character to its internal representation of grouping (say set it to \3\3\0\0) when thousands_sep is NUL. num_put would be instructed to look for the two consecutive NULs in grouping and avoid inserting thousands_sep when NUL. Since user-defined numpunct would almost certainly not return grouping terminated by two NULs if such a facet with a grouping of \3\3 and NUL for thousands_sep num_put would insert the NUL as expected. Yes, it's a hack but it's one that would work in the vast majority of cases: the implementation would pass anal tests while behaving sanely in ordinary situations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34733
[Bug tree-optimization/33826] [4.1/4.2/4.3 Regression] GCC generates wrong code for infinitely recursive functions
--- Comment #18 from ghazi at gcc dot gnu dot org 2008-01-11 03:57 --- Thanks Kenny, patch posted here: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00445.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33826
[Bug middle-end/33187] Missed cmove opportunity
--- Comment #8 from ghazi at gcc dot gnu dot org 2008-01-11 03:58 --- Thanks Uros, patch posted here: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00445.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33187
[Bug libstdc++/34733] numpunct::grouping() doesn't match libc value for Bulgarian (bg_BG) locale
--- Comment #8 from pcarlini at suse dot de 2008-01-11 03:59 --- (In reply to comment #7) What I'm saying is that if the C library says localeconv()-grouping is \3\3 the C++ numpunct::grouping() shouldn't say it's something else. Why not? If we agree that when the thousand separator returned by the C library is NUL, then localeconv()-grouping **is meaningless**, garbage, uninitialized memory (I think we previously agreed about that), I don't see why people can expect that match. In particular, I don't see that because, in C++, due probably to a limitation in the standard, there is no separate boolean in numpunct to tell no-grouping: I maintain that essentially the only meaningful way to espress no-grouping in C++, in the grouping() string, is leaving the string empty. I think my reading of the standard is pretty straightforward, I mentioned a specific section, there is also a note, saying how 3 would be interpreted. Note, I'm not interested in num_put, here, of course in principle you can store somewhere the values returned by the underlying C library and make num_put happy, I do not dispute that you can play one of tricks you mentioned, for that. What I'm saying is that, a numpunct conveying to its user the meaning no-grouping is a numpunct returning an empty string from grouping(). Any other return value, even if for the sake of consistency of an hypothetical - note, I'm saying hypothetical, see above, I don't think localeconv()-grouping is anything but junk when the thousand separator is NUL, in C - localedata seems wrong to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34733
[Bug target/27971] eliminate shift in array[(x2)3]
--- Comment #5 from raksit at gcc dot gnu dot org 2008-01-11 04:21 --- Subject: Bug 27971 Author: raksit Date: Fri Jan 11 04:20:32 2008 New Revision: 131460 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131460 Log: gcc/ChangeLog PR rtl-optimization/27971 * combine.c (find_split_point): introduced a new split for certain types of mem rtx. gcc/testsuite/ChangeLog PR rtl-optimization/27971 * gcc.target/i386/pr27971.c: New testcase. Added: trunk/gcc/testsuite/gcc.target/i386/pr27971.c Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27971
[Bug middle-end/29256] [4.2/4.3 regression] loop performance regression
--- Comment #20 from ghazi at gcc dot gnu dot org 2008-01-11 04:21 --- Is the testcase gcc.dg/tree-ssa/loop-19.c supposed to work with -fpic/-fPIC? I'm getting failures on mainline and 4.2 with x86_64, and only on 4.2 with i686. Mainline i686 seems to work though. Fails: http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00383.html http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00365.html http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00410.html works: http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00366.html Thanks, --Kaveh -- ghazi at gcc dot gnu dot org changed: What|Removed |Added CC||ghazi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256
[Bug c/34735] New: C99 6.7.4/2 is not diagnose
This is not rejected:
static int a()
{
return 0;
}
extern int f(void);
inline int f(void)
{
return a();
}
CUT ---
This violates C99 6.7.4/2 which says:
An inline definition of a function with external linkage shall not contain a
definition of a
modifiable object with static storage duration, and shall not contain a
reference to an
identifier with internal linkage.
--
Summary: C99 6.7.4/2 is not diagnose
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34735
[Bug middle-end/29256] [4.2/4.3 regression] loop performance regression
--- Comment #21 from rakdver at kam dot mff dot cuni dot cz 2008-01-11 04:44 --- Subject: Re: [4.2/4.3 regression] loop performance regression Is the testcase gcc.dg/tree-ssa/loop-19.c supposed to work with -fpic/-fPIC? not necessarily; with -fpic, both memory accesses are fully strength-reduced, which seems to be the correct thing to do; however, I'm getting failures on mainline and 4.2 with x86_64, and only on 4.2 with i686. Mainline i686 seems to work though. the difference in the costs of the two variants is so small that you will basically get one of them at random. This test is not intended to be run with -fpic. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256
[Bug c/16622] [C99] extern inline is handled wrong in C99 mode
--- Comment #18 from pinskia at gcc dot gnu dot org 2008-01-11 04:50 --- 2 -- What does constraint #3 of section 6.7.4 mean? It is not fully as 6.7.4/3 is not diagnosed, I filed this as PR 34735. I guess Geoff forgot about this constraint. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||34735 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16622
[Bug c/34735] C99 6.7.4/3 is not diagnose
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-11 05:15 ---
We do reject this though:
static int a()
{
return 0;
}
inline int f(void)
{
return a();
}
extern int f(void);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34735
[Bug libstdc++/34733] numpunct::grouping() doesn't match libc value for Bulgarian (bg_BG) locale
--- Comment #9 from sebor at roguewave dot com 2008-01-11 05:44 --- I don't agree that localeconv()-grouping is garbage just because thousands_sep is NUL. I'm not aware of anything in C or POSIX that says that. In the case of bg_BG, the grouping is clearly correct. What's questionable in this case is the value of thousands_sep. But that's probably just a bug in the Bulgarian locale definition. Bugs aside, there may be a perfectly valid locale (a user-defined one) in which there is no thsousands_sep (i.e., it's NUL) but where grouping is non-empty. It's trivial to create one as an exercise. The C++ library numpunct should be able to represent such a locale without change. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34733
[Bug c/34736] New: AVR optimiser does not keep interrupt disabled blocks small
I am compiling for an avr target and sharing variables with interrupts. To safely update the variables I am disabling interrupts but I want the interrupts to be disabled for the shortest possible period of time. The compiler shifts the instructions around slightly when optimizing, this has the effect of increasing the time that interrupts are disabled. I've attached a trivial example which demonstrates this however more complicated code has a similar result with a varying number of instructions moved into the disabled section. I'm attaching a trivial example with .c, .i (typedefs trimmed) and .s files. The gcc used is from the Debian gcc-avr package version 4.2.2-1 Compilation line was: avr-gcc -mmcu=attiny13 -Wall -Os -fsigned-char -S -c -o interrupt_disable_bug.s interrupt_disable_bug.c -- Summary: AVR optimiser does not keep interrupt disabled blocks small Product: gcc Version: 4.2.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gcc-david at tulloh dot id dot au GCC target triplet: AVR http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34736
[Bug c/34736] AVR optimiser does not keep interrupt disabled blocks small
--- Comment #1 from gcc-david at tulloh dot id dot au 2008-01-11 06:04 --- Created an attachment (id=14917) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14917action=view) Trivial example source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34736
[Bug c/34736] AVR optimiser does not keep interrupt disabled blocks small
--- Comment #2 from gcc-david at tulloh dot id dot au 2008-01-11 06:05 --- Created an attachment (id=14918) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14918action=view) Trivial example intermediate file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34736
[Bug c/34736] AVR optimiser does not keep interrupt disabled blocks small
--- Comment #3 from gcc-david at tulloh dot id dot au 2008-01-11 06:05 --- Created an attachment (id=14919) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14919action=view) Trivial example assembler output file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34736
[Bug c++/33887] [4.1/4.2/4.3 Regression] Reference to bitfield gets wrong value when optimizing
--- Comment #18 from aoliva at gcc dot gnu dot org 2008-01-11 06:46 --- I don't see anything in expand_expr_real_1 that, given something like (wider)narrower_typed_value, would reduce the value in a way that takes the narrower_type into account. NOP_EXPR and CONVERT_EXPR will just expand the operand and be done with it if the modes of both types are the same and, in the case of bitfields with the same mode but lower precision, they are. Also, all uses of REDUCE_BIT_FIELD take only the target type into account, which means that, if the intermediate expression wasn't reduced at the time it was computed, then it won't ever be. And when the reduce_bit_field_operation langhook is false, then the intermediate expression won't have been reduced at the time it was computed. So we lose. What I don't know is whether languages that set reduce_bit_field_operation could expect expanders to take care of such expansions for them (they'd better, since the need for explicit reduction code is determined by whether the value is extracted from a bit-field in memory or held in a gimple reg that might be the result of optimization), or they're supposed to take care of the widening extension themselves (say, genericize (wider)unsigned_narrower_type_value as (wider)unsigned_narrower_type_value mask, and (wider)signed_narrower_type_value as (((wider)signed_narrower_type_value mask) ^ signbit) - signbit). Which is it? I.e., when !reduce_bit_field_operation, should expand_expr_real_1() perform the reduction to the inner type in widening conversions, or should convert_to_integer() take care of it when outprec inprec? -- aoliva at gcc dot gnu dot org changed: What|Removed |Added CC||aoliva at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33887
[Bug libfortran/34712] Formatted write of float broken (mingw32)
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-01-11 07:02 --- Reply to comment #2: I will update and see if that fixes it. Thanks Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34712
[Bug tree-optimization/34648] [4.3 Regression] ICE in find_or_generate_expression
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34648
[Bug c/34668] [4.3 Regression] ICE in find_compatible_field with -combine
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34668
[Bug c++/34691] [4.1/4.2/4.3 Regression] Default argument checking not performed after overload resolution with C linkage
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34691
[Bug preprocessor/34692] [4.2/4.3 regression] Internal error with pragma in macro
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34692
[Bug rtl-optimization/34628] [4.2/4.3 Regression] problems with inlining on ARM
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34628
