[Bug c++/50134] -Wmissing-prototypes doesn't work for C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50134 --- Comment #4 from Manuel López-Ibáñez 2011-09-30 07:00:40 UTC --- So Joseph, Jason, what is the difference between Wmissing-prototypes and Wmissing-declarations? Can't you just make one a synonym for the other and make one of them the canonical form?
[Bug c++/38980] [4.4/4.5/4.6/4.7 Regression] missing -Wformat warning on const char format string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38980 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-30 CC||jason at gcc dot gnu.org, ||jsm28 at gcc dot gnu.org Target Milestone|--- |4.4.7 Summary|missing -Wformat warning on |[4.4/4.5/4.6/4.7 |const char format string|Regression] missing ||-Wformat warning on const ||char format string Ever Confirmed|0 |1 --- Comment #2 from Jakub Jelinek 2011-09-30 07:46:22 UTC --- I think this has been caused by http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21089#c25 The c-format* stuff uses decl_constant_value, for C it will for const array variable with STRING_CST DECL_INITIAL return the DECL_INITIAL, but in C++ I think since the above commit it will not: 105256 mmitchel/* Do not return an aggregate constant (of which 105256 mmitchel string literals are a special case), as we do not 106533 kazu want to make inadvertent copies of such entities, 105256 mmitchel and we must be sure that their addresses are the 105256 mmitchel same everywhere. */ 105256 mmitchel|| TREE_CODE (init) == CONSTRUCTOR 105256 mmitchel|| TREE_CODE (init) == STRING_CST))) So, either we need a different function or an argument to decl_constant_value to force returning STRING_CST in that case, because in c-format case making inadvertent copies of such entities isn't a problem, c-format only wants to check that literal.
[Bug c++/50134] -Wmissing-prototypes doesn't work for C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50134 --- Comment #5 from Jonathan Wakely 2011-09-30 08:04:38 UTC --- C++ doesn't have prototypes, it has declarations and definitions, so the different names makes sense. I'm not sure what "Do so even if the definition itself provides a prototype." means in the context of C++.
[Bug target/50572] New: unstable performance on Atom due to loop alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50572
Bug #: 50572
Summary: unstable performance on Atom due to loop alignment
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sergos@gmail.com
After monitoring of Atom performance on trunk for some period of time I figured
out that we have a significant (up to 15%) instability because of loop
alignment. Currently for Atom we have the following alignments:
{&atom_cost, 16, 7, 16, 7, 16}
for
struct ptt
{
const struct processor_costs *cost; /* Processor costs */
const int align_loop; /* Default alignments. */
const int align_loop_max_skip;
const int align_jump;
const int align_jump_max_skip;
const int align_func;
};
Which means we try to align by 16, although if it takes no more than 7 bytes to
insert. This 'if' is the source of instability. For a reduction loop I observed
almost twice slowdown because it did not fit into 16bytes after being aligned
by 8.
I used the -falign-loops=16 option to measure code size impact using -m32-O2
-msse2 -mfpmath=sse -ffast-math -march=atom for SPEC2000:
SPEC2000
Test.text section size
-
AlignedCurrentIncreas%% increase
wupwise6303246300842400,04%
swim_602612602548640,01%
mgrid_6083886082121760,03%
applu_6416846414122720,04%
mesa_94144493811633280,35%
galgel_81350881176417440,21%
art_4375724374121600,04%
equake_4422284420841440,03%
facerec6949486945963520,05%
ammp_56142856029211360,20%
lucas_6632366629482880,04%
fma3d_1565348156022851200,33%
sixtrac1537844153422836160,24%
apsi_7191727183408320,12%
gzip_4804524800204320,09%
vpr_54816454715610080,18%
cc1_1554052154653275200,49%
mcf_4340364339081280,03%
crafty_59208459083612480,21%
parser_50947650827612000,24%
eon_118934811888524960,04%
perlbmk89429289126830240,34%
gap_84563684112445120,54%
vortex_96998896878812000,12%
bzip2_4725964722603360,07%
twolf_60714060504420960,35%
Will it be acceptable to put -falign-loops=16 under -mtune=atom for O2?
[Bug libstdc++/50573] New: configure lists --with-gnu-ld twice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50573 Bug #: 50573 Summary: configure lists --with-gnu-ld twice Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: al...@gcc.gnu.org on trunk i see: $ grep "^[[:space:]]*\-\-with-gnu-ld" libstdc++-v3/configure --with-gnu-ld assume the C compiler uses GNU ld [default=no] --with-gnu-ld assume the C compiler uses GNU ld default=no
[Bug libstdc++/50573] configure lists --with-gnu-ld twice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50573 --- Comment #1 from Bernhard Reutner-Fischer 2011-09-30 09:02:18 UTC --- btw.. same thing with java configury and three(!) times in gcc/configure: $ grep -c "^[[:space:]]*\-\-with-gnu-ld" */configure | egrep -v "(0|1)$" gcc/configure:3 libjava/configure:2 libstdc++-v3/configure:2
[Bug fortran/50564] [4.7 Regression] Front-end optimization - ICE with FORALL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50564 --- Comment #3 from Tobias Burnus 2011-09-30 09:11:38 UTC --- (In reply to comment #2) > I'll have a look in the next few days. One way could be to move the "EXPR_ASSIGN:" part of trans-stmt.c's gfc_trans_forall_1 into a separate function and add a "EXPR_BLOCK:" which loops over all c->block->next, calling that new function (with an gcc_assert that it only contains EXPR_ASSIGN); it probably deserves also a comment that the BLOCK is generated by the FE optimization.
[Bug libstdc++/50573] configure lists --with-gnu-ld twice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50573 --- Comment #2 from Andreas Schwab 2011-09-30 09:23:09 UTC --- The first one is coming from libtool.m4 (LT_PATH_LD), the second one from config/lib-ld.m4 (AC_LIB_PROG_LD, imported from gettext, with some quoting problems). The third occurrence in gcc has a different purpose.
[Bug tree-optimization/50574] New: gcc.c-torture/execute/vector-compare-1.c FAILs on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50574 Bug #: 50574 Summary: gcc.c-torture/execute/vector-compare-1.c FAILs on SPARC Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: artyom.shinkar...@gmail.com Host: sparc-sun-solaris2.* Target: sparc-sun-solaris2.* Build: sparc-sun-solaris2.* The new gcc.c-torture/execute/vector-compare-1.c test FAILs on Solaris/SPARC: output is: /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.c-torture/execute/vector-compare-1.c: In function 'main': /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.c-torture/execute/vector-compare-1.c:34:5: error: invalid vector comparison resulting type vector(4) int FAIL: gcc.c-torture/execute/vector-compare-1.c compilation, -O0 I cannot even parse the error message. Rainer
[Bug tree-optimization/50574] gcc.c-torture/execute/vector-compare-1.c FAILs on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50574 Rainer Orth changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug tree-optimization/50575] gcc.c-torture/execute/vector-compare-2.c FAILs on Solaris 8/9 x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50575 Rainer Orth changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug tree-optimization/50575] New: gcc.c-torture/execute/vector-compare-2.c FAILs on Solaris 8/9 x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50575 Bug #: 50575 Summary: gcc.c-torture/execute/vector-compare-2.c FAILs on Solaris 8/9 x86 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: artyom.shinkar...@gmail.com Host: i386-pc-solaris2.[89] Target: i386-pc-solaris2.[89] Build: i386-pc-solaris2.[89] The new gcc.c-torture/execute/vector-compare-2.c FAILs on Solaris 8 and 9/x86: output is: /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.c-torture/execute/vector-compare-2 .c: In function 'foo': /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.c-torture/execute/vector-compare-2 .c:7:1: note: The ABI for passing parameters with 16-byte alignment has changed in GCC 4.6 In file included from :0:0: /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.c-torture/execute/vector-compare-2 .c: In function 'foo': /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.c-torture/execute/vector-compare-2 .c:7:1: note: The ABI for passing parameters with 16-byte alignment has changed in GCC 4.6 FAIL: gcc.c-torture/execute/vector-compare-2.c compilation, -O2 -flto
[Bug tree-optimization/49662] [4.7 Regression] XFAIL: gcc.dg/graphite/interchange-XX.c, PRE confuses loop interchange
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49662 Rainer Orth changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #5 from Rainer Orth 2011-09-30 09:36:48 UTC --- All 3 tests now XPASS everywhere. It seems the XFAILs can be removed? Rainer
[Bug target/50099] ICE: internal compiler error: in extract_insn, at recog.c:2113 while building lttng-ust
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50099 --- Comment #10 from Ramana Radhakrishnan 2011-09-30 09:36:47 UTC --- Author: ramana Date: Fri Sep 30 09:36:43 2011 New Revision: 179378 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179378 Log: Fix PR target/50099 Added: trunk/gcc/testsuite/gcc.target/arm/pr50099.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.md trunk/gcc/config/arm/iterators.md trunk/gcc/config/arm/predicates.md trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/50574] gcc.c-torture/execute/vector-compare-1.c FAILs on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50574 --- Comment #1 from Dominique d'Humieres 2011-09-30 09:37:51 UTC --- It also fails on powerpc-apple-darwin9 (see http://gcc.gnu.org/ml/gcc-testresults/2011-09/msg03110.html) and s390x-ibm-linux-* (see http://gcc.gnu.org/ml/gcc-testresults/2011-09/msg03113.html).
[Bug tree-optimization/50052] [4.6/4.7 Regression] FAIL: gcc.dg/ipa/ipa-sra-2.c scan-tree-dump eipa_sra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50052 Rainer Orth changed: What|Removed |Added Target|hppa*-*-* |hppa*-*-*, alpha-dec-osf*, ||mips-sgi-irix*, ||sparc-sun-solaris* CC||ro at gcc dot gnu.org Host|hppa*-*-* |hppa*-*-*, alpha-dec-osf*, ||mips-sgi-irix*, ||sparc-sun-solaris* Build|hppa*-*-* |hppa*-*-*, alpha-dec-osf*, ||mips-sgi-irix*, ||sparc-sun-solaris* --- Comment #6 from Rainer Orth 2011-09-30 09:42:22 UTC --- Also affects Solaris/SPARC, Tru64 UNIX (Alpha), and IRIX (MIPS). Since this is unfixed for about 2 months, could the tests please be XFAILed on strict-alignment targets to reduce the noise? Rainer
[Bug libgomp/49965] libgomp.c++/reduction-4.C and libgomp.c++/task-8.C FAIL on Solaris 11/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49965 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-30 Ever Confirmed|0 |1 --- Comment #10 from Rainer Orth 2011-09-30 09:44:03 UTC --- Eric, could you please have a look to see if this is a SPARC backend issue or the problem lies elsewhere? Thanks. Rainer
[Bug c++/44473] iterators already defined for std::vector when using std::decimal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44473 --- Comment #13 from Paolo Carlini 2011-09-30 09:44:50 UTC --- By the way, the patch is approved thus we don't need further feedback to commi it and fix this annoying issue. I'll just do it later today, if nobody beats me!
[Bug tree-optimization/49662] [4.7 Regression] XFAIL: gcc.dg/graphite/interchange-XX.c, PRE confuses loop interchange
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49662 --- Comment #6 from rguenther at suse dot de 2011-09-30 09:53:26 UTC --- On Fri, 30 Sep 2011, ro at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49662 > > Rainer Orth changed: > >What|Removed |Added > > CC||ro at gcc dot gnu.org > > --- Comment #5 from Rainer Orth 2011-09-30 09:36:48 > UTC --- > All 3 tests now XPASS everywhere. It seems the XFAILs can be removed? Looks like so
[Bug target/19599] function pointer prevents tail-call optimization on arm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19599 --- Comment #7 from Ramana Radhakrishnan 2011-09-30 09:57:06 UTC --- The patch as applied today causes some bootstrap failures and I'm investigating that. Ramana
[Bug libstdc++/50573] configure lists --with-gnu-ld twice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50573 --- Comment #3 from Paolo Carlini 2011-09-30 09:58:50 UTC --- Thus doesn'l look like a library proper issue, right? Build system? Please add somebody in CC
[Bug tree-optimization/50574] gcc.c-torture/execute/vector-compare-1.c FAILs on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50574
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed||2011-09-30
Ever Confirmed|0 |1
--- Comment #2 from Richard Guenther 2011-09-30
10:05:00 UTC ---
It's gimple type verification. Please break on error() and check what
test fails and how. tree-cfg.c has
if (TYPE_VECTOR_SUBPARTS (type) != TYPE_VECTOR_SUBPARTS (op0_type)
|| (GET_MODE_SIZE (TYPE_MODE (type))
!= GET_MODE_SIZE (TYPE_MODE (op0_type
{
error ("invalid vector comparison resulting type");
debug_generic_expr (type);
return true;
[Bug tree-optimization/50575] gcc.c-torture/execute/vector-compare-2.c FAILs on Solaris 8/9 x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50575 --- Comment #1 from Richard Guenther 2011-09-30 10:06:48 UTC --- Please add proper options/prune for your target to avoid these ABI messages.
[Bug libgomp/49965] libgomp.c++/reduction-4.C and libgomp.c++/task-8.C FAIL on Solaris 11/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49965 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot |gnu.org |gnu.org --- Comment #11 from Eric Botcazou 2011-09-30 10:14:23 UTC --- Investigating.
[Bug c++/47346] access control for nested type is ignored in class template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47346 --- Comment #6 from dodji at seketeli dot org 2011-09-30 10:26:29 UTC --- "paolo.carlini at oracle dot com" a écrit: > Out of curiosity, does the posted patch fix at once *all* the issues mentioned > in the Description? Yes it does, AFAICT. > It would be great to have it! I am onto something else at the moment, but I intend to address Jason's comment to the patch I posted when I am done. Sorry for the delay.
[Bug libstdc++/50573] configure lists --with-gnu-ld twice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50573 Paolo Carlini changed: What|Removed |Added CC||bonzini at gnu dot org --- Comment #4 from Paolo Carlini 2011-09-30 10:27:44 UTC --- Let's add Paolo..
[Bug c++/47346] access control for nested type is ignored in class template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47346 --- Comment #7 from Paolo Carlini 2011-09-30 10:33:15 UTC --- Great. By the way, I think I didn't see any comment, that's why I asked ;)
[Bug libstdc++/50573] configure lists --with-gnu-ld twice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50573 --- Comment #5 from Paolo Bonzini 2011-09-30 10:41:32 UTC --- I'd just close it as wontfix. Perhaps we can fix the quoting problems, and hope that autoconf removes duplicates another day.
[Bug tree-optimization/50576] New: Recent vector comparison changes cause an ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50576
Bug #: 50576
Summary: Recent vector comparison changes cause an ICE
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mgret...@sourceware.org
CC: artyom.shinkar...@gmail.com,
richard.guent...@gmail.com
Host: x86_64-linux-gnu
Target: arm-none-eabi
Compiling the following (cut down from the
gcc.c-torture/execute/vector-compare-1.c test case):
/* try.c. */
int
main (int argc, char *argv[])
{
__attribute__ ((vector_size ((2) * sizeof (double double d0;
__attribute__ ((vector_size ((2) * sizeof (double double d1;
__attribute__ ((vector_size ((2) * sizeof (long long long long idres;
{
idres = (d0 > d1);
}
}
/* end of try.c. */
with:
arm-none-eabi-gcc -mfpu=neon -mfloat-abi=softfp -mcpu=cortex-a9 -c try.c
Gives:
try.c: In function 'main':
try.c:3:1: error: invalid vector comparison resulting type
vector(2) long long int
idres = d0 > d1;
try.c:3:1: internal compiler error: verify_gimple failed
This was tested with trunk r179378.
The issue was introduced by this patch
(http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01088.html - checked in as
r179342), and has not been fixed by Richard Guenther's follow on patch
(http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01933.html).
[Bug tree-optimization/50576] Recent vector comparison changes cause an ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50576 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011-09-30 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2011-09-30 10:49:43 UTC --- is sizeof(long long) == sizeof (double)?
[Bug other/50573] configure lists --with-gnu-ld twice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50573 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|libstdc++ |other Resolution||WONTFIX --- Comment #6 from Paolo Carlini 2011-09-30 10:55:57 UTC --- Yep. Thanks!
[Bug tree-optimization/50576] Recent vector comparison changes cause an ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50576 --- Comment #2 from Matthew Gretton-Dann 2011-09-30 10:58:03 UTC --- (In reply to comment #1) > is sizeof(long long) == sizeof (double)? Yes - sizeof(long long) and sizeof(double) are both 8.
[Bug tree-optimization/50577] New: IPA-PTA context insensitivity confuses pure-const analysis
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50577
Bug #: 50577
Summary: IPA-PTA context insensitivity confuses pure-const
analysis
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
For gcc.c-torture/execute/2412-2.c, slightly changed to
static int f(int a,int *y)
{
int x = a;
if (a==0)
return *y;
return f(a-1,&x);
}
int main(int argc,char **argv)
{
if (f (100, (int *) 0) != 1)
abort ();
exit (0);
}
IPA-PTA computes that in f(), y points to { 0, x }, and when the late
local pure-const pass comes along it sees f():
scanning: D.2734_4 = *y_3(D);
Indirect ref to local memory is OK
making f() const. That causes RTL DSE to delete the store x = a.
This triggers with
Index: tree-ssa-structalias.c
===
--- tree-ssa-structalias.c (revision 179378)
+++ tree-ssa-structalias.c (working copy)
@@ -6010,11 +6043,13 @@ pt_solution_includes_global (struct pt_s
if (pt->ipa_escaped)
return pt_solution_includes_global (&ipa_escaped_pt);
+#if 0
/* ??? This predicate is not correct for the IPA-PTA solution
as we do not properly distinguish between unit escape points
and global variables. */
if (cfun->gimple_df->ipa_pta)
return true;
+#endif
return false;
}
only (obviously).
[Bug c++/47346] access control for nested type is ignored in class template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47346 --- Comment #8 from dodji at seketeli dot org 2011-09-30 11:41:14 UTC --- The comment was posted in another month: http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00536.html Another hint at why we need a better patch/comments tracker :)
[Bug libstdc++/50578] New: Rethrow core dump if static link to libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50578 Bug #: 50578 Summary: Rethrow core dump if static link to libstdc++ Classification: Unclassified Product: gcc Version: 4.2.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: zihao.ji...@sinobot.com.cn Created attachment 25388 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25388 Small test program still fail with gcc4.2.4 Core dump occurs if rethrow the exception from inner function. This occurs on AIX5.1 with gcc4.2.4, the test program is attached. Compile it with: g++ -o exctest2 -static-libgcc -Wl,-bstatic -lsupc++ -lstdc++ exctest2.cpp -Wl,-bdynamic And run ./exctest2, the exception should be caught, but it always core dump at exc_catch_begin or exc_catch_end. The strange thing is, if I put std::cout.flush() before each 'throw;', the issue disappear.
[Bug libstdc++/50578] Rethrow core dump if static link to libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50578 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011-09-30 CC||dje at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini 2011-09-30 12:05:32 UTC --- I recommend checking a much more recent compiler, say from the 4.6.x branch: 4.2.x is not maintained anymore and any issue there would not be addressed anyway.
[Bug tree-optimization/50574] gcc.c-torture/execute/vector-compare-1.c FAILs on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50574 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-09-30 12:25:53 UTC --- I find the following trees when error is hit for the first time: (gdb) p type $1 = (tree) 0xfba11140 (gdb) pt unit size align 32 symtab 0 alias set -1 canonical type fb99c3c0 precision 32 min max pointer_to_this > sizes-gimplified TI size constant 128> unit size constant 16> align 128 symtab 0 alias set -1 canonical type fba10d20 nunits 4> (gdb) p op0_type $2 = (tree) 0xfba4e120 (gdb) pt unit size align 32 symtab 0 alias set -1 canonical type fb99c8a0 precision 32 pointer_to_this > sizes-gimplified BLK size constant 128> unit size constant 16> align 128 symtab 0 alias set -1 canonical type fba4e120 nunits 4 pointer_to_this > It seems the mode_size comparison is failing. Rainer
[Bug tree-optimization/50574] gcc.c-torture/execute/vector-compare-1.c FAILs on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50574 Richard Guenther changed: What|Removed |Added Status|WAITING |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #4 from Richard Guenther 2011-09-30 12:46:06 UTC --- (In reply to comment #3) > I find the following trees when error is hit for the first time: > > (gdb) p type > $1 = (tree) 0xfba11140 > (gdb) pt > type size > unit size > align 32 symtab 0 alias set -1 canonical type fb99c3c0 precision 32 > min > max > pointer_to_this > > sizes-gimplified TI > size > constant 128> > unit size > constant 16> > align 128 symtab 0 alias set -1 canonical type fba10d20 nunits 4> > (gdb) p op0_type > $2 = (tree) 0xfba4e120 > (gdb) pt > type size > unit size > align 32 symtab 0 alias set -1 canonical type fb99c8a0 precision 32 > pointer_to_this > > sizes-gimplified BLK > size > constant 128> > unit size > constant 16> > align 128 symtab 0 alias set -1 canonical type fba4e120 nunits 4 > pointer_to_this > > > It seems the mode_size comparison is failing. Ok, that makes sense. I'll test a patch. Richard. > Rainer
[Bug tree-optimization/50574] gcc.c-torture/execute/vector-compare-1.c FAILs on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50574
--- Comment #5 from Richard Guenther 2011-09-30
12:47:32 UTC ---
FYI
Index: tree-cfg.c
===
--- tree-cfg.c (revision 179378)
+++ tree-cfg.c (working copy)
@@ -3229,8 +3302,8 @@ verify_gimple_comparison (tree type, tre
}
if (TYPE_VECTOR_SUBPARTS (type) != TYPE_VECTOR_SUBPARTS (op0_type)
- || (GET_MODE_SIZE (TYPE_MODE (type))
- != GET_MODE_SIZE (TYPE_MODE (op0_type
+ || (GET_MODE_SIZE (TYPE_MODE (TREE_TYPE (type)))
+ != GET_MODE_SIZE (TYPE_MODE (TREE_TYPE (op0_type)
{
error ("invalid vector comparison resulting type");
debug_generic_expr (type);
[Bug tree-optimization/50574] gcc.c-torture/execute/vector-compare-1.c FAILs on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50574 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-09-30 12:52:09 UTC --- > --- Comment #4 from Richard Guenther 2011-09-30 > 12:46:06 UTC --- [...] > Ok, that makes sense. I'll test a patch. Great, thanks. Rainer
[Bug tree-optimization/50574] gcc.c-torture/execute/vector-compare-1.c FAILs on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50574 --- Comment #7 from Richard Guenther 2011-09-30 13:33:18 UTC --- Author: rguenth Date: Fri Sep 30 13:33:14 2011 New Revision: 179382 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179382 Log: 2011-09-30 Richard Guenther PR middle-end/50574 * tree-cfg.c (verify_gimple_comparison): Compare component mode sizes for vector comparisons. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-cfg.c
[Bug target/50579] [4.7 regression] gcc.target/mips/20020620-1.c FAILs on IRIX 6.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50579 Rainer Orth changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug tree-optimization/50574] gcc.c-torture/execute/vector-compare-1.c FAILs on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50574 Richard Guenther changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC|richard.guenther at gmail |rguenth at gcc dot gnu.org |dot com | Resolution||FIXED --- Comment #8 from Richard Guenther 2011-09-30 13:33:39 UTC --- Fixed.
[Bug target/50579] New: [4.7 regression] gcc.target/mips/20020620-1.c FAILs on IRIX 6.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50579 Bug #: 50579 Summary: [4.7 regression] gcc.target/mips/20020620-1.c FAILs on IRIX 6.5 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: rsand...@gcc.gnu.org Host: mips-sgi-irix6.5 Target: mips-sgi-irix6.5 Build: mips-sgi-irix6.5 After 20110831, gcc.target/mips/20020620-1.c has started to FAIL on IRIX 6.5: FAIL: gcc.target/mips/20020620-1.c (test for excess errors) UNRESOLVED: gcc.target/mips/20020620-1.c scan-assembler-not move Excess errors: /vol/gcc/src/hg/trunk/irix/gcc/testsuite/gcc.target/mips/20020620-1.c:1:0: error: '-mabi=n32' is incompatible with '-mlong64' The following new test FAILs as well,which is probably related: FAIL: gcc.target/mips/abi-o64-long64.c (test for excess errors) Excess errors: /vol/gcc/src/hg/trunk/irix/gcc/testsuite/gcc.target/mips/abi-o64-long64.c:1:0: error: the combination of '-mabi=o64' and '-mabicalls' is incompatible with '-mlong64'
[Bug target/50580] New: gcc.target/mips/interrupt_handler-[23].c FAIL on IRIX 6.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50580 Bug #: 50580 Summary: gcc.target/mips/interrupt_handler-[23].c FAIL on IRIX 6.5 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: rsand...@gcc.gnu.org Host: mips-sgi-irix6.5 Target: mips-sgi-irix6.5 Build: mips-sgi-irix6.5 The new gcc.target/mips/interrupt_handler-[23].c FAIL on IRIX 6.5: FAIL: gcc.target/mips/interrupt_handler-2.c scan-assembler \\t.cfi_restore 64\\n FAIL: gcc.target/mips/interrupt_handler-2.c scan-assembler \\t.cfi_restore 65\\n FAIL: gcc.target/mips/interrupt_handler-3.c scan-assembler \\t.cfi_restore 1\\n FAIL: gcc.target/mips/interrupt_handler-3.c scan-assembler \\t.cfi_restore 2\\n FAIL: gcc.target/mips/interrupt_handler-3.c scan-assembler \\t.cfi_restore 3\\n FAIL: gcc.target/mips/interrupt_handler-3.c scan-assembler \\t.cfi_restore 4\\n FAIL: gcc.target/mips/interrupt_handler-3.c scan-assembler \\t.cfi_restore 5\\n FAIL: gcc.target/mips/interrupt_handler-3.c scan-assembler \\t.cfi_restore 6\\n FAIL: gcc.target/mips/interrupt_handler-3.c scan-assembler \\t.cfi_restore 7\\n FAIL: gcc.target/mips/interrupt_handler-3.c scan-assembler \\t.cfi_restore 8\\n FAIL: gcc.target/mips/interrupt_handler-3.c scan-assembler \\t.cfi_restore 9\\n FAIL: gcc.target/mips/interrupt_handler-3.c scan-assembler \\t.cfi_restore 10\\n FAIL: gcc.target/mips/interrupt_handler-3.c scan-assembler \\t.cfi_restore 11\\n FAIL: gcc.target/mips/interrupt_handler-3.c scan-assembler \\t.cfi_restore 12\\n FAIL: gcc.target/mips/interrupt_handler-3.c scan-assembler \\t.cfi_restore 13\\n FAIL: gcc.target/mips/interrupt_handler-3.c scan-assembler \\t.cfi_restore 14\\n FAIL: gcc.target/mips/interrupt_handler-3.c scan-assembler \\t.cfi_restore 15\\n FAIL: gcc.target/mips/interrupt_handler-3.c scan-assembler \\t.cfi_restore 24\\n FAIL: gcc.target/mips/interrupt_handler-3.c scan-assembler \\t.cfi_restore 25\\n FAIL: gcc.target/mips/interrupt_handler-3.c scan-assembler \\t.cfi_restore 31\\n FAIL: gcc.target/mips/interrupt_handler-3.c scan-assembler \\t.cfi_restore 64\\n FAIL: gcc.target/mips/interrupt_handler-3.c scan-assembler \\t.cfi_restore 65\\n FAIL: gcc.target/mips/interrupt_handler-3.c scan-assembler \\t.cfi_def_cfa_offset 0\\n The assembler output doesn't contain any .cfi* directive, although gas 2.21.1 is in use and auto-host.h has #define HAVE_GAS_CFI_DIRECTIVE 1 #define HAVE_GAS_CFI_PERSONALITY_DIRECTIVE 1 #define HAVE_GAS_CFI_SECTIONS_DIRECTIVE 1
[Bug target/50580] gcc.target/mips/interrupt_handler-[23].c FAIL on IRIX 6.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50580 Rainer Orth changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug c++/50134] -Wmissing-prototypes doesn't work for C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50134
--- Comment #6 from joseph at codesourcery dot com 2011-09-30 14:16:40 UTC ---
On Fri, 30 Sep 2011, redi at gcc dot gnu.org wrote:
> I'm not sure what "Do so even if the definition itself provides a prototype."
> means in the context of C++.
That's simple enough: it's a style warning: a global function should be
declared in a header, so warn for
int
f (void)
{
return 0;
}
if there was no previous declaration for f. (For C++, the definition and
any previous declaration will always provide a prototype.)
As Ian said in , for C++
the two options reduce to the same thing because no non-prototype
declarations or definitions exist. For C,
int f();
int f(void) { return 0; }
gets a warning with -Wmissing-prototypes but not -Wmissing-declarations,
because "int f();" is a non-prototype declaration in C.
[Bug c++/50134] -Wmissing-prototypes doesn't work for C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50134
--- Comment #7 from Jonathan Wakely 2011-09-30
14:29:18 UTC ---
(In reply to comment #6)
> On Fri, 30 Sep 2011, redi at gcc dot gnu.org wrote:
>
> > I'm not sure what "Do so even if the definition itself provides a
> > prototype."
> > means in the context of C++.
>
> That's simple enough: it's a style warning: a global function should be
> declared in a header, so warn for
>
> int
> f (void)
> {
> return 0;
> }
>
> if there was no previous declaration for f.
I get that part.
> (For C++, the definition and
> any previous declaration will always provide a prototype.)
Exactly, that's my point. But I had missed the fact that the option is valid
in C as well as C++.
My uncertainty was about what that sentence means in the context of C++, and
the answer is nothing, because there are no definitions which do not provide a
prototype in C++ (ignoring the fact that "prototype" doesn't mean anything in
C++).
[Bug tree-optimization/50557] [4.7 Regression] Register pressure increase after reassociation (x86, 32 bits)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50557 --- Comment #5 from William J. Schmidt 2011-09-30 14:30:56 UTC --- Reassociation isn't doing anything untoward here that raises register pressure. The problem must be occurring downstream. Likely the scheduler is making a different decision that leads to more pressure. Block 9 contains the following prior to reassociation: D.3497_48 = D.3496_47 + D.3475_117; t_50 = D.3497_48 + D.3493_44; Reassociation changes this to: D.3497_48 = D.3493_44 + D.3496_47; t_50 = D.3497_48 + D.3475_117; This extends the lifetime of D.3475_117 but shortens the lifetime of D.3493_44, both of which go dead here. Register pressure is not raised at any point. There are no further changes to this code in the rest of the tree-SSA phases. Based on this, I don't see any reason to adjust the reassociation algorithm. Someone with some expertise in RTL phases could look into what happens later on to cause the additional pressure, but I don't see this as a tree-optimization issue.
[Bug tree-optimization/50575] gcc.c-torture/execute/vector-compare-2.c FAILs on Solaris 8/9 x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50575 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-09-30 14:39:28 UTC --- > --- Comment #1 from Richard Guenther 2011-09-30 > 10:06:48 UTC --- > Please add proper options/prune for your target to avoid these ABI messages. I just noticed that the ABI warnings occur for every optimization level, but only cause the two LTO tests to fail. I'll dig deeper since such an inconsistency shouldn't happen. Adding vector-compare-2.x (like pr38151.x) does work, of cause; I'll resort to that if necessary. Rainer
[Bug target/50038] redundant zero extensions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50038 tocarip.intel at gmail dot com changed: What|Removed |Added CC||tocarip.intel at gmail dot ||com --- Comment #3 from tocarip.intel at gmail dot com 2011-09-30 14:51:31 UTC --- So assuming this approach (modify implicit-zee pass) is right, we'll have to enable this pass at least on x86 (32 bit). Is it ok ? P. S. I forgot to mention that this patch bootstraps/passes ,make check.
[Bug tree-optimization/46309] optimization a==3||a==1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46309 --- Comment #5 from Jakub Jelinek 2011-09-30 15:00:18 UTC --- Author: jakub Date: Fri Sep 30 15:00:12 2011 New Revision: 179388 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179388 Log: PR tree-optimization/46309 * fold-const.c (make_range, merge_ranges): Remove prototypes. (make_range_step): New function. (make_range): Use it. * tree.h (make_range_step): New prototypes. * Makefile.in (tree-ssa-reassoc.o): Depend on $(DIAGNOSTIC_CORE_H). * tree-ssa-reassoc.c: Include diagnostic-core.h. (struct range_entry): New type. (init_range_entry, range_entry_cmp, update_range_test, optimize_range_tests): New functions. (reassociate_bb): Call optimize_range_tests. * gcc.dg/pr46309.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr46309.c Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-reassoc.c trunk/gcc/tree.h
[Bug inline-asm/50571] [4.6/4.7 Regression] Undesirable folding in "m" constrained asm operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50571 --- Comment #2 from Jakub Jelinek 2011-09-30 15:01:31 UTC --- Author: jakub Date: Fri Sep 30 15:01:27 2011 New Revision: 179389 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179389 Log: PR inline-asm/50571 * gimple-fold.c (fold_stmt_1) : If input constraints allow mem and not reg, pass true instead of false as second argument to maybe_fold_reference. * gcc.dg/pr50571.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr50571.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-fold.c trunk/gcc/testsuite/ChangeLog
[Bug target/50566] [avr]: Add support for better logging similar to -mdeb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50566 --- Comment #4 from Georg-Johann Lay 2011-09-30 15:15:32 UTC --- Author: gjl Date: Fri Sep 30 15:15:23 2011 New Revision: 179391 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179391 Log: PR target/50566 * config/avr/avr-protos.h (avr_log_t): New field address_cost. * config/avr/avr.c (avr_address_cost): Use it. * config/avr/avr-log.c (avr_log_set_avr_log): Initialize it. (avr_log_vadump): Unknown %-codes finish printing. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr-log.c trunk/gcc/config/avr/avr-protos.h trunk/gcc/config/avr/avr.c
[Bug c/50581] New: stdarg doesn't support array types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50581
Bug #: 50581
Summary: stdarg doesn't support array types
Classification: Unclassified
Product: gcc
Version: 4.5.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wolfg...@solfrank.net
__builtin_va_arg doesn't work correctly if given an array type, as it doesn't
take the promotion of array to pointer into account. When called without some
-std=xxx argument, gcc complains with the message "invalid use of non-lvalue
array". If it is called with e.g. -std=c99, it doesn't complain, but generates
incorrect code nevertheless.
The problem can be reproduced by the following program:
---
typedef char array[10];
array arr;
void
f(char *fmt, ...)
{
__builtin_va_list ap;
__builtin_va_start(ap, fmt);
__builtin_memcpy(arr, __builtin_va_arg(ap, array), sizeof arr);
__builtin_va_end(ap);
}
---
Fixing this is especially useful for types the user doesn't even know whether
it is an array or not, like e.g. __builtin_va_list itself to allow for
recursive variadic argument passing:
---
void
f(char *fmt, ...)
{
__builtin_va_list ap, ap1;
__builtin_va_start(ap, fmt);
__builtin_va_copy(ap1, __builtin_va_arg(ap, __builtin_va_list));
__builtin_va_end(ap);
__builtin_va_copy(ap, ap1);
__builtin_va_end(ap1);
__builtin_va_end(ap);
}
---
The fix is quite easy. Just apply the following diff to gcc/c-common.c:
---
Index: gcc/c-common.c
===
RCS file: /cvsroot/src/external/gpl3/gcc/dist/gcc/c-common.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 c-common.c
--- gcc/c-common.c 21 Jun 2011 01:20:03 - 1.1.1.1
+++ gcc/c-common.c 30 Sep 2011 15:12:23 -
@@ -5124,6 +5124,14 @@
tree
build_va_arg (location_t loc, tree expr, tree type)
{
+ /*
+ * Since arrays are converted to pointers when given as function arguments,
+ * here we have to do the same with the type of the argument.
+ * XXX Does it make sense to do the same with function type arguments?
+ */
+ if (TREE_CODE(type) == ARRAY_TYPE)
+type = build_pointer_type(strip_array_types(type));
+
expr = build1 (VA_ARG_EXPR, type, expr);
SET_EXPR_LOCATION (expr, loc);
return expr;
---
[Bug other/50582] New: Instruct GCC that added_clobbers_hard_reg_p shouldn't consider a specific register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50582 Bug #: 50582 Summary: Instruct GCC that added_clobbers_hard_reg_p shouldn't consider a specific register Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: paulo.ma...@csr.com As noted in : http://gcc.gnu.org/ml/gcc/2011-09/msg00313.html `insn_invalid_p' calls `added_clobbers_hard_reg_p' with the comment: /* If we have to add CLOBBERs, fail if we have to add ones that reference hard registers since our callers can't know if they are live or not. Otherwise, add them. */ Backends like rx and mn10300 implement CC_REGNUM as a register containing flags, however, none of their move instructions clobbers CC_REGNUM. If a backend move clobbers CC_REGNUM a move instruction (set r0 r1) is deemed as invalid because the pattern for it is: (parallel [(set r0 r1) (clobber CC_REGNUM)]) However, this shouldn't be the case. The backend should be able to inform genemit.c which registers shouldn't be considered hard registers for the purpose of `added_clobbers_hard_reg_p'.
[Bug lto/50568] [4.7 Regression] Massive LTO failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50568 --- Comment #32 from hjl at gcc dot gnu.org 2011-09-30 15:48:56 UTC --- Author: hjl Date: Fri Sep 30 15:48:51 2011 New Revision: 179395 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179395 Log: Use 64bit integer for LTO symbol ID. gcc/lto 2011-09-30 H.J. Lu Andi Kleen PR lto/50568 * lto.c (lto_splay_tree_delete_id): New. (lto_splay_tree_compare_ids): Likewise. (lto_splay_tree_lookup): Likewise. (lto_splay_tree_id_equal_p): Likewise. (lto_splay_tree_insert): Likewise. (lto_splay_tree_new): Likewise. (lto_resolution_read): Change id to unsigned HOST_WIDE_INT. Use lto_splay_tree_id_equal_p and lto_splay_tree_lookup. (create_subid_section_table): Use lto_splay_tree_lookup and lto_splay_tree_insert. (lto_file_read): Use lto_splay_tree_new. lto-plugin/ 2011-09-30 H.J. Lu Andi Kleen PR lto/50568 * lto-plugin.c (sym_aux): Change id to unsigned long long. (plugin_symtab): Likewise. (dump_symtab): Likewise. (resolve_conflicts): Likewise. (process_symtab): Likewise. Modified: trunk/gcc/lto/ChangeLog trunk/gcc/lto/lto.c trunk/lto-plugin/ChangeLog trunk/lto-plugin/lto-plugin.c
[Bug other/50582] Instruct GCC that added_clobbers_hard_reg_p shouldn't consider a specific register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50582
--- Comment #1 from Paulo J. Matos 2011-09-30
15:54:25 UTC ---
I have implemented a fix to this using a new macro: NOT_REALLY_HARD_REGS which
is an array of FIRST_PSEUDO_REGISTER length, with a 1 in position x if register
x should not be considered a hard register for the purposes of
added_clobbers_hard_reg_p.
So for my backend where FIRST_PSEUDO_REGISTER = 14, CC_REGNUM = 13,
NOT_REALLY_HARD_REGS looks as follows:
#define NOT_REALLY_HARD_REG \
{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1 }
I attach a patch to genemit.c implementing this enhancement.
[Bug other/50582] Instruct GCC that added_clobbers_hard_reg_p shouldn't consider a specific register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50582 --- Comment #2 from Paulo J. Matos 2011-09-30 15:57:21 UTC --- Created attachment 25389 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25389 Patch for GCC 4.6.1 implementing suggested enhancement
[Bug c++/49949] wrong sign for product of complex and double with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49949 --- Comment #13 from Jan Hubicka 2011-09-30 16:26:46 UTC --- > Maybe Honza has ideas about this... That patch affect inlining decisions, but should not affect correctness. So it seems that the bug whatever it is just gone latent. Honza
[Bug target/50583] New: Many __sync_XXX builtin functions are incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50583
Bug #: 50583
Summary: Many __sync_XXX builtin functions are incorrect
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: kirill.yuk...@intel.com, ubiz...@gmail.com
We have
`TYPE __sync_fetch_and_add (TYPE *ptr, TYPE value, ...)'
`TYPE __sync_fetch_and_sub (TYPE *ptr, TYPE value, ...)'
`TYPE __sync_fetch_and_or (TYPE *ptr, TYPE value, ...)'
`TYPE __sync_fetch_and_and (TYPE *ptr, TYPE value, ...)'
`TYPE __sync_fetch_and_xor (TYPE *ptr, TYPE value, ...)'
`TYPE __sync_fetch_and_nand (TYPE *ptr, TYPE value, ...)'
These builtins perform the operation suggested by the name, and
returns the value that had previously been in memory. That is,
{ tmp = *ptr; *ptr OP= value; return tmp; }
{ tmp = *ptr; *ptr = ~(tmp & value); return tmp; } // nand
On x86, they may be implemented as
[hjl@gnu-33 gcc]$ cat /tmp/x.c
int
foo (int *p)
{
return __sync_fetch_and_and(p, 7);
}
[hjl@gnu-33 gcc]$ gcc -S -O2 /tmp/x.c
[hjl@gnu-33 gcc]$ cat x.s
.file"x.c"
.text
.p2align 4,,15
.globlfoo
.typefoo, @function
foo:
.LFB0:
.cfi_startproc
movl(%rdi), %eax
.L2:
movl%eax, %edx
movl%eax, %ecx
andl$7, %edx
lock cmpxchgl%edx, (%rdi)
jne.L2
movl%ecx, %eax
ret
.cfi_endproc
.LFE0:
.sizefoo, .-foo
.ident"GCC: (GNU) 4.6.0 20110603 (Red Hat 4.6.0-10)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-33 gcc]$
This isn't equivalent to
{ tmp = *ptr; *ptr OP= value; return tmp; }
It is
{
tmp = *ptr;
tmp1 = tmp OP value;
return __sync_val_compare_and_swap (ptr, tmp, tmp1);
}
The only thing supported on x86 are
[hjl@gnu-33 gcc]$ cat /tmp/y.c
int
foo1 (int *p)
{
return __sync_fetch_and_add (p, 7);
}
int
foo2 (int *p)
{
return __sync_fetch_and_sub (p, 7);
}
[hjl@gnu-33 gcc]$ gcc -S -O2 /tmp/y.c
[hjl@gnu-33 gcc]$ cat y.s
.file"y.c"
.text
.p2align 4,,15
.globlfoo1
.typefoo1, @function
foo1:
.LFB0:
.cfi_startproc
movl$7, %eax
lock xaddl%eax, (%rdi)
ret
.cfi_endproc
.LFE0:
.sizefoo1, .-foo1
.p2align 4,,15
.globlfoo2
.typefoo2, @function
foo2:
.LFB1:
.cfi_startproc
movl$-7, %eax
lock xaddl%eax, (%rdi)
ret
.cfi_endproc
.LFE1:
.sizefoo2, .-foo2
.ident"GCC: (GNU) 4.6.0 20110603 (Red Hat 4.6.0-10)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-33 gcc]$
[Bug target/50583] Many __sync_XXX builtin functions are incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50583
--- Comment #1 from H.J. Lu 2011-09-30 16:57:14
UTC ---
We have 2 choices:
1. Update document of
`TYPE __sync_fetch_and_add (TYPE *ptr, TYPE value, ...)'
`TYPE __sync_fetch_and_sub (TYPE *ptr, TYPE value, ...)'
`TYPE __sync_fetch_and_or (TYPE *ptr, TYPE value, ...)'
`TYPE __sync_fetch_and_and (TYPE *ptr, TYPE value, ...)'
`TYPE __sync_fetch_and_xor (TYPE *ptr, TYPE value, ...)'
`TYPE __sync_fetch_and_nand (TYPE *ptr, TYPE value, ...)'
to
{
tmp = *ptr;
tmp1 = tmp OP value;
return __sync_val_compare_and_swap (ptr, tmp, tmp1);
}
2. Remove those __sync_fetch_and_XXX which aren't
{ tmp = *ptr; *ptr OP= value; return tmp; }
Since only
{ tmp = *ptr; *ptr OP= value; return tmp; }
can be used to implement locks, I think we should do 2.
[Bug c/50584] New: No warning for passing small array to C99 static array declarator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50584
Bug #: 50584
Summary: No warning for passing small array to C99 static array
declarator
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: i...@airs.com
C99 introduced the idea of using static in an array declarator in a function
prototype parameter. My reading of the standard is that using static means
that the actual argument must be at least that size. GCC should at least issue
a warning when that requirement is clearly violated.
For example, this program
extern void bar (void *a[static 6]);
void foo() {
void *a1;
void *a2[5];
void *a3[6];
void *a4[10];
bar (&a1);
bar (a2);
bar (a3);
bar (a4);
}
should issue a warning, or perhaps even an error, for the first two calls to
bar, as the compiler can clearly see that the values are not large enough.
[Bug c++/44473] iterators already defined for std::vector when using std::decimal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44473 --- Comment #14 from Janis Johnson 2011-09-30 17:33:48 UTC --- Author: janis Date: Fri Sep 30 17:33:41 2011 New Revision: 179399 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179399 Log: gcc/cp PR c++/44473 * mangle.c (write_type): Handle CV qualifiers for decimal classes. gcc/testsuite PR c++/44473 * g++.dg/dfp/44473-1.C: New test. * g++.dg/dfp/44473-2.C: New test. * g++.dg/dfp/mangle-1.C: New test. * g++.dg/dfp/mangle-2.C: New test. * g++.dg/dfp/mangle-3.C: New test. * g++.dg/dfp/mangle-4.C: New test. * g++.dg/dfp/mangle-5.C: New test. Added: trunk/gcc/testsuite/g++.dg/dfp/44473-1.C trunk/gcc/testsuite/g++.dg/dfp/44473-2.C trunk/gcc/testsuite/g++.dg/dfp/mangle-1.C trunk/gcc/testsuite/g++.dg/dfp/mangle-2.C trunk/gcc/testsuite/g++.dg/dfp/mangle-3.C trunk/gcc/testsuite/g++.dg/dfp/mangle-4.C trunk/gcc/testsuite/g++.dg/dfp/mangle-5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/mangle.c trunk/gcc/testsuite/ChangeLog
[Bug inline-asm/50571] [4.6/4.7 Regression] Undesirable folding in "m" constrained asm operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50571 --- Comment #3 from Jakub Jelinek 2011-09-30 18:14:38 UTC --- Author: jakub Date: Fri Sep 30 18:14:33 2011 New Revision: 179402 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179402 Log: PR inline-asm/50571 * gimple-fold.c (fold_stmt_1) : If input constraints allow mem and not reg, pass true instead of false as second argument to maybe_fold_reference. * gcc.dg/pr50571.c: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/pr50571.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/gimple-fold.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug target/50583] Many __sync_XXX builtin functions are incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50583
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment #2 from Andrew Macleod 2011-09-30
18:25:51 UTC ---
Technically it is closer to
do {
tmp = *ptr;
tmp1 = tmp OP value;
} while (__sync_val_compare_and_swap (ptr, tmp, tmp1) != tmp);
return tmp;
except it uses the new value of tmp from the CAS rather than reloading it
again.
It loops performing OP on the new value of tmp until the CAS is successful.
Functionally it is identical, what is your case where it can't be used?
The only difference I see is that another very hostile process which constantly
changes *ptr may prevent forward progress from ever happening, resulting in an
infinite loop.
At the moment we aren't making any guarantees of forward progress, although I
think at some point we may want to add a flag to the compiler as it becomes
more of an issue. With a flag like that enabled, a CAS loop would not be a
valid implementation.
[Bug target/50583] Many __sync_XXX builtin functions are incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50583
--- Comment #3 from H.J. Lu 2011-09-30 18:37:42
UTC ---
The same problem with
`TYPE __sync_add_and_fetch (TYPE *ptr, TYPE value, ...)'
`TYPE __sync_sub_and_fetch (TYPE *ptr, TYPE value, ...)'
`TYPE __sync_or_and_fetch (TYPE *ptr, TYPE value, ...)'
`TYPE __sync_and_and_fetch (TYPE *ptr, TYPE value, ...)'
`TYPE __sync_xor_and_fetch (TYPE *ptr, TYPE value, ...)'
`TYPE __sync_nand_and_fetch (TYPE *ptr, TYPE value, ...)'
These builtins perform the operation suggested by the name, and
return the new value. That is,
{ *ptr OP= value; return *ptr; }
{ *ptr = ~(*ptr & value); return *ptr; } // nand
[hjl@gnu-33 pr50583]$ cat z.i
int
foo (int *p)
{
return __sync_and_and_fetch (p, 7);
}
[hjl@gnu-33 pr50583]$ gcc -O2 -S z.i
[hjl@gnu-33 pr50583]$ cat z.s
.file"z.i"
.text
.p2align 4,,15
.globlfoo
.typefoo, @function
foo:
.LFB0:
.cfi_startproc
movl(%rdi), %eax
.L2:
movl%eax, %edx
andl$7, %edx
lock cmpxchgl%edx, (%rdi)
jne.L2
movl%edx, %eax
ret
.cfi_endproc
.LFE0:
.sizefoo, .-foo
.ident"GCC: (GNU) 4.6.0 20110603 (Red Hat 4.6.0-10)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-33 pr50583]$
It is
{
tmp = *ptr;
do
{
tmp1 = tmp OP value;
}
while (__sync_val_compare_and_swap (ptr, tmp, tmp1) != tmp);
return tmp1;
}
If *ptr is changed between load and cmpxchg, we get an infinite loop.
[Bug target/50583] Many __sync_XXX builtin functions are incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50583 --- Comment #4 from H.J. Lu 2011-09-30 18:47:21 UTC --- I guess it is OK.
[Bug target/50583] Many __sync_XXX builtin functions are incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50583
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||jakub at gcc dot gnu.org
Resolution||INVALID
--- Comment #5 from Jakub Jelinek 2011-09-30
18:49:29 UTC ---
(In reply to comment #3)
> movl(%rdi), %eax
> .L2:
> movl%eax, %edx
> andl$7, %edx
> lock cmpxchgl%edx, (%rdi)
> jne.L2
> movl%edx, %eax
> It is
>
> {
>tmp = *ptr;
>do
> {
>tmp1 = tmp OP value;
> }
>while (__sync_val_compare_and_swap (ptr, tmp, tmp1) != tmp);
>return tmp1;
> }
>
> If *ptr is changed between load and cmpxchg, we get an infinite loop.
No, you aren't translating the asm correctly back into C.
It is
tmp = *ptr;
do
tmp1 = tmp OP value; tmp2 = tmp;
while ((tmp = __sync_val_compare_and_swap (ptr, tmp2, tmp1) != tmp2);
return tmp1;
because cmpxchgl instruction loads the *ptr value from memory into %eax if the
instruction has been unsuccessful. So, tmp is loaded with the new value for
the next iteration.
[Bug inline-asm/50571] [4.6/4.7 Regression] Undesirable folding in "m" constrained asm operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50571 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Jakub Jelinek 2011-09-30 18:55:11 UTC --- Fixed.
[Bug c/50581] stdarg doesn't support array types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50581
--- Comment #1 from joseph at codesourcery dot com 2011-09-30 19:41:17 UTC ---
There is no possible valid use of passing arrays to va_arg.
In C99, it is never possible for an array to be passed by value to a
function because it will have decayed to a pointer before the call.
Thus, any execution of va_arg with such an argument type results in
undefined behavior, just like calling it with "char" or "float", and
generating a runtime abort (with a compile-time warning) might be
appropriate, as is done for "char" and "float".
In C90, it is technically possible to use va_arg in this case without
undefined behavior. The argument passed to the function would have to be
a non-lvalue array - for example, an array in a structure returned from
another function. The result of va_arg would itself be a non-lvalue
array, which it is not possible to convert to a pointer, so it is not
possible to access the values in the array in any way; all that can be
done is to discard the value (call va_arg for its side effects) or to pass
it to another variadic function.
As far as I know this obscure C90-only use case works correctly (so you
can access arguments after the non-lvalue array using va_arg again, for
example). If you have problems with it, please provide a bug report with
a valid C90 testcase.
E.g.,
#include
typedef char array[1];
struct s { array a; };
struct s f (void);
void g (int a, ...);
void
h (void)
{
g (0, f().a);
}
void
g (int a, ...)
{
va_list ap;
va_start (ap, a);
va_arg (ap, array);
va_end (ap);
}
[Bug tree-optimization/46309] optimization a==3||a==1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46309 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-30 Ever Confirmed|0 |1 --- Comment #6 from Paolo Carlini 2011-09-30 20:10:37 UTC --- Thank for this, Jakub! I'm confirming the issue ;) Shall we close it as fixed for 4.7.0 or would it make sense to backport something?
[Bug c++/44473] iterators already defined for std::vector when using std::decimal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44473 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #15 from Paolo Carlini 2011-09-30 20:12:53 UTC --- Confirmed fixed. Thanks!
[Bug tree-optimization/46309] optimization a==3||a==1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46309 --- Comment #7 from Jakub Jelinek 2011-09-30 20:18:59 UTC --- Well, the original issue isn't fully fixed. If the gimplifier decides to split the conditions into multiple basic blocks, i.e. if it isn't tmp1 = a == 1; tmp2 = a == 3; tmp3 = a == 4; tmp4 = a == 2; tmp5 = tmp1 | tmp2; tmp6 = tmp5 | tmp3; x = tmp6 | tmp4; but instead if (a == 1) goto ; if (a == 3) goto ; if (a == 4) goto ; if (a == 2) goto ; x = 0; goto ; X: x = 1; or similar (e.g. two comparisons BIT_IOR_EXPRed together, then jump), then this optimization isn't performed.
[Bug tree-optimization/46309] optimization a==3||a==1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46309 --- Comment #8 from Paolo Carlini 2011-09-30 20:25:14 UTC --- I see... thanks.
[Bug c++/49949] wrong sign for product of complex and double with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49949 Paolo Carlini changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||paolo.carlini at oracle dot ||com --- Comment #14 from Paolo Carlini 2011-09-30 20:27:36 UTC --- Hug :( We should really distill a much, much smaller snippet and analyze what is really going wrong. Maybe Jakub could help?
[Bug libstdc++/50529] [C++0x] std::vector::erase invokes undefined behavior with empty range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50529 --- Comment #6 from paolo at gcc dot gnu.org 2011-09-30 20:47:17 UTC --- Author: paolo Date: Fri Sep 30 20:47:12 2011 New Revision: 179403 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179403 Log: 2011-09-30 François Dumont * include/debug/vector (vector<>::erase(iterator, iterator)): Check iterators equality using normal iterators. * include/debug/deque (deque<>::erase(iterator, iterator)): Likewise. 2011-09-30 Paolo Carlini PR libstdc++/50529 * include/bits/vector.tcc (vector<>::erase(iterator, iterator)): Fix to do nothing if the range is empty. * include/bits/stl_bvector.h: Likewise. * include/bits/deque.tcc: Likewise. * include/debug/vector: Adjust. * include/debug/deque: Likewise. * testsuite/23_containers/vector/modifiers/erase/50529.cc: New. * testsuite/23_containers/deque/modifiers/erase/50529.cc: Likewise. * testsuite/23_containers/deque/modifiers/erase/3.cc: Adjust. Added: branches/gcc-4_6-branch/libstdc++-v3/testsuite/23_containers/deque/modifiers/erase/50529.cc branches/gcc-4_6-branch/libstdc++-v3/testsuite/23_containers/vector/modifiers/erase/50529.cc Modified: branches/gcc-4_6-branch/libstdc++-v3/ChangeLog branches/gcc-4_6-branch/libstdc++-v3/include/bits/deque.tcc branches/gcc-4_6-branch/libstdc++-v3/include/bits/stl_bvector.h branches/gcc-4_6-branch/libstdc++-v3/include/bits/vector.tcc branches/gcc-4_6-branch/libstdc++-v3/include/debug/deque branches/gcc-4_6-branch/libstdc++-v3/include/debug/vector branches/gcc-4_6-branch/libstdc++-v3/testsuite/23_containers/deque/modifiers/erase/3.cc
[Bug libstdc++/50529] [C++0x] std::vector::erase invokes undefined behavior with empty range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50529 Paolo Carlini changed: What|Removed |Added Target Milestone|4.7.0 |4.6.2 --- Comment #7 from Paolo Carlini 2011-09-30 20:48:32 UTC --- Fixed in 4.6.2 too.
[Bug c++/38980] [4.4/4.5/4.6/4.7 Regression] missing -Wformat warning on const char format string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38980 --- Comment #3 from Paolo Carlini 2011-09-30 21:15:16 UTC --- Thanks a lot for the analysis Jakub, seems easy to fix now.
[Bug target/50583] Many __sync_XXX builtin functions are incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50583 --- Comment #6 from Andi Kleen 2011-09-30 23:35:29 UTC --- Can't say I'm a fan of adding such a heavy weight sequence into an intrinsic. Maybe better to simply leave out the intrinsics that cannot be implemented with loops? If someone wants a loop they better open code it. It would be nice if you implemented the ors, nands and ands with bts, btr etc if the second argument is a constant and only has one bit set.
