[Bug c/44598] -Wunused-variable miss 'static const char x[] = ;'
--- Comment #4 from jakub at gcc dot gnu dot org 2010-06-21 06:11 --- FYI, this has nothing to do with the new -Wunused-but-set-* warnings, the initialization in the definition isn't counted as set. This is something the old -Wunused-variable warning reports/doesn't report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44598
[Bug fortran/44604] New: Wrong run-time checks with VALUE dummies and pointer/allocatable actuals
Reported by Michael Briggs at http://gcc.gnu.org/ml/fortran/2010-06/msg00205.html Checking fails for a zero-initialized pointers/allocatable scalar variable/array element passed to a dummy argument with VALUE attribute. For the following program, it fails for -fcheck=all: program TestSmall implicit none integer, allocatable :: ptrVar allocate ( ptrVar ) ptrVar = 0 ! if changed to 1, the problem goes away call test(ptrVar) contains subroutine test(n) integer, VALUE :: n end subroutine test end program TestSmall -- Summary: Wrong run-time checks with VALUE dummies and pointer/allocatable actuals Product: gcc Version: 4.6.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=44604
[Bug fortran/44604] Wrong run-time checks with VALUE dummies and pointer/allocatable actuals
--- Comment #1 from burnus at gcc dot gnu dot org 2010-06-21 07:13 ---
Seemingly the allocated/associated check
cond = fold_build2 (EQ_EXPR, boolean_type_node, parmse.expr,
fold_convert (TREE_TYPE (parmse.expr),
null_pointer_node));
in trans-expr.c's gfc_conv_procedure_call accesses the value of the variable
and not its location as parmse.expr is already dereferenced via gfc_conv_expr,
called by
else if (fsym fsym-attr.value)
{
// [...]
gfc_conv_expr (parmse, e);
}
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44604
[Bug fortran/44604] Wrong run-time checks with VALUE dummies and pointer/allocatable actuals
--- Comment #2 from burnus at gcc dot gnu dot org 2010-06-21 07:24 --- Reminder: Same problem occurs when calling with %VAL(actual_arg). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44604
[Bug fortran/44602] [F2008] EXIT: Jump to end of construct
--- Comment #2 from burnus at gcc dot gnu dot org 2010-06-21 07:41 --- +else if (sym == p-sym) One should check that this does the right thing for do block exit end block end do as this should leave the DO construct and not only the BLOCK construct (to be compatible with older Fortran standard, where EXIT was relative to DO). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44602
[Bug rtl-optimization/44605] New: Wrong floating point on
-- Summary: Wrong floating point on Product: gcc Version: 4.4.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gcc at breakpoint dot cc GCC build triplet: powerpc-linux-gnuspe GCC host triplet: powerpc-linux-gnuspe GCC target triplet: powerpc-linux-gnuspe http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44605
[Bug rtl-optimization/44605] Wrong floating point on
--- Comment #1 from gcc at breakpoint dot cc 2010-06-21 07:56 --- was too early -- gcc at breakpoint dot cc changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID Summary|Wrong floating point on |Wrong floating point on http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44605
[Bug c++/44328] switch/case optimization produces an invalid lookup table index
--- Comment #19 from jamborm at gcc dot gnu dot org 2010-06-21 08:29 --- (In reply to comment #16) (In reply to comment #15) ... I cannot reproduce the problem. I can send you either the compiler binaries (hosts: cygwin/linux i386/linux x64/darwin x64) or the configuration options to build the binutils and the compiler for the arm-eabi target, if you want to. Configuration options for i386-linux and x86_64-linux hosts for both binutils and gcc would be very much appreciated. I'll see what I can do then. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
[Bug c++/44590] [4.6 Regression] Revision 159362 caused multiple failures on the libstdc++-v3 tests
--- Comment #1 from jamborm at gcc dot gnu dot org 2010-06-21 08:35 --- Honza, does this look familiar to you? -- jamborm at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at ucw dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44590
[Bug c++/44590] [4.6 Regression] Revision 159362 caused multiple failures on the libstdc++-v3 tests
--- Comment #2 from hubicka at ucw dot cz 2010-06-21 08:44 --- Subject: Re: [4.6 Regression] Revision 159362 caused multiple failures on the libstdc++-v3 tests I was fixing bug like this, where function was extern inline and had address taken in the unit. Inliner removed offline copy of the function but we need to keep it around so ipa-ref can point to it. I guess this is your problem too. ipa-inline should understand that even if offline copy goes away, the cgraph node needs to be preserved when there are some references of it. cgraph_can_remove_if_no_direct_calls_p already tests for address_taken, so why the offline copy disappears? Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44590
[Bug fortran/44604] Wrong run-time checks with VALUE dummies and pointer/allocatable actuals
--- Comment #3 from dominiq at lps dot ens dot fr 2010-06-21 08:55 --- Is it not a duplicate of pr35203? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44604
[Bug fortran/44595] INTENT of argeuments to intrinsics procedure not check
--- Comment #2 from janus at gcc dot gnu dot org 2010-06-21 09:02 --- cf. also PR40039 -- janus at gcc dot gnu dot org changed: What|Removed |Added CC||janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44595
[Bug tree-optimization/44606] New: Wrong SPE floating point during computation
I attached two testcase which is stripped down graphicsmagick code. tc-resize2.c has a few instructions more than tc-resize.c. I belive the bug is the same. gcc -o tc2 -O0 -Wall -Wextra tc-resize.c gcc -o tc2 -O2 -Wall -Wextra tc-resize.c ( ./tc0 ; echo -; ./tc2 ) .19 2484.00 .21 2700.00 .23 2916.00 .24 3132.00 .26 3348.00 - .0 2484.00 .0 2700.00 .0 2916.00 .0 3132.00 .0 3348.00 gcc -o tc20 -O0 -Wall -Wextra tc-resize2.c gcc -o tc22 -O2 -Wall -Wextra tc-resize2.c ( ./tc20 ; echo -; ./tc22 ) .26 3264.00 .28 3520.00 .30 3776.00 .32 4032.00 .34 4288.00 - .14 1734.00 .15 1870.00 .16 2006.00 .17 2142.00 .18 2278.00 Now here is stripped down output of the assembly file: MinifyImage: evstdd 26,88(11) .L9: li 26,0 stw 26,64(1) .L11: #APP # 105 tc-resize.c 1 nop # 0 2 #NO_APP lis 19,@ha efdmul 5,9,26 r26 should be 0.0078125 but is 0 r26 bits 32..63 are, dunno about 0..31 la 19,@l(19) evldd 19,0(19) r19 is 0.5 efdadd 5,5,19 r5 is expected to be .5 efdctuiz 5,5r5 is 0 rlwinm 5,5,0,0xff #APP # 107 tc-resize.c 1 nop # 0 2 #NO_APP evmergehi 6,9,9 mr 7,9 mr 8,7 mr 7,6 crxor 6,6,6 that should be 9,9,9 but is a different issue :) bl fprintf # r5 int (bad), r6 pad, r7 r8 double r26 is zero and that is wrong. I belive 1/128.0 gets replaced by 0.0 and optimized. Sebastian -- Summary: Wrong SPE floating point during computation Product: gcc Version: 4.4.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gcc at breakpoint dot cc GCC build triplet: powerpc-linux-gnuspe GCC host triplet: powerpc-linux-gnuspe GCC target triplet: powerpc-linux-gnuspe http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44606
[Bug tree-optimization/44606] Wrong SPE floating point during computation
--- Comment #1 from gcc at breakpoint dot cc 2010-06-21 09:10 --- Created an attachment (id=20950) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20950action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44606
[Bug tree-optimization/44606] Wrong SPE floating point during computation
--- Comment #2 from gcc at breakpoint dot cc 2010-06-21 09:10 --- Created an attachment (id=20951) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20951action=view) slightly extended tc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44606
[Bug tree-optimization/44606] Wrong SPE floating point during computation
--- Comment #3 from gcc at breakpoint dot cc 2010-06-21 09:11 --- Created an attachment (id=20952) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20952action=view) -S output of the first tc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44606
[Bug fortran/44604] Wrong run-time checks with VALUE dummies and pointer/allocatable actuals
--- Comment #4 from burnus at gcc dot gnu dot org 2010-06-21 09:13 --- (In reply to comment #3) Is it not a duplicate of pr35203? No. In this bug (PR 44604) one is in the caller and there one can distinguish between address and value of a variable and the fix is relatively simple (though requires some thinking and re-shoveling). By contrast, PR 35203 requires a special handling of OPTIONAL + VALUE dummies, where both the caller and the callee need to be involved by passing additional information and making use of them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44604
[Bug target/44603] out of range branch generated in thumb code.
--- Comment #2 from mikpe at it dot uu dot se 2010-06-21 09:47 --- Seen also with 4.6 and 4.5 arm-unknown-linux-gnueabi toolchains at -O0, 4.4 and 4.3 don't trigger it. I'm pretty sure I've seen another thumb out of range branch PR not too long ago. -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44603
[Bug target/44603] out of range branch generated in thumb code.
--- Comment #3 from mikpe at it dot uu dot se 2010-06-21 10:09 --- Dupe of PR43961? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44603
[Bug fortran/44541] [OOP] wrong code for polymorphic variable with INTENT(OUT)/Alloc w/ MOLD
--- Comment #2 from janus at gcc dot gnu dot org 2010-06-21 10:18 --- My first idea to fix this was to add a new field to the vtabs, let's call it $def_init, which would be the fourth field in the vtab structure (after $hash, $size and $extends), and would contain the default initialization values for the type. However, this approach does not work, since the field needed for default initialization would have to be of the derived type which the vtab belongs to. This however can have different sizes, so that the PPCs in the vtab will not be aligned any more for extended types, which messes up dynamic dispatch. Alternatives: (1) make $def_init a pointer (problem: initialization of $def_init itself) (2) add standalone variables a la type_t$def_init to carry default initialization for each type (3) ...? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44541
[Bug debug/31230] debug information depends on gc parameters
--- Comment #4 from tjvries at xs4all dot nl 2010-06-21 10:20 ---
Created an attachment (id=20953)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20953action=view)
minimal test case of 14 lines, cut down from varasm.i
I also ran into this bug, while building gcc 4.3.5 for x86_64-unknown-linux-gnu
with make {CFLAGS,BOOT_CFLAGS,STAGE1_CFLAGS}=\-g3\ -O0\ -dH\.
I managed to minimized the test case down to 14 lines.
The difference in debug info can be reproduced using:
...
$ cc1 varasm.i -O0 -g -quiet -o varasm.s
$ cc1 varasm.i -O0 -g -quiet -o varasm.s.0.0 --param ggc-min-expand=0 --param
ggc-min-heapsize=0
...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31230
[Bug debug/31230] debug information depends on gc parameters
--- Comment #5 from tjvries at xs4all dot nl 2010-06-21 10:32 --- Created an attachment (id=20954) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20954action=view) naive patch. run callbacks on hashtable entries exhaustively before deleting Furthermore, I investigated why this problem does not occur with 4.4.0 onwards, and I found that this is due to the fact that -funit-at-a-time is hard coded to on for 4.4.0, which causes f1 to be live at the same time as f3 (no cgraph_release_function_body() in between). An easy workaround for this problem in 4.3.5 is therefore -funit-at-a-time. I also managed to reproduce the problem for -gstabs. The patch from comment 3 works indeed, but not for -gstabs, which makes a lot of sense since the patch is dwarf specific. Of course we might attempt to fix the stab format (and possible others) in a similar way, but the fact that the fix needs to be repeated made me wonder whether the problem had to be dealt with at another level than specific debug formats. Let's take a look at what happens exactly during garbage collection in between f1 and f3 in mark_roots(): - gt_ggc_rtab is traversed, and neither array type nor index type is marked live - gt_ggc_cache_rtab is traversed, in particular type_hash_table, and the hash entry with the index type is hit (before the entry with the array type, but this is non-deterministic) and processed by ggc_htab_delete(). The entry is not considered live, and consequently the entry is cleared. - next the entry with the array type is hit and processed by ggc_htab_delete(). The entry is considered live due to TYPE_SYMTAB_POINTER (type). Consequently the callback is called, marking the entry and everything reachable from it live, including the index type. Unfortunately, the hash entry for the index type is already gone. During parsing of f3, a new index type equivalent to the old one is created, but type_hash_canon cannot find the old index type in the hash table (since that entry has been deleted), so the new index type is now a canonical type, and gets an entry in the type_hash_table. Next, a new array type equivalent to the old one is created, but type_hash_canon cannot find the old array type, even though the entry has not been deleted. The new array type has a different index type than the old array type, and consequently the hashcode for the new array type is different than the hascode for the old array type, so the old array type is not found. The new array type is now also a canonical type, and gets an entry in the type_hash_table. The old index type, the old array type and the hash table entry associated with the old array type are now unused but not freed. The question is whether to blame this on - invalid use of the garbage collection infrastructure. Using the if_marked construction to mark an object live, is only allowed if everything reachable from that object is also live. - the garbage collection infrastructure itself. If the if_marked construction is used to mark an object live, the garbage collection infrastructure should mark everything that is reachable from that object also as live. The patch in comment 3 seems to take the first choice. I decided to explore the second choice, and created a naive patch of ggc_mark_roots(). It solves the inconsistent debug info problem, both for dwarf2 and for stabs. I did a debug bootstrap build (-g3 -O0 -dH) with the patch and ran the testsuites (gcc, objc, gfortran, g++, libgomp, libstdc++, libjava, libmudflap, libffi), with the same results as a normal bootstrap build without the patch, so the patch looks sane at least. This is my first time looking into the gcc garbage collector, so I'd appreciate some comments on my findings. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31230
[Bug c++/44328] switch/case optimization produces an invalid lookup table index
--- Comment #20 from mikpe at it dot uu dot se 2010-06-21 10:44 --- (In reply to comment #19) Configuration options for i386-linux and x86_64-linux hosts for both binutils and gcc would be very much appreciated. I don't know if you can build the c++ frontend without libstdc++, but the latter seem to require a libc, so I had to do a 4-step build with newlib: Common options for binutils, gcc, and newlib: --target=arm-unknown-eabi --prefix=/../cross-arm-eabi Initial C-only gcc: --enable-languages=c --disable-libssp Use that to build and install newlib. Final gcc with c++: --enable-languages=c,c++ --with-newlib -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
[Bug c++/44607] New: basic template struct has no direct access to members of a basic parent template struct
the following program with a basic template struct which inherit another basic
template struct does not compile:
g++ bug_template_template.cc
bug_template_template.cc: In member function âvoid UC::f()â:
bug_template_template.cc:6: error: âiâ was not declared in this scope
the output of g++ -v -save-temps follows the source file
the preprocessed file .ii is at the end of this report
template class C struct T{
int i;
C c;
};
template class C struct U:TC{
void f(){i=0;}
};
g++ -v -save-temps bug_template_template.cc
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.4-3'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--with-arch-32=i486 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.4 (Debian 4.4.4-3)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
/usr/lib/gcc/x86_64-linux-gnu/4.4.4/cc1plus -E -quiet -v -D_GNU_SOURCE
bug_template_template.cc -mtune=generic -fpch-preprocess -o
bug_template_template.ii
ignoring nonexistent directory /usr/local/include/x86_64-linux-gnu
ignoring nonexistent directory
/usr/lib/gcc/x86_64-linux-gnu/4.4.4/../../../../x86_64-linux-gnu/include
ignoring nonexistent directory /usr/include/x86_64-linux-gnu
#include ... search starts here:
#include ... search starts here:
/usr/include/c++/4.4
/usr/include/c++/4.4/x86_64-linux-gnu
/usr/include/c++/4.4/backward
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/4.4.4/include
/usr/lib/gcc/x86_64-linux-gnu/4.4.4/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
/usr/lib/gcc/x86_64-linux-gnu/4.4.4/cc1plus -fpreprocessed
bug_template_template.ii -quiet -dumpbase bug_template_template.cc
-mtune=generic -auxbase bug_template_template -version -o
bug_template_template.s
GNU C++ (Debian 4.4.4-3) version 4.4.4 (x86_64-linux-gnu)
compiled by GNU C version 4.4.4, GMP version 4.3.2, MPFR version
2.4.2-p1.
GGC heuristics: --param ggc-min-expand=57 --param ggc-min-heapsize=51739
GNU C++ (Debian 4.4.4-3) version 4.4.4 (x86_64-linux-gnu)
compiled by GNU C version 4.4.4, GMP version 4.3.2, MPFR version
2.4.2-p1.
GGC heuristics: --param ggc-min-expand=57 --param ggc-min-heapsize=51739
Compiler executable checksum: a92c574e76687c18572fdbea97434cec
bug_template_template.cc: In member function âvoid UC::f()â:
bug_template_template.cc:6: error: âiâ was not declared in this scope
cat bug_template_template.ii
# 1 bug_template_template.cc
# 1 built-in
# 1 command-line
# 1 bug_template_template.cc
template class C struct T{
int i;
C c;
};
template class C struct U:TC{
void f(){i=0;}
};
--
Summary: basic template struct has no direct access to members of
a basic parent template struct
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at razorcam dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44607
[Bug fortran/43945] [OOP] Derived type with GENERIC: resolved to the wrong specific TBP
--- Comment #20 from janus at gcc dot gnu dot org 2010-06-21 11:01 ---
(In reply to comment #14)
The attached variation of generic_23 still does not work.
... and the dump shows why:
if (vtab$foo2.get == 0B)
{
vtab$vtype$foo2$get.getit = getit;
vtab$foo2.get = vtab$vtype$foo2$get;
vtab$foo2.getit = (integer(kind=4) (*T42b) (void)) getit2;
vtab$foo2.doit = (void (*T62) (void)) doit2;
vtab$vtype$foo2$do.doit = doit;
vtab$foo2.do = vtab$vtype$foo2$do;
}
The specific PPCs of 'foo2' point to the right procedures, but their generic
counterparts don't.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43945
[Bug c++/44607] basic template struct has no direct access to members of a basic parent template struct
--- Comment #1 from paolo dot carlini at oracle dot com 2010-06-21 11:07 --- Why, before filing pretty trivial PRs don't you search a bit Bugzilla and the docs? In this specific case, just use this-i or follow http://gcc.gnu.org/gcc-3.4/changes.html. In general, I would suggest seriously studying any good book treating templates (eg, Vandevoorde Josuttis). -- paolo dot carlini at oracle dot com changed: What|Removed |Added Severity|major |normal Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44607
[Bug c++/44607] basic template struct has no direct access to members of a basic parent template struct
--- Comment #2 from redi at gcc dot gnu dot org 2010-06-21 11:15 --- I already suggested that link in Bug 44559 comment 2, please use something other than GCC's Bugzilla to learn the differences between standard C++ and what used to be accepted by various old compilers. You can also use the online Comeau compiler at http://www.comeaucomputing.com/tryitout/ to test your assumptions. If Comeau and GCC both give an error then you can be 99.9% sure the problem is in your code not the compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44607
[Bug c++/44328] switch/case optimization produces an invalid lookup table index
--- Comment #21 from mikpe at it dot uu dot se 2010-06-21 11:18 --- (In reply to comment #20) (In reply to comment #19) Configuration options for i386-linux and x86_64-linux hosts for both binutils and gcc would be very much appreciated. I don't know if you can build the c++ frontend without libstdc++, ... You can. Just build gcc with --target=arm-unknown-eabi --enable-languages=c,c++ --disable-libstdc++-v3 --disable-libssp. No newlib needed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
[Bug middle-end/42834] memcpy folding overeager
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-06-21 11:18 --- Subject: Bug 42834 Author: rguenth Date: Mon Jun 21 11:18:26 2010 New Revision: 161067 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161067 Log: 2010-06-21 Richard Guenther rguent...@suse.de PR middle-end/42834 * builtins.c (fold_builtin_memory_op): Use ref-all types for all memcpy foldings. * expr.c (store_expr): Handle MEM_REFs from STRING_CSTs. testsuite/ * c-c++-common/torture/pr42834.c: New testcase. * gcc.dg/tree-prof/stringop-1.c: Adjust. * gfortran.dg/array_memcpy_3.f90: Likewise. * gfortran.dg/array_memcpy_4.f90: Likewise. Added: branches/mem-ref2/gcc/testsuite/c-c++-common/torture/pr42834.c Modified: branches/mem-ref2/gcc/ChangeLog.mem-ref2 branches/mem-ref2/gcc/builtins.c branches/mem-ref2/gcc/expr.c branches/mem-ref2/gcc/testsuite/gcc.dg/tree-prof/stringop-1.c branches/mem-ref2/gcc/testsuite/gfortran.dg/array_memcpy_3.f90 branches/mem-ref2/gcc/testsuite/gfortran.dg/array_memcpy_4.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42834
[Bug other/43480] build: random timestamps have multilib conflicts
--- Comment #2 from jan dot kratochvil at redhat dot com 2010-06-21 11:22 --- Checked-in. Forgot to place the PR # there. r161066 | jkratoch | 2010-06-21 13:16:18 +0200 (Mon, 21 Jun 2010) | 7 lines gcc/ * Makefile.in (POD2MAN): Provide --date from $(DATESTAMP). libjava/classpath/ * doc/Makefile.am (POD2MAN): Provide --date from ChangeLog. * doc/Makefile.in: Regenerate. -- jan dot kratochvil at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43480
[Bug middle-end/44608] New: unspecified signed overflow applied to unsigned int
As discussed in
http://gcc.gnu.org/ml/gcc-help/2010-06/msg00191.html
I am filing a PR for the following piece of C:
int abssat2 (int x)
{
unsigned int y = x;
if (x 0)
y = -y;
if (y = 0x8000)
y--;
return y;
}
Code looks fine until pass CE1 which introduces ABS rtx for the first
comparison (ifcvt.c:noce_try_abs).
Pass insn combine then calls combine.c:combine_simplify_rtx() which calls
simplify_rtx.c:simplify_relational_operation (code=LT, mode=SImode,
cmp_mode=SImode, op0=(abs:SI (reg:SI)), op1=(const_int 0))
and the latter removes the second comparison against 0x8000.
As this problem occurs on a non-standard target, let me know if I con you
provide with any additional information.
--
Summary: unspecified signed overflow applied to unsigned int
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: avr at gjlay dot de
GCC build triplet: pc-linux
GCC host triplet: pc-linux
GCC target triplet: private
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44608
[Bug middle-end/44608] unspecified signed overflow applied to unsigned int
--- Comment #1 from avr at gjlay dot de 2010-06-21 11:26 --- Created an attachment (id=20955) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20955action=view) Dump for .c.123t.optimized Dump for .c.123t.optimized -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44608
[Bug middle-end/44608] unspecified signed overflow applied to unsigned int
--- Comment #2 from avr at gjlay dot de 2010-06-21 11:28 --- Created an attachment (id=20956) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20956action=view) Dump for .c.128r.expand Dump for .c.128r.expand -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44608
[Bug middle-end/44608] unspecified signed overflow applied to unsigned int
--- Comment #3 from avr at gjlay dot de 2010-06-21 11:28 --- Created an attachment (id=20957) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20957action=view) Dump for .c.141r.ce1 Dump for .c.141r.ce1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44608
[Bug other/43480] build: random timestamps have multilib conflicts
--- Comment #3 from jan dot kratochvil at redhat dot com 2010-06-21 11:29 --- The fastjar part filed as: https://sourceforge.net/tracker/?func=detailaid=3019015group_id=426atid=100426 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43480
[Bug middle-end/44608] unspecified signed overflow applied to unsigned int
--- Comment #4 from avr at gjlay dot de 2010-06-21 11:30 --- Created an attachment (id=20958) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20958action=view) Dump for .c.159r.combine Dump for .c.159r.combine -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44608
[Bug middle-end/44608] unspecified signed overflow applied to unsigned int
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-06-21 11:38 --- It is folding from the frontend that changes if (y = 0x8000) to if ((int) y 0) (see code == LT instead of code == GEU) But the main issue is that y = -y to abs is bogus (but we can't easily tell that as on RTL operands do not have a signedness). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2010-06-21 11:38:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44608
[Bug other/43480] build: random timestamps have multilib conflicts
--- Comment #4 from jan dot kratochvil at redhat dot com 2010-06-21 11:46 --- http://gcc.gnu.org/ml/gcc-patches/2010-06/msg01999.html Wrongly patched libjava/classpath/ChangeLog , therefore fixed it up: r161069 | jkratoch | 2010-06-21 13:40:02 +0200 (Mon, 21 Jun 2010) | 3 lines Move the entry from libjava/classpath/ ChangeLog to ChangeLog.gcj as it is a local change. Reported by Jakub Jelinek, approved by Mark Wielaard. Index: libjava/classpath/ChangeLog Index: libjava/classpath/ChangeLog.gcj -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43480
[Bug c++/44609] New: Invalid code causes ICE
The following code is reduced from a usage of boost, where one word was spelt incorrectly. My code reducer has done some very unusual things while reducing the size of the test case. The following code, on my code, causes g++ to spend 1 minute outputting 16 million lines, then eventually ICEing. It seems to be a problem with recursive templates, but it would be nicer if g++ gave up a little earlier. Confirmed on g++ 4.4 and svn trunk. -- Summary: Invalid code causes ICE Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: chris at bubblescope dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44609
[Bug c++/44609] Invalid code causes ICE
--- Comment #1 from chris at bubblescope dot net 2010-06-21 11:50 --- Created an attachment (id=20959) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20959action=view) ICEing example -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44609
[Bug middle-end/44608] unspecified signed overflow applied to unsigned int
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-06-21 11:50 ---
int __attribute__((noinline))
abssat2 (int x)
{
unsigned int y = x;
if (x 0)
y = -y;
if (y = 0x8000)
y--;
return y;
}
extern void abort (void);
int main()
{
if (abssat2 (0x8000) != 0x7fff)
abort ();
return 0;
}
does not fail on x86_64 or i?86.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44608
[Bug c++/44609] Invalid code causes ICE
--- Comment #2 from paolo dot carlini at oracle dot com 2010-06-21 11:56 --- Are you on x86_64-linux? I can't get it to ICE, the error messages just go on forever... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44609
[Bug c++/44609] Invalid code causes ICE
--- Comment #3 from chris at bubblescope dot net 2010-06-21 12:10 --- Many apologises, the computer had a ulimit set which I had not noticed. Yes, I also get an infinite loop rather than an ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44609
[Bug middle-end/44608] unspecified signed overflow applied to unsigned int
--- Comment #7 from avr at gjlay dot de 2010-06-21 12:27 --- (In reply to comment #5) It is folding from the frontend that changes if (y = 0x8000) to if ((int) y 0) (see code == LT instead of code == GEU) But the main issue is that y = -y to abs is bogus (but we can't easily tell that as on RTL operands do not have a signedness). Both transformation are ok from the target's point of view. The bad thing is that undefinedness is propagated to RTL which is supposed to be an algebraic formulation of the target's instruction set. But in this case RTL is treated like a low level representation of C (or any other language gcc supports). To reproduce the problem it seems essential that there is an abssi2 insn in the md. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44608
[Bug preprocessor/39213] [4.4/4.5/4.6 regression] Preprocessor ICE with -m64 and --traditional-cpp
--- Comment #3 from ro at gcc dot gnu dot org 2010-06-21 12:35 --- Updated summary (you list the regressed branches to fix, not the working one). -- ro at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.4.0 4.5.0 |4.4.5 4.5.1 4.6.0 Known to work|3.4.3 |3.4.6 Summary|Regression [3.4.3] |[4.4/4.5/4.6 regression] |Preprocessor ICE with -m64 |Preprocessor ICE with -m64 |and --traditional-cpp |and --traditional-cpp Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39213
[Bug fortran/44448] 32-bit gfortran.dg/atan2_1.f90 fails on Solaris 1[01]/x86 at -O0
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-21 12:47 --- Subject: Re: 32-bit gfortran.dg/atan2_1.f90 fails on Solaris 1[01]/x86 at -O0 --- Comment #6 from kargl at gcc dot gnu dot org 2010-06-16 21:51 --- (In reply to comment #5) This makes no sense at all. Rainer, I'm really sorry if it seems that I'm shooting questions a bit at random, but I have a hard time imagining how to narrow it down. Can you try the following equivalent C code (at -O0): Sure: same differences as in the Fortran case: -4.35483e-08 -4.35483e-08 -1.08095e-16 -1.08095e-16 4.33013e-08 4.33013e-08 4.38018e-17 4.38018e-17 3.05453e-08 3.05453e-08 3.33934e-17 3.33934e-17 2.96684e-08 2.96684e-08 -5.76796e-17 -5.76796e-17 4.87235e-08 4.87235e-08 -9.40003e-17 -9.40003e-17 -1.70395e-08 -1.70395e-08 2.55872e-17 2.55872e-17 1.2215e-09 1.2215e-09 -3.88144e-17 -3.88144e-17 2.30691e-08 2.30691e-08 -2.1684e-18 -2.1684e-18 -1.41206e-08 -1.41206e-08 -8.18573e-18 -8.18573e-18 2.18557e-08 2.18557e-08 -3.06287e-17 -3.06287e-17 Right now, the only thing I can see make sense is numerically instability in the libm. Also, how are atan2f and atan2 defined in the system's math.h header? Do they have simple prototypes? Are they actually macros? The declarations are in iso/math_c99.h: iso/math_c99.h: extern float atanf __P((float)); extern float atan2f __P((float, float)); #if !defined(__cplusplus) #pragma does_not_read_global_data(acosf, asinf, atanf, atan2f) #pragma does_not_write_global_data(acosf, asinf, atanf, atan2f) #if defined(__MATHERR_ERRNO_DONTCARE) #pragma no_side_effect(acosf, asinf, atanf, atan2f) Does -ffloat-store change the outcome? This looks to possibly be an excess precision problem and the difference between something in a register and main memory. Indeed: with -ffloat-store, the test program only prints 0s. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8
[Bug target/44575] [4.5/4.6 Regression] __builtin_va_arg overwrites into adjacent stack location
--- Comment #3 from jakub at gcc dot gnu dot org 2010-06-21 12:49 --- Created an attachment (id=20960) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20960action=view) gcc46-pr44575.patch Untested fix. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44575
[Bug debug/44610] New: VTA produces wrong variable location information
If i compile the attached testcase for picochip under -O2, i get the following location information for variable arg0 in main. .ascii 16#61# 16#72# 16#67# 16#30# 16#0# ; arg0\0 .initByte 0x1 .initByte 0x2a .unalignedInitLong 0x9e .initByte 0xc .initByte 0x5b .initByte 0x93 .uleb128 0x2 .initByte 0x5b .initByte 0x93 .uleb128 0x2 .initByte 0x5b .initByte 0x93 .uleb128 0x2 .initByte 0x5b .initByte 0x93 .uleb128 0x2 .uleb128 0xc .unalignedInitLong _picoMark_Ldebug_ranges0+0xc .uleb128 0xa which my dwarflib reader translates to mean 0x42f (19) Lexical Block: Address Ranges: [0x18, 0x8d) [0x94, 0x99) 0x434 (20) Data: Name: arg0 Type: 0xe0 Is External: false Location: DW_OP_reg11 DW_OP_piece: 2 DW_OP_reg11 DW_OP_piece: 2 DW_OP_reg11 DW_OP_piece: 2 DW_OP_reg11 DW_OP_piece: 2 R11 obviously does not contain all 4 piece os this 8-byte variable (a register is 16-bit in picochip). I have tried to see if this was bug 43982, but the mainline as of 20Jun with fix for that bug still reproduces this problem. The problem with this is that it doesn't actually say variable value is not present, which is generally okay with -O2. It just gives wrong value silently! Can you have a look at this, please? I will attach the source file and the assembly. Please ask me if you need any other information. -- Summary: VTA produces wrong variable location information Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hariharans at picochip dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: picochip-unknown-none http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44610
[Bug debug/44610] VTA produces wrong variable location information
--- Comment #1 from hariharans at picochip dot com 2010-06-21 13:55 --- Created an attachment (id=20961) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20961action=view) The test sourcecode -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44610
[Bug c++/44607] basic template struct has no direct access to members of a basic parent template struct
--- Comment #3 from gcc at razorcam dot com 2010-06-21 13:55 --- Sorry again. I am reading again the ISO c++ standard in order to avoid invalid bug reports. It should occupy me for some time. Is there a c++ lint program that could help you when you don't know all the tricks of the full standard yet? Obviously g++ error messages are not meant to replace a c++ lint. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44607
[Bug debug/44610] VTA produces wrong variable location information
--- Comment #2 from hariharans at picochip dot com 2010-06-21 13:56 --- Created an attachment (id=20962) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20962action=view) The test assembly -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44610
[Bug debug/44610] VTA produces wrong variable location information
--- Comment #3 from hariharans at picochip dot com 2010-06-21 13:59 --- In my first comment, bug 43982 should have been bug 43983 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44610
[Bug c++/44607] basic template struct has no direct access to members of a basic parent template struct
--- Comment #4 from manu at gcc dot gnu dot org 2010-06-21 14:00 --- (In reply to comment #2) You can also use the online Comeau compiler at http://www.comeaucomputing.com/tryitout/ to test your assumptions. If Comeau and GCC both give an error then you can be 99.9% sure the problem is in your code not the compiler. Perhaps it would be more useful if the bug reporting instructions would mention this advice. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44607
[Bug c++/44609] Invalid template code causes infinite loop of error messages
--- Comment #4 from manu at gcc dot gnu dot org 2010-06-21 14:03 --- And what is the difference between an ICE and an infinite loop? Both seem to be internal errors of the compiler. -- 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 Keywords||ice-on-invalid-code Last reconfirmed|-00-00 00:00:00 |2010-06-21 14:03:26 date|| Summary|Invalid code causes ICE |Invalid template code causes ||infinite loop of error ||messages http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44609
[Bug fortran/40632] Support F2008's contiguous attribute
--- Comment #3 from burnus at gcc dot gnu dot org 2010-06-21 14:16 --- Subject: Bug 40632 Author: burnus Date: Mon Jun 21 14:15:56 2010 New Revision: 161079 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161079 Log: 2010-06-20 Tobias Burnus bur...@net-b.de PR fortran/40632 * interface.c (compare_parameter): Add gfc_is_simply_contiguous checks. * symbol.c (gfc_add_contiguous): New function. (gfc_copy_attr, check_conflict): Handle contiguous attribute. * decl.c (match_attr_spec): Ditto. (gfc_match_contiguous): New function. * resolve.c (resolve_fl_derived, resolve_symbol): Handle contiguous. * gfortran.h (symbol_attribute): Add contiguous. (gfc_is_simply_contiguous): Add prototype. (gfc_add_contiguous): Add prototype. * match.h (gfc_match_contiguous): Add prototype. * parse.c (decode_specification_statement, decode_statement): Handle contiguous attribute. * expr.c (gfc_is_simply_contiguous): New function. * dump-parse-tree.c (show_attr): Handle contiguous. * module.c (ab_attribute, attr_bits, mio_symbol_attribute): Ditto. * trans-expr.c (gfc_add_interface_mapping): Copy attr.contiguous. * trans-array.c (gfc_conv_descriptor_stride_get, gfc_conv_array_parameter): Handle contiguous arrays. * trans-types.c (gfc_build_array_type, gfc_build_array_type, gfc_sym_type, gfc_get_derived_type, gfc_get_array_descr_info): Ditto. * trans.h (gfc_array_kind): Ditto. * trans-decl.c (gfc_get_symbol_decl): Ditto. 2010-06-20 Tobias Burnus bur...@net-b.de PR fortran/40632 * gfortran.dg/contiguous_1.f90: New. * gfortran.dg/contiguous_2.f90: New. * gfortran.dg/contiguous_3.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/contiguous_1.f90 trunk/gcc/testsuite/gfortran.dg/contiguous_2.f90 trunk/gcc/testsuite/gfortran.dg/contiguous_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/dependency.c trunk/gcc/fortran/dependency.h trunk/gcc/fortran/dump-parse-tree.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/interface.c trunk/gcc/fortran/match.h trunk/gcc/fortran/module.c trunk/gcc/fortran/parse.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-types.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40632
[Bug c++/44611] New: Including math,h and cmath hides ::signbit function
When both of these files are included - compiler cannot locate c global signbit
function.
adri...@dluadrianc:~/gcc_bug g++ signbit.cc
signbit.cc: In function 'int main(int, char**)':
signbit.cc:18:42: error: 'signbit' was not declared in this scope
#include iostream
#include math.h
#include cmath
int main(int argc, char *argv[])
{
float a=12.4234;
float b=-123.4333;
#ifdef _XOPEN_SOURCE
std::cout _XOPEN_SOURCE= _XOPEN_SOURCE std::endl;
#endif
#ifdef _ISOC99_SOURCE
std::cout _ISOC99_SOURCE is here\n;
#endif
std::cout signbit a= signbit(a) std::endl;
std::cout signbit b= signbit(b) std::endl;
return 0;
}
adri...@dluadrianc:~/gcc_bug gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.5.0/configure --enable-__cxa_atexit
--enable-languages=c,c++ --enable-threads --with-cpu=core2 --disable-nls
--with-arch=i686 --with-mpfr=/usr/local --with-gmp=/usr/local
--with-mpc=/usr/local --with-build-time-tools=/usr/local --enable-lto
Thread model: posix
gcc version 4.5.0 (GCC)
--
Summary: Including math,h and cmath hides ::signbit function
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gnu at bluedreamer dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611
[Bug c++/44609] Invalid template code causes infinite loop of error messages
--- Comment #5 from paolo dot carlini at oracle dot com 2010-06-21 14:27 --- There is a *huge* difference, because first we must be able to **reproduce** what the submitter is reporting. I'm sure that Chris, long time contributor of the C++ library, understands this basic, scientific method I would call it, point. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44609
[Bug c++/44611] Including math,h and cmath hides ::signbit function
--- Comment #1 from gnu at bluedreamer dot com 2010-06-21 14:31 --- Created an attachment (id=20963) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20963action=view) Source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611
[Bug c++/44611] Including math,h and cmath hides ::signbit function
--- Comment #2 from gnu at bluedreamer dot com 2010-06-21 14:31 --- Created an attachment (id=20964) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20964action=view) --save-temps output .ii file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611
[Bug c++/44611] Including math,h and cmath hides ::signbit function
--- Comment #3 from gnu at bluedreamer dot com 2010-06-21 14:32 --- Created an attachment (id=20965) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20965action=view) --save-temps output .s file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611
[Bug fortran/44584] [4.6 Regression] gfortran.dg/typebound_proc_15.f03 failed
--- Comment #9 from hjl dot tools at gmail dot com 2010-06-21 14:32 --- Test starts to pass between revision 161046 and revision 161055 on Linux/ia64. Does anyone know which checkin fixes this? This that a real fix? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44584
[Bug c++/44609] Invalid template code causes infinite loop of error messages
--- Comment #6 from chris at bubblescope dot net 2010-06-21 14:35 --- Of course, there is a big difference between an ICE and an infinite loop. Also, bug which causes ICEs on one computer and not another need treating with great care, as that suggests unpredictable memory corruption may be occurring. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44609
[Bug c++/44611] Including math.h and cmath hides ::signbit function
--- Comment #4 from paolo dot carlini at oracle dot com 2010-06-21 14:44 --- I don't think signbit is special: including *any* c* header first undefs the names, thus if they are defined as macros in C, you don't see them anymore in the global namespace, only in std::. If, on the other hand, your specific point is one about the C99 classification macros, yes those are enabled by default, can be disabled at library configure time with --disable-c99. In fact the issue whether C99 facilities should be enabled by default in c++98 mode is a very old one, you can find traces of it in bugzilla for sure, and now is definitely *way too old* to change our decision, considering that all of that is standard in c++0x, which is behind the corner. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Summary|Including math,h and |Including math.h and |cmath hides ::signbit |cmath hides ::signbit |function|function http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611
[Bug fortran/40632] Support F2008's contiguous attribute
--- Comment #4 from burnus at gcc dot gnu dot org 2010-06-21 14:44 --- FIXED on the trunk. Related items: is_contiguous() intrinsic and DO CONCURRENT construct. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40632
[Bug libstdc++/44611] Including math.h and cmath hides ::signbit function
--- Comment #5 from redi at gcc dot gnu dot org 2010-06-21 14:52 --- But should std::signbit be available as ::signbit when math.h is included, at least for c++0x mode? [depr.c.headers]/2 says Every C header, each of which has a name of the form name.h, behaves as if each name placed in the standard library namespace by the corresponding cname header is placed within the global namespace scope. signbit is placed in namespace std by cmath which says to me that it should be placed in the global namespace by math.h (I'm still unsure whether the same applies to stddef.h and std::nullptr_t) -- redi at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |libstdc++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611
[Bug target/44546] [4.5/4.6 Regression] ICE in extract_insn, at recog.c:2103 with -ffast-math -Os (compiling graphviz)
--- Comment #10 from uros at gcc dot gnu dot org 2010-06-21 14:52 --- Subject: Bug 44546 Author: uros Date: Mon Jun 21 14:52:07 2010 New Revision: 161085 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161085 Log: PR target/44546 * config/i386/predicates.md (ix86_swapped_fp_comparsion_operator): New predicate. * config/i386/i386.md (*fp_jcc_8mode_387 and splitters): Use ix86_swapped_fp_comparsion_operator instead of ix86_fp_comparison_operator. (*fp_jcc_1_387): Rename from *fp_jcc_3_387. (*fp_jcc_1r_387): Rename from *fp_jcc_4_387. (*fp_jcc_2_387): Rename from *fp_jcc_5_387. (*fp_jcc_2r_387): Rename from *fp_jcc_6_387. (*fp_jcc_3_387): Rename from *fp_jcc_7_387. (*fp_jcc_4_mode_387): Rename from *fp_jcc_8mode_387. testsuite/ChangeLog: PR target/44546 * gcc.target/i386/pr44546.c: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/pr44546.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config/i386/i386.md branches/gcc-4_5-branch/gcc/config/i386/predicates.md branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44546
[Bug target/44546] [4.5/4.6 Regression] ICE in extract_insn, at recog.c:2103 with -ffast-math -Os (compiling graphviz)
--- Comment #11 from ubizjak at gmail dot com 2010-06-21 14:53 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44546
[Bug fortran/41137] inefficient zeroing of an array
--- Comment #7 from burnus at gcc dot gnu dot org 2010-06-21 15:02 --- (In reply to comment #1) Just for reference, the difference in time between the two variants is truly impressive. About a factor of 11 with gcc 4.4 and 8 with gcc 4.5. I get for the example the following values, note especially the newly added CONTIGUOUS result: 0.31601900 - assumed-shape 0.21601403 - assumed-shape CONTIGUOUS 0.21601295 - explicit size (n,n,...) 0.20801300 - explicit size (10,10,...) 0.21601403 - explicit size (10*10*...) Ignoring some measuring noise, assumed-shape is 46% (-O0) to 25% (-O3) slower than explicit size, but using the CONTIGUOUS attribute, the performance is re-gained. I cannot reproduce the factor of 10 results, however. What surprises me a bit is that -flto -fwhole-program does not reduce the speed penalty of assumed-shape arrays. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41137
[Bug middle-end/44612] New: -flto -fwhole-program: Never read variable not optimized away
Follow up to PR 41137. Using the Intel compiler, the following program takes 0s for the loops (real time: 0.005s); however, with gfortran -fdump-tree-original -fwhole-program -flto -ffast-math -march=native -O3 cont.f90 GCC needs 1.142s. Expected: * GCC also optimizes the loops away if the variable a is never read (but only set) Removing the !! comments prevents ifort from optimizing the loops away; still the performance is with (real time) 0.650s twice as good as the one of GCC. -- Summary: -flto -fwhole-program: Never read variable not optimized away Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: middle-end 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=44612
[Bug middle-end/44612] -flto -fwhole-program: Never read variable not optimized away
--- Comment #1 from burnus at gcc dot gnu dot org 2010-06-21 15:17 --- Created an attachment (id=20966) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20966action=view) Test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44612
[Bug fortran/41137] inefficient zeroing of an array
--- Comment #8 from burnus at gcc dot gnu dot org 2010-06-21 15:22 --- (In reply to comment #7) I get for the example the following values, note especially the newly added CONTIGUOUS result: For the test case, see attachment 20966 at PR 44612; that PR I have filled because GCC does not optimize away the loops, which only set but never read the value from the variable. (Ifort does this optimization.) Additionally, if one prints the variable, ifort is twice as fast. For curiosity: Using NAG, the timing is 0.690 vs. 1.220, i.e. the assumed-shape version is actually faster [though, its overall the performance is poor]. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41137
[Bug libstdc++/44611] Including math.h and cmath hides ::signbit function
--- Comment #6 from paolo dot carlini at oracle dot com 2010-06-21 15:41 --- To be honest, I have zero doubts about nullptr_t: nowhere 18.2 hints at providing it in the global namespace, per se. About signbit, if it's a macro in C it has to be undefined in order to implement the cmath facility in c++0x, see 26.8/11. Really, I don't see how the macro and the template can co-exist: The templates defined in cmath replace the C macros with the same names and the templates are specified in namespace std. If, on the other hand, we are talking in general about the *.h headers, the basic point of DR456, finally resolved, is that those headers very often come together with the C library, over which many C++ library implementations have ***no control*** today (maybe back in the C++98 times people have some other ideas about the interaction between C and C++ in typical platforms, I don't know) Irrespective of the details of the resolution, that is the very important gist of the resolution: implementors of the C++ library are supposed to not have controls on the internals of the *.h C headers and for sure are not supposed to add in facilities. If, in corner cases (*), that is still not clear enough, maybe (other members of) the LWG can further clarify the matter, but it's clear enough for me ;) (*) In the past, we had one, that with memchr co, which has been resolved by Jakub at the C headers level because cstring could not be implemented correctly otherwise. At some point I wanted to raise the issue in the LWG, because, missing an ISO clarification, we forced in a glibc + v3 solution which is contrary to the gist of 456. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611
[Bug c++/44613] New: Declaring an array with non-constant length inside a switch corrupts stack pointer.
The following program compiles with g++ -O3 without errors or warnings but sets
crash at the first printf. It seems to zero the stack pointer before calling
printf.
- Begin switch-crash.ii
# 1 switch-crash.cpp
# 1 built-in
# 1 command-line
# 1 switch-crash.cpp
extern C int printf (__const char *__restrict __format, ...);
int f(int len) {
switch(1) {
case 1:
char x[len];
break;
}
printf(Done\n);
}
int main() {
f(1);
printf(Done\n);
}
-- End switch-crash.ii
Output of g++ -v:
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc
--disable-werror --with-arch-32=i486 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)
--
Summary: Declaring an array with non-constant length inside a
switch corrupts stack pointer.
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mark dot haines at openmarket dot com
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44613
[Bug fortran/41137] inefficient zeroing of an array
--- Comment #9 from jv244 at cam dot ac dot uk 2010-06-21 15:49 --- (In reply to comment #7) I cannot reproduce the factor of 10 results, however. Here this still is the case (so might depend on the precise architecture): /data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/f951 test.f90 -march=k8-sse3 -mcx16 -msahf --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=1024 -mtune=k8 -quiet -dumpbase test.f90 -auxbase test -O3 -version -fintrinsic-modules-path /data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/finclude -o /tmp/ccXsKXnD.s ./a.out 0.10800600 1.0520660 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41137
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #47 from Kyle dot D dot Moffett at boeing dot com 2010-06-21 15:55 --- (In reply to comment #41) Created an attachment (id=20877) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20877action=view) [edit] e500.h and caller-save.c patch The ICE in #38 is due to a bug in caller-save.c We've basically rebuilt everything in the PowerPCSPE Debian port now, and as far as I can tell all of the test-cases affected by this bug are fixed by your attachment 20877 (pr44364.diff). Now that we've gotten further, Sebastian has identified a new floating point bug (PR44606), but I believe we can call this one closed. Again, many thanks for all your help! Cheers, Kyle Moffett -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug libstdc++/44611] Including math.h and cmath hides ::signbit function
--- Comment #8 from paolo dot carlini at oracle dot com 2010-06-21 16:02 --- To be clear: I'm against fiddling with *.h headers, basing on DR456. If you want to do that, for each C library we support, good luck, but I'm not going to help, sorry. And note that appendix D talks about *the C .h headers*, thus anything you do in the global namespace has to happen via a C *.h header. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611
[Bug libstdc++/44611] Including math.h and cmath hides ::signbit function
--- Comment #7 from redi at gcc dot gnu dot org 2010-06-21 15:56 --- (In reply to comment #6) To be honest, I have zero doubts about nullptr_t: nowhere 18.2 hints at providing it in the global namespace, per se. [depr.c.headers]/3 The header stdlib.h assuredly provides the same declarations and definitions within the global namespace Note the same declarations, not the subset of declarations defined in the C standard About signbit, if it's a macro in C it has to be undefined in order to implement the cmath facility in c++0x, see 26.8/11. Really, I don't see how the macro and the template can co-exist: The templates defined in cmath replace the C macros with the same names and the templates are specified in namespace std. I agree the macro and template can't co-exist, but the template could be available as both std::signbit and ::signbit, and I think that's required by appendix D. I agree this isn't ideal, and DR456 tried to help, I don't think DR456 goes far enough in relaxing the requirements on implementations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611
[Bug c++/44611] Including math.h and cmath hides ::signbit function
--- Comment #9 from gnu at bluedreamer dot com 2010-06-21 16:07 --- I agree the macro and template can't co-exist, but the template could be available as both std::signbit and ::signbit, and I think that's required by appendix D. Are these still relevant for c++0x? More so section 5 which says if they are macros in C they must be macros in C++ 17.4.1.2 Headers 4. Except as noted in clauses 18 through 27, the contents of each header cname shall be the same as that of the corresponding header name.h, as specified in ISO/IEC 9899:1990 Programming Languages C (Clause 7), or ISO/IEC:1990 Programming LanguagesC AMENDMENT 1: C Integrity, (Clause 7), as appropriate, as if by inclusion. In the C++ Standard Library, however, the declarations and definitions (except for names which are defined as macros in C) are within namespace scope (3.3.5) of the namespace std. 5. Names which are defined as macros in C shall be defined as macros in the C++ Standard Library, even if C grants license for implementation as functions. [Note: the names defined as macros in C include the following: assert, errno, offsetof, setjmp, va_arg, va_end, and va_start. end note] -- gnu at bluedreamer dot com changed: What|Removed |Added Component|libstdc++ |c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611
[Bug c++/44611] Including math.h and cmath hides ::signbit function
--- Comment #10 from redi at gcc dot gnu dot org 2010-06-21 16:12 --- (In reply to comment #9) Are these still relevant for c++0x? More so section 5 which says if they are macros in C they must be macros in C++ see 26.8 [c.math] paragraph 11 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611
[Bug c++/44611] Including math.h and cmath hides ::signbit function
--- Comment #11 from gnu at bluedreamer dot com 2010-06-21 16:20 --- (In reply to comment #10) (In reply to comment #9) Are these still relevant for c++0x? More so section 5 which says if they are macros in C they must be macros in C++ see 26.8 [c.math] paragraph 11 Thanks. I should probably start using the draft rather then my dusty old 14882 copy. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611
[Bug c++/44613] Declaring an array with non-constant length inside a switch corrupts stack pointer.
--- Comment #1 from redi at gcc dot gnu dot org 2010-06-21 16:22 --- (In reply to comment #0) The following program compiles with g++ -O3 without errors or warnings Not with warnings enabled it doesn't! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44613
[Bug bootstrap/44426] [4.4/4.5/4.6 Regression] gcc 4.5.0 requires c9x compiler to build
--- Comment #14 from jakub at gcc dot gnu dot org 2010-06-21 16:27 --- Subject: Bug 44426 Author: jakub Date: Mon Jun 21 16:26:25 2010 New Revision: 161092 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161092 Log: PR bootstrap/44426 * sel-sched-dump.h (sel_prepare_string_for_dot_label): Remove prototype. (sel_print_to_dot): Remove macro. (sel_print): Likewise. New prototype. * sel-sched-dump.c (sel_prepare_string_for_dot_label): Make static. (sel_print): New function. Modified: trunk/gcc/ChangeLog trunk/gcc/sel-sched-dump.c trunk/gcc/sel-sched-dump.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44426
[Bug c++/44611] Including math.h and cmath hides ::signbit function
--- Comment #12 from redi at gcc dot gnu dot org 2010-06-21 16:28 --- Is there a reason you changed the component back to c++? This is not a problem in the C++ compiler front-end. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611
[Bug c++/44611] Including math.h and cmath hides ::signbit function
--- Comment #13 from gnu at bluedreamer dot com 2010-06-21 16:31 --- (In reply to comment #12) Is there a reason you changed the component back to c++? This is not a problem in the C++ compiler front-end. I didn't mean to change anything. All I did was reply (maybe browser cached some post back values) My apologies - please change it to whatever it should be. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44611
[Bug target/44575] [4.5/4.6 Regression] __builtin_va_arg overwrites into adjacent stack location
--- Comment #4 from jakub at gcc dot gnu dot org 2010-06-21 16:34 --- Subject: Bug 44575 Author: jakub Date: Mon Jun 21 16:33:49 2010 New Revision: 161097 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161097 Log: PR target/44575 * config/i386/i386.c (ix86_gimplify_va_arg): When copying va_arg from a set of register save slots into a temporary, if the container is bigger than type size, do the copying using smaller mode or using memcpy. * gcc.c-torture/execute/pr44575.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr44575.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44575
[Bug fortran/44614] New: [OOP] Wrongly importing a symbol into an interface without IMPORT
Based on a report by bd satish at http://gcc.gnu.org/ml/fortran/2010-06/msg00210.html The following program is invalid as IMPORT is missing, but gfortran still compiles it: Expected: An error such as: Error: line 12: SELF is of undefined derived type CONNECTION or error #6457: This derived type name has not been declared. [CONNECTION] module factory_pattern implicit none type, abstract :: Connection contains procedure(generic_desc), deferred :: description end type Connection abstract interface subroutine generic_desc(self) !import class(Connection) :: self end subroutine generic_desc end interface end module factory_pattern -- Summary: [OOP] Wrongly importing a symbol into an interface without IMPORT Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: accepts-invalid, 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=44614
[Bug target/44615] New: -mtune=atom failed on sse2-vec-2.c and amd64-abi-3.c
On Linux/x86-64, I got FAIL: gcc.target/i386/amd64-abi-3.c scan-assembler subq[\\t ]*\\$88,[\\t ]*%rsp FAIL: gcc.target/i386/sse2-vec-2.c (internal compiler error) FAIL: gcc.target/i386/sse2-vec-2.c (test for excess errors) with -mtune=atom. -- Summary: -mtune=atom failed on sse2-vec-2.c and amd64-abi-3.c Product: gcc Version: 4.4.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44615
[Bug target/44615] -mtune=atom failed on sse2-vec-2.c and amd64-abi-3.c
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-21 16:42 --- (In reply to comment #0) FAIL: gcc.target/i386/amd64-abi-3.c scan-assembler subq[\\t ]*\\$88,[\\t ]*%rsp This is due to -mtune=atom generates: leaq-88(%rsp), %rsp instead of subq$88, %rsp -- hjl dot tools at gmail dot com changed: What|Removed |Added Summary|-mtune=atom failed on sse2- |-mtune=atom failed on sse2- |vec-2.c and amd64-abi-3.c |vec-2.c and amd64-abi-3.c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44615
[Bug fortran/44616] New: [OOP] ICE if CLASS(foo) is used before its definition
Reported by bd satish at http://gcc.gnu.org/ml/fortran/2010-06/msg00210.html For the program, gfortran ICEs with: f951: internal compiler error: in find_typebound_proc_uop, at fortran/class.c:660 The failing assert is: gcc_assert (derived-f2k_derived); Note: The original test case (see link) misses an IMPORT, cf. PR 44614. The additional derived type is required -- and for the ICE it needs to come before the actual definition, otherwise, it works. module factory_pattern implicit none type First_Factory character(len=20) :: factory_type class(Connection), pointer :: connection_type contains end type First_Factory type, abstract :: Connection contains procedure(generic_desc), deferred :: description end type Connection abstract interface subroutine generic_desc(self) import ! Required, cf. PR 44614 class(Connection) :: self end subroutine generic_desc end interface end module factory_pattern -- Summary: [OOP] ICE if CLASS(foo) is used before its definition Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: ice-on-valid-code 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=44616
[Bug fortran/44614] [OOP] Wrongly importing a symbol into an interface without IMPORT
--- Comment #1 from burnus at gcc dot gnu dot org 2010-06-21 16:44 --- Cf. also PR 44616 for the ICE reported at the mailing list. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44614
[Bug target/44615] -mtune=atom failed on sse2-vec-2.c and amd64-abi-3.c
--- Comment #2 from hjl dot tools at gmail dot com 2010-06-21 16:45 --- (In reply to comment #0) FAIL: gcc.target/i386/sse2-vec-2.c (internal compiler error) FAIL: gcc.target/i386/sse2-vec-2.c (test for excess errors) I got /export/build/gnu/gcc-atom/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc-atom/build-x86_64-linux/gcc/ /export/gnu/import/git/gcc/gcc/testsuite/gcc.target/i386/sse2-vec-2.c -O2 -msse2 -mtune=atom In file included from /export/gnu/import/git/gcc/gcc/testsuite/gcc.target/i386/sse2-vec-2.c:5:0: /export/gnu/import/git/gcc/gcc/testsuite/gcc.target/i386/sse2-check.h: In function do_test: /export/gnu/import/git/gcc/gcc/testsuite/gcc.target/i386/sse2-check.h:12:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. The problem is ;; if palignr or psrldq (define_insn_reservation atom_sseishft_2 1 (and (eq_attr cpu atom) (and (eq_attr type sseishft) (and (eq_attr atom_unit sishuf) (match_operand 2 immediate_operand atom-simple-0) ;; if reg/mem op (define_insn_reservation atom_sseishft_3 2 (and (eq_attr cpu atom) (and (eq_attr type sseishft) (not (match_operand 2 immediate_operand atom-complex, atom-all-eu) in atom.md. Some patterns, which generate psrldq, don't have the 3rd operand as shift count. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44615
[Bug c++/44613] Declaring an array with non-constant length inside a switch corrupts stack pointer.
--- Comment #2 from manu at gcc dot gnu dot org 2010-06-21 16:45 --- (In reply to comment #1) (In reply to comment #0) The following program compiles with g++ -O3 without errors or warnings Not with warnings enabled it doesn't! ??? -- 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=44613
[Bug c++/44613] Declaring an array with non-constant length inside a switch corrupts stack pointer.
--- Comment #3 from mark dot haines at openmarket dot com 2010-06-21 16:47 --- (In reply to comment #1) (In reply to comment #0) The following program compiles with g++ -O3 without errors or warnings Not with warnings enabled it doesn't! Sorry, g++ -O3 -Wall -Wextra switch-crash.cpp gives: switch-crash.cpp: In function int f(int): switch-crash.cpp:6: warning: unused variable x switch-crash.cpp:10: warning: no return statement in function returning non-void switch-crash.cpp:7: warning: saved_stack.1 is used uninitialized in this function The saved_stack.1 is somewhat suspicious. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44613
[Bug c++/44613] Declaring an array with non-constant length inside a switch corrupts stack pointer.
--- Comment #4 from manu at gcc dot gnu dot org 2010-06-21 16:51 --- (In reply to comment #3) (In reply to comment #1) (In reply to comment #0) The following program compiles with g++ -O3 without errors or warnings Not with warnings enabled it doesn't! Sorry, g++ -O3 -Wall -Wextra switch-crash.cpp gives: switch-crash.cpp: In function int f(int): switch-crash.cpp:6: warning: unused variable x switch-crash.cpp:10: warning: no return statement in function returning non-void If you add return 0 after the printf, this warning is silenced and it still crashes (it crashes for me even at -O0). switch-crash.cpp:7: warning: saved_stack.1 is used uninitialized in this function The saved_stack.1 is somewhat suspicious. It is a bug anyway, because internal variables should never be warned. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-21 16:51:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44613
[Bug fortran/41137] inefficient zeroing of an array
--- Comment #10 from burnus at gcc dot gnu dot org 2010-06-21 17:00 --- (In reply to comment #9) (In reply to comment #7) I cannot reproduce the factor of 10 results, however. Here this still is the case (so might depend on the precise architecture): OK, I was using -fwhole-file out of habit - thus the difference is that small (all optimization levels, including -O0). Otherwise, I also get the same factor-of-10 difference. If one splits it in two files, one needs to use -O3 -flto to get a fast program. For comparison, using two files, ifort also shows a factor of 2 to 5 difference (and is at -O0 ten times slower than gfortran; at -O2 it is twice as fast as gfortran). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41137
[Bug bootstrap/44426] [4.4/4.5/4.6 Regression] gcc 4.5.0 requires c9x compiler to build
--- Comment #15 from jakub at gcc dot gnu dot org 2010-06-21 17:07 --- Subject: Bug 44426 Author: jakub Date: Mon Jun 21 17:06:48 2010 New Revision: 161100 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161100 Log: PR bootstrap/44426 * sel-sched-dump.h (sel_prepare_string_for_dot_label): Remove prototype. (sel_print_to_dot): Remove macro. (sel_print): Likewise. New prototype. * sel-sched-dump.c (sel_prepare_string_for_dot_label): Make static. (sel_print): New function. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/sel-sched-dump.c branches/gcc-4_5-branch/gcc/sel-sched-dump.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44426
[Bug bootstrap/44426] [4.4/4.5/4.6 Regression] gcc 4.5.0 requires c9x compiler to build
--- Comment #16 from jakub at gcc dot gnu dot org 2010-06-21 17:11 --- Subject: Bug 44426 Author: jakub Date: Mon Jun 21 17:10:02 2010 New Revision: 161102 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161102 Log: PR bootstrap/44426 * sel-sched-dump.h (sel_prepare_string_for_dot_label): Remove prototype. (sel_print_to_dot): Remove macro. (sel_print): Likewise. New prototype. * sel-sched-dump.c (sel_prepare_string_for_dot_label): Make static. (sel_print): New function. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/sel-sched-dump.c branches/gcc-4_4-branch/gcc/sel-sched-dump.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44426
[Bug bootstrap/44426] [4.4/4.5/4.6 Regression] gcc 4.5.0 requires c9x compiler to build
--- Comment #17 from jakub at gcc dot gnu dot org 2010-06-21 17:20 --- Should be fixed now. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44426
[Bug target/44615] -mtune=atom failed on sse2-vec-2.c and amd64-abi-3.c
--- Comment #3 from hjl dot tools at gmail dot com 2010-06-21 17:23 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02058.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2010- ||06/msg02058.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44615
[Bug fortran/41137] inefficient zeroing of an array
--- Comment #11 from jakub at gcc dot gnu dot org 2010-06-21 17:43 --- What's the reason why gfc_trans_zero_assign insists that len is INTEGER_CST? At least if it is contiguous (and not assumed size), why can't memset be used even for non-constant sizes? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41137
