[Bug libfortran/47284] G format outputs wrong number of asterixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47284 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org, ||jvdelisle at gcc dot ||gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-14 08:30:06 UTC --- Compiler comparison (using 'FORMAT(,G5.1,)'): gfortran (4.1, 4.3, 4.6), g95, NAG f95, g77 and pgf95 print: * ifort, pathf95, openf95, sunf95 and crayftn print: * Fortran 2008: 10.7.2 Numeric editing, 10.7.2.1 General rules item (5): (5) On output, if an exponent exceeds its specified or implied width using the E, EN, ES, D, or G edit descriptor, or the number of characters produced exceeds the field width, the processor shall fill the entire field of width w with asterisks. However, the processor shall not produce asterisks if the field width is not exceeded when optional characters are omitted. R1007 data-edit-desc is ... or G w [ . d [ E e ] ] or ... Thus I agree that for G5.1 one should have five and not only one asterisk.
[Bug c++/47288] New: Wrong operation of call by reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47288
Summary: Wrong operation of call by reference
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: malicti...@gmail.com
I find the call variables of call by reference will fail to run the follow:
#include stdio.h
void swap(int a, int b) {
a ^= b^= a ^= b;
}
int main(void) {
int a = 3, b = 5;
swap(a, b);
printf(%d %d\n, a, b);
return 0;
}
If will print 0 3, but we want to get 5 3.
if we change the swap function:
void swap(int a, int b) {
a ^= b;
b ^= a;
a ^= b;
}
or directly change swap(a, b) to a ^= b^= a ^= b; in main function
They will print 5 3 correctly.
This bug I find in g++ 4.1.0, 4.4.3, 4.5.1
[Bug c++/47288] Wrong operation of call by reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47288 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-01-14 08:40:44 UTC --- There is no sequence point between the assignments of a (and b).
[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr-ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536 --- Comment #19 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-14 09:00:20 UTC --- (In reply to comment #18) (I asked on comp.lang.fortran) Cf. http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/4b65b1cd206ce9fe Or from the standard (F2008): 15.2.3.6 C LOC (X): Argument. X [...] shall not be a coindexed object. [...] If it is an array, it shall be contiguous and have nonzero size. We just have to check for array sections along the references, and error out if there are any. I was about to suggest to use gfc_simply_contiguous() but I then realized that -- for a simply contiguous array array -- also the following array section array([1,2,3,4]) is contiguous - even though it is not simply contiguous and in the general case the contiguity is not compile-time checkable. (vector-subscripts are notoriously difficult to check at compile time) Similarly, c_loc(comp(1:2)%elem) is valid as long as elem is the only item in the derived type *and* no padding is happening. (As padding often occurs, one could always reject it.) And comp(1:1)%elem is always contiguous - but that's also a strange way of writing it. (Actually, I think that comp(1:1)%elem _is_ simply contiguous - though I am not sure gfc_simply_contiguous does detect this.) Personally, I think one should give some diagnostic as soon as the argument is not simply contiguous -- be it a warning or an error. At least I cannot imagine any sensible program using non-simply contiguous arrays as argument for C_LOC. (The term simply contiguous is defined in section 6.5.4.) * * * When you add another check for C_LOC, can you include one for the following? You just need to add a gfc_is_coindexed (expr). use iso_c_binding type t integer :: A end type t type(t), target, allocatable :: x(:)[:] type(c_ptr) :: cptr allocate(x(1)[*]) cptr = c_loc(x(1)%a)! OK cptr = c_loc(x(1)[1]%a) ! Invalid end
[Bug libgcj/44341] [4.6 Regression] libjava cross build fails when configured with --with-gmp=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44341 --- Comment #11 from Alexandre Oliva aoliva at gcc dot gnu.org 2011-01-14 09:54:54 UTC --- Yeah, sorry, the *s were not supposed to be there in the variable names, only in the help message. I fixed that shortly after posting the patch here, when I first noticed the problem.
[Bug c++/47289] New: internal compiler error: in tsubst_pack_expansion (triggered by decltype)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47289
Summary: internal compiler error: in tsubst_pack_expansion
(triggered by decltype)
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: schmidt-thi...@ismll.de
Created attachment 22963
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22963
preprocessed source file
gcc (svn rev. 166057) throws an internal compiler error when
compiling the attached file bug-gcc-compiler-error.ii
g++ -std=c++0x bug-gcc-compiler-error.ii
bug-gcc-compiler-error.cpp: In function ‘int main()’:
bug-gcc-compiler-error.cpp:33: internal compiler error: in
tsubst_pack_expansion, at cp/pt.c:7544
The code compiles fine if the definition of reverse is replaced
by:
template template typename... __ARGS class _F, typename _T, typename...
_ARGS
_T reverse (_T x1, _ARGS... args) {
return _F_T, _ARGS...::call_function(x1, args...);
}
gcc was build from source and configured via
configure --prefix=/opt/prog/gcc/ -enable-languages=c,c++,fortran
--disable-multilib
on ubuntu
uname -a
Linux lst-desktop 2.6.32-24-generic #39-Ubuntu SMP Wed Jul 28 05:14:15 UTC 2010
x86_64 GNU/Linux
[Bug c++/47289] internal compiler error: in tsubst_pack_expansion (triggered by decltype)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47289 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.14 10:27:04 Ever Confirmed|0 |1 Known to fail||4.4.5, 4.5.2, 4.6.0 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-14 10:27:04 UTC --- Confirmed.
[Bug tree-optimization/47286] Invalid code when using register ... asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47286 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.01.14 10:34:35 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-14 10:34:35 UTC --- Confirmed. points-to analysis computes sp as pointing to nothing.
[Bug tree-optimization/47286] Invalid code when using register ... asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47286 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Known to fail||4.5.2, 4.6.0 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-14 10:59:46 UTC --- The fundamental problem is present on all branches, we are lucky in 4.4 and earlier though.
[Bug tree-optimization/47283] [4.6 regression] ICE in refs_may_alias_p_1, at tree-ssa-alias.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47283 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-14 11:03:21 UTC --- Doesn't reproduce for me on x86_64 with -m32.
[Bug tree-optimization/47280] [4.6 Regression] ICE: verify_stmts failed: statement marked for throw, but doesn't with -fnon-call-exceptions -ftrapv
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47280 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-14 11:07:15 UTC --- Mine.
[Bug middle-end/46823] [4.6 Regression] ICE: edge points to wrong declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823 --- Comment #22 from Martin Jambor jamborm at gcc dot gnu.org 2011-01-14 11:59:10 UTC --- Author: jamborm Date: Fri Jan 14 11:59:07 2011 New Revision: 168778 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168778 Log: 2011-01-14 Martin Jambor mjam...@suse.cz PR middle-end/46823 * tree-inline.c (expand_call_inline): Get fndecl from call graph edge. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-inline.c
[Bug tree-optimization/47283] [4.6 regression] ICE in refs_may_alias_p_1, at tree-ssa-alias.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47283 --- Comment #4 from Martin Jambor jamborm at gcc dot gnu.org 2011-01-14 12:03:51 UTC --- OK, I can reproduce this and will have a look. The first interesting observation is that -g is necessary to trigger the error.
[Bug middle-end/47281] [4.6 Regression] error: non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47281
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2011.01.14 12:10:10
AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org
|gnu.org |
Target Milestone|--- |4.6.0
Ever Confirmed|0 |1
--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-14
12:10:10 UTC ---
Simplified C testcase:
struct T;
typedef void F(void);
F* aux(void (*x)())
{
return x;
}
void make_mess (int);
F*
get_funloc (void (*x)(int), F* (*y)())
{
return y(x);
}
F*
foo ()
{
return get_funloc (make_mess, aux);
}
[Bug tree-optimization/47286] Invalid code when using register ... asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47286 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-14 12:15:48 UTC --- Author: rguenth Date: Fri Jan 14 12:15:43 2011 New Revision: 168779 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168779 Log: 2011-01-14 Richard Guenther rguent...@suse.de PR tree-optimization/47286 * tree-ssa-structalias.c (new_var_info): Register variables are global. * gcc.dg/tree-ssa/pr47286.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr47286.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-structalias.c
[Bug middle-end/47281] [4.6 Regression] error: non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47281 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Blocks||46076 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-14 12:26:47 UTC --- It's the transitivity problem in (void (*)(void))(void (*)())(void (*)(int))make_mess The first conversion is useless as is the second. But (void (*)(void))(void (*)(int))make_mess is not useless. That's of course a bug in the type system as implemented as we rely on 1) useless_type_conversion_p is transitive. If a b and b c then a c. So we either have to revert the fix for PR46076 or need to make conversions to unprototyped function pointers not generally useless. I'm going for reverting the fix for 4.6.
[Bug driver/47244] [4.6 Regression] plugin linker is used unconditionally
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47244 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-14 12:32:22 UTC --- Your fix does not work. /abuild/rguenther/trunk-g/gcc/xgcc -B/abuild/rguenther/trunk-g/gcc/ /space/rguenther/src/svn/trunk/gcc/testsuite/gcc.dg/tree-ssa/pr46076.c -O2 -lm -o pr46076.exe -v ... /abuild/rguenther/trunk-g/gcc/collect2 -plugin /abuild/rguenther/trunk-g/gcc/liblto_plugin.so -plugin-opt=/abuild/rguenther/trunk-g/gcc/lto-wrapper -plugin-opt=-fresolution=/tmp/cc3HveYS.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o pr46076.exe /usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o /abuild/rguenther/trunk-g/gcc/crtbegin.o -L/abuild/rguenther/trunk-g/gcc -L/lib/../lib64 -L/usr/lib/../lib64 /tmp/cc8pWTze.o -lm -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /abuild/rguenther/trunk-g/gcc/crtend.o /usr/lib/../lib64/crtn.o /usr/bin/gold: /tmp/cc8pWTze.o: in function main:pr46076.c(.text.startup+0x20): error: undefined reference to 'link_error'
[Bug middle-end/46823] [4.6 Regression] ICE: edge points to wrong declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46823 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #23 from Martin Jambor jamborm at gcc dot gnu.org 2011-01-14 12:35:54 UTC --- Hopefully finally fixed.
[Bug middle-end/47281] [4.6 Regression] error: non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47281 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-14 12:39:34 UTC --- Fixed.
[Bug middle-end/47281] [4.6 Regression] error: non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47281 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-14 12:39:14 UTC --- Author: rguenth Date: Fri Jan 14 12:39:09 2011 New Revision: 168781 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168781 Log: 2011-01-14 Richard Guenther rguent...@suse.de PR middle-end/47281 Revert 2011-01-11 Richard Guenther rguent...@suse.de PR tree-optimization/46076 * tree-ssa.c (useless_type_conversion_p): Conversions from unprototyped to empty argument list function types are useless. * gcc.dg/torture/pr47281.c: New testcase. * gcc.dg/tree-ssa/pr46076.c: XFAIL. Added: trunk/gcc/testsuite/gcc.dg/torture/pr47281.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/pr46076.c trunk/gcc/tree-ssa.c
[Bug c/46076] [4.6 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076 --- Comment #21 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-14 12:39:14 UTC --- Author: rguenth Date: Fri Jan 14 12:39:09 2011 New Revision: 168781 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168781 Log: 2011-01-14 Richard Guenther rguent...@suse.de PR middle-end/47281 Revert 2011-01-11 Richard Guenther rguent...@suse.de PR tree-optimization/46076 * tree-ssa.c (useless_type_conversion_p): Conversions from unprototyped to empty argument list function types are useless. * gcc.dg/torture/pr47281.c: New testcase. * gcc.dg/tree-ssa/pr46076.c: XFAIL. Added: trunk/gcc/testsuite/gcc.dg/torture/pr47281.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/pr46076.c trunk/gcc/tree-ssa.c
[Bug c/46076] [4.6 regression] constant propagation and compile-time math no longer happening versus 4.4 and 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46076 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #22 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-14 12:39:55 UTC --- Reopen.
[Bug middle-end/31249] pseudo-optimization with sincos/cexpi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31249 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #19 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-01-14 13:04:28 UTC --- Still there on powerpc-apple-darwin9 [trunk revision 168762]: gfc sincos_o.f904.230s 8.32s 7.98s gfc -m64 sincos_o.f904.60s 7.98s 7.07s gcc46 sincos_o.c 4.17s 7.95s 7.63s gcc46 -m64 sincos_o.c 4.55s 7.55s 7.03s
[Bug c++/46688] [4.6 Regression] g++ requires a function declaration when it should not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46688 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org 2011-01-14 13:08:06 UTC --- Author: jason Date: Fri Jan 14 13:08:02 2011 New Revision: 168782 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168782 Log: PR c++/46688 * tree.c (build_vec_init_expr): Handle flexible array properly. Added: trunk/gcc/testsuite/g++.dg/ext/flexary2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog
[Bug c++/46903] [4.6 Regression][C++0x] ICE unexpected expression of kind template_id_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46903 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2011-01-14 13:08:16 UTC --- Author: jason Date: Fri Jan 14 13:08:11 2011 New Revision: 168783 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168783 Log: PR c++/46903 * typeck2.c (check_narrowing): Only check arithmetic types. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-regress1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck2.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/46935] We should recognize expanded switch statement and convert 2 way switch statements into shift mask test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46935 Tom de Vries tom at codesourcery dot com changed: What|Removed |Added CC||tom at codesourcery dot com --- Comment #5 from Tom de Vries tom at codesourcery dot com 2011-01-14 13:17:09 UTC --- I know Tom de Vries is working on this problem and has a prototype patch. He'll be posting his work for 4.7. http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00959.html
[Bug tree-optimization/47280] [4.6 Regression] ICE: verify_stmts failed: statement marked for throw, but doesn't with -fnon-call-exceptions -ftrapv
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47280 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-14 13:20:28 UTC --- Author: rguenth Date: Fri Jan 14 13:20:22 2011 New Revision: 168784 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168784 Log: 2011-01-14 Richard Guenther rguent...@suse.de PR tree-optimization/47280 * tree-ssa-forwprop.c (associate_plusminus): Cleanup EH and return CFG changes. (tree_ssa_forward_propagate_single_use_vars): Deal with CFG changes from associate_plusminus. * g++.dg/opt/pr47280.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/opt/pr47280.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-forwprop.c
[Bug tree-optimization/47280] [4.6 Regression] ICE: verify_stmts failed: statement marked for throw, but doesn't with -fnon-call-exceptions -ftrapv
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47280 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-14 13:20:59 UTC --- Fixed.
[Bug middle-end/31249] pseudo-optimization with sincos/cexpi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31249 --- Comment #20 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-01-14 13:27:24 UTC --- I have forgotten to give the optimization levels: -O1 -O3 gfc sincos_o.f904.23s8.32s7.98s gfc -m64 sincos_o.f904.60s 7.98s7.07s gcc46 sincos_o.c 4.17s 7.95s7.63s gcc46 -m64 sincos_o.c 4.55s7.55s7.03s
[Bug c++/47290] New: memory exhausted compiling a destructor with an infinite 'for (;;);' loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47290
Summary: memory exhausted compiling a destructor with an
infinite 'for (;;);' loop
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@abeckmann.de
The following piece of code consumes all available memory when being compiled
with g++ 4.5 or g++ 4.6 and optimization level -O2 or higher. It compiles
correctly with g++ 4.4.
gcc version 4.6.0 20110111 (experimental) (GCC)
gcc version 4.5.3 20110110 (prerelease) (GCC)
= 8 =
struct V
{
V ( int = 0 ) ;
~V ()
{
for ( ; ; ) ;
}
int size () ;
} ;
struct S
{
V a ;
V b ;
S () : b ( a . size () )
{ }
} ;
S s ;
= 8 =
$ ulimit -v
700
# limited to about 7 GB ouf of my 8 GB of RAM so the machine does not start to
swap heavily
$ g++-trunk -O2 -c memhog.C
virtual memory exhausted: Cannot allocate memory
$ g++-trunk -v -O2 -c memhog.C
Using built-in specs.
COLLECT_GCC=/opt/software/x86_64/gcc-trunk/bin/g++-trunk
COLLECT_LTO_WRAPPER=/opt/software/x86_64/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/opt/software/x86_64/gcc-trunk
--program-suffix=-trunk --enable-languages=c,c++ --enable-checking
Thread model: posix
gcc version 4.6.0 20110111 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-O2' '-c' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
/opt/software/x86_64/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus
-quiet -v -D_GNU_SOURCE memhog.C -quiet -dumpbase memhog.C -mtune=generic
-march=x86-64 -auxbase memhog -O2 -version -o /tmp/ccmZpTnX.s
GNU C++ (GCC) version 4.6.0 20110111 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.6.0 20110111 (experimental), GMP version
4.3.2, MPFR version 3.0.0-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
/opt/software/x86_64/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../x86_64-unknown-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/opt/software/x86_64/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0
/opt/software/x86_64/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/x86_64-unknown-linux-gnu
/opt/software/x86_64/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/backward
/opt/software/x86_64/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/include
/usr/local/include
/opt/software/x86_64/gcc-trunk/include
/opt/software/x86_64/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/include-fixed
/usr/include
End of search list.
GNU C++ (GCC) version 4.6.0 20110111 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.6.0 20110111 (experimental), GMP version
4.3.2, MPFR version 3.0.0-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: e48296e048ab4023a18c7e7537bfd602
virtual memory exhausted: Cannot allocate memory
[Bug tree-optimization/32684] Missed tail call with sin/cos and sincos pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32684 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Depends on||46926 --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-14 13:32:51 UTC --- See also PR46926. The flags controlling whether we can emit a call to sincos need some work (but it's not exactly clear how it should work).
[Bug middle-end/31249] pseudo-optimization with sincos/cexpi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31249 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Depends on||46926 --- Comment #21 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-14 13:33:20 UTC --- See also PR46926. The flags controlling whether we can emit a call to sincos need some work (but it's not exactly clear how it should work).
[Bug tree-optimization/32684] Missed tail call with sin/cos and sincos pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32684 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Depends on|46926 | --- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-14 13:33:52 UTC --- (In reply to comment #8) See also PR46926. The flags controlling whether we can emit a call to sincos need some work (but it's not exactly clear how it should work). Err - wrong bug.
[Bug c++/46903] [4.6 Regression][C++0x] ICE unexpected expression of kind template_id_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46903 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-01-14 13:33:54 UTC --- Fixed.
[Bug c++/46688] [4.6 Regression] g++ requires a function declaration when it should not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46688 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2011-01-14 13:33:11 UTC --- Fixed.
[Bug c/47273] References to unaligned packed structure members not allowed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47273
--- Comment #2 from Waldemar Valdas Bancewicz waldemarbancewicz at ruggedcom
dot com 2011-01-14 13:42:03 UTC ---
Consider the following program test.c:
#include stdio.h
struct s {
char a;
int b;
int* GetValp() { return b; }
int GetValr() { return b; }
} __attribute__((packed));
int main() {
struct s s1;
*(s1.GetValp()) = 150;
s1.GetValr() = 5;
printf(%d\n, s1.b);
}
When trying to compile we get the following error message:
waldemarbancewicz@waldemarbancewicz:~/tmp$ g++ -o test test.c
test.c: In member function ‘int s::GetValr()’:
test.c:7: error: cannot bind packed field ‘((s*)this)-s::b’ to ‘int’
[Bug c/47273] References to unaligned packed structure members not allowed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47273 --- Comment #3 from Waldemar Valdas Bancewicz waldemarbancewicz at ruggedcom dot com 2011-01-14 13:44:04 UTC --- This bug has to do with g++, not gcc. Should I delete this bug and re-submit?
[Bug c++/47291] New: [4.6 Regression] ICE: SIGSEGV in size_binop_loc (fold-const.c:1427) with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47291 Summary: [4.6 Regression] ICE: SIGSEGV in size_binop_loc (fold-const.c:1427) with -g Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 22965 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22965 reduced testcase (from g++.old-deja/g++.pt/ptrmem2.C) Compiler output: $ gcc -g testcase.C ==15482== Invalid read of size 8 ==15482==at 0x863310: size_binop_loc (fold-const.c:1427) ==15482==by 0xA12739: byte_from_pos (stor-layout.c:840) ==15482==by 0x53C217: cplus_expand_constant (expr.c:50) ==15482==by 0x4FAC3E: fold_cplus_constants (cp-lang.c:218) ==15482==by 0x7AB5CE: gen_generic_params_dies (dwarf2out.c:13048) ==15482==by 0x7B51A3: gen_tagged_type_die (dwarf2out.c:20150) ==15482==by 0x7A8FB0: gen_type_die_with_usage (dwarf2out.c:20500) ==15482==by 0x7B3EAD: gen_decl_die (dwarf2out.c:21057) ==15482==by 0x9357BB: rest_of_type_compilation (passes.c:229) ==15482==by 0x5A6479: finish_struct_1 (class.c:5683) ==15482==by 0x582A6A: instantiate_class_template (pt.c:8561) ==15482==by 0x5F0486: complete_type (typeck.c:134) ==15482==by 0x5344F4: grokdeclarator (decl.c:9651) ==15482==by 0x5ACFC2: grokfield (decl2.c:806) ==15482==by 0x5E7B51: cp_parser_member_declaration (parser.c:18010) ==15482==by 0x5CCA6B: cp_parser_type_specifier (parser.c:17630) ==15482==by 0x5CE247: cp_parser_decl_specifier_seq (parser.c:9990) ==15482==by 0x5E55B9: cp_parser_simple_declaration (parser.c:9641) ==15482==by 0x5E5A48: cp_parser_block_declaration (parser.c:9592) ==15482==by 0x5E9771: cp_parser_declaration (parser.c:9497) ==15482==by 0x5E8299: cp_parser_declaration_seq_opt (parser.c:9383) ==15482==by 0x5E9DE8: c_parse_file (parser.c:3463) ==15482==by 0x6BE0E4: c_common_parse_file (c-opts.c:1071) ==15482==by 0xA211D5: toplev_main (toplev.c:579) ==15482==by 0x62FEBBC: (below main) (in /lib64/libc-2.11.2.so) ==15482== Address 0x10 is not stack'd, malloc'd or (recently) free'd ==15482== testcase.C: In instantiation of 'DS::i': testcase.C:7:15: instantiated from here testcase.C:2:30: 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. Tested revisions: r168743 - crash 4.5.2 - OK
[Bug tree-optimization/32684] Missed tail call with sin/cos and sincos pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32684
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org
|gnu.org |
--- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-14
13:51:31 UTC ---
Looking here again I can't see what tailcall you would expect. Mainline
generates
complex double
quantum_cexp (double phi)
{
complex double sincostmp.1;
double D.2685;
double D.2684;
complex double D.2683;
bb 2:
sincostmp.1_5 = __builtin_cexpi (phi_1(D));
D.2684_2 = REALPART_EXPR sincostmp.1_5;
D.2685_3 = IMAGPART_EXPR sincostmp.1_5;
D.2683_4 = COMPLEX_EXPR D.2684_2, D.2685_3;
return D.2683_4;
which we indeed do not optimize to just
return __builtin_cexp1 (phi_1(D));
but in the end sincos doesn't have an ABI that allows for tailcalling
or sibcalling to it.
There is a missing folding of COMPLEX_EXPR REALPART_EXPR x, IMAGPART_EXPR
x to x and SCCVN does not go the full way of combining binary expressions.
[Bug c/47273] References to unaligned packed structure members not allowed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47273
--- Comment #4 from Waldemar Valdas Bancewicz waldemarbancewicz at ruggedcom
dot com 2011-01-14 14:04:19 UTC ---
The reason pointers and references are treated differently:
Consider the following code fragment:
struct s {
char a;
int b;
int* GetValp() { return b; }
//int GetValr() { return b; }
} __attribute__((packed));
The GetValp code will compile to something like:
if b is aligned
return address of b
else
do aligned read before pointer and after pointer, bitshift and mask each read
and merge to get data
However, GetValr, by returning a reference, always assumes that the reference
is aligned. Since we are returning a reference to a packed structure member,
the compiler will not allow this. Therefore, if the user is absolutely sure the
reference is aligned, using references gives a slight performance boost over
pointers. However, this performance gain only happens on some architectures.
Hence my request to add a g++ compiler option to disable this optimization.
[Bug c/47273] References to unaligned packed structure members not allowed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47273 --- Comment #5 from Waldemar Valdas Bancewicz waldemarbancewicz at ruggedcom dot com 2011-01-14 14:08:26 UTC --- Created attachment 22966 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22966 testcase
[Bug c++/47290] [4.5/4.6 Regression] memory exhausted compiling a destructor with an infinite 'for (;;);' loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47290 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||memory-hog Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.14 14:20:44 Summary|memory exhausted compiling |[4.5/4.6 Regression] memory |a destructor with an|exhausted compiling a |infinite 'for (;;);' loop |destructor with an infinite ||'for (;;);' loop Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-01-14 14:20:44 UTC --- confirmed as regression since 4.4 seems to stop allocating at about 10GB, then just consumes 100% cpu until killed
[Bug c++/47291] [4.6 Regression] ICE: SIGSEGV in size_binop_loc (fold-const.c:1427) with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47291 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug rtl-optimization/47245] New: [4.6 Regression] Invalid immediate offset for Thumb VFP store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47245 Summary: [4.6 Regression] Invalid immediate offset for Thumb VFP store Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: ibol...@gcc.gnu.org Host: arm-linux-gnueabi Target: arm-linux-gnueabi Build: arm-linux-gnueabi Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0 The following patch, which went into trunk as revision 168045, has made it possible for gcc to generate invalid offsets for some VFP stores: http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01349.html The range -1024 to +1024 is ok for 's' co-processor registers, but not for generic 'r' registers. The attached preprocessed source can be made to show the issue by compiling as follows: gcc -O3 -mthumb mcpu=cortex-a9 -mfloat-abi=softfp -mfpu=vfpv3-d16 besttry.i --save-temps The error caused is this: /tmp/ccxviNhV.s: Assembler messages: /tmp/ccxviNhV.s:37: Error: offset out of range I have attached the produced besttry.s. In the short-term, I suggest that we limit the negative offset, to be able to cover the case where VFP store ends up using general registers. I do not know how we could allow a larger negative offset for the 's' registers, when it is not known until later what type of register will get allocated.
[Bug fortran/47082] [4.6 Regression] [OOP] ICE in gfc_conv_component_ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47082 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug c++/46807] [4.6 Regression] internal compiler error: in synthesized_method_walk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46807 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug tree-optimization/47190] [4.5/4.6 Regression] ICE: in function_and_variable_visibility, at ipa.c:934 with static weakref variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47190 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.5.3
[Bug c++/47290] [4.5/4.6 Regression] memory exhausted compiling a destructor with an infinite 'for (;;);' loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47290 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.5.3
[Bug driver/47244] [4.6 Regression] plugin linker is used unconditionally
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47244 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-14 14:28:33 UTC --- It works. Got bitten by ./xgcc -B. t.c -v Reading specs from ./specs ... (again)
[Bug c++/47289] [C++0x] ICE in tsubst_pack_expansion (triggered by decltype)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47289 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||jason at redhat dot com --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2011-01-14 14:39:14 UTC --- ICE is caused by revision 145013: http://gcc.gnu.org/ml/gcc-cvs/2009-03/msg00520.html
[Bug debug/47292] New: Violation of DWARF-3 spec for DW_FORM_strp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47292 Summary: Violation of DWARF-3 spec for DW_FORM_strp Product: gcc Version: 4.4.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: p...@ca.ibm.com This version of the compiler marks its debug information as dwarf-3. This causes problems with a dwarf-3 compliant debugger when debugging 64 bit code. In section 7.4 32-Bit and 64-Bit DWARF Formats, the dwarf-3 spec says with regard to DW_FORM_strp: Within the body of the .debug_info section, certain forms of attribute value depend on the choice of DWARF format as follows. For the 32-bit DWARF format, the value is a 32-bit unsigned integer; for the 64-bit DWARF format, the value is a 64-bit unsigned integer. This version of the compiler is generating 32 bit integers for both 32 and 64 bit formats. This causes a compliant debugger to generate an incorrect pointer into the debug information. gcc -v reports: Using built-in specs. Target: ppc64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --enable-secureplt --with-long-double-128 --with-cpu-32=power4 --with-tune-32=power6 --with-cpu-64=power4 --with-tune-64=power6 --build=ppc64-redhat-linux Thread model: posix gcc version 4.4.4 20100726 (Red Hat 4.4.4-13) (GCC)
[Bug tree-optimization/47179] [4.5/4.6 Regression] SPU: errno misoptimization around malloc call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47179 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-14 15:02:27 UTC --- Author: rguenth Date: Fri Jan 14 15:02:20 2011 New Revision: 168788 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168788 Log: 2011-01-14 Richard Guenther rguent...@suse.de PR tree-optimization/47179 * target.def (ref_may_alias_errno): New target hook. * targhooks.h (default_ref_may_alias_errno): Declare. * targhooks.c: Include tree-ssa-alias.h and tree-flow.h. (default_ref_may_alias_errno): New function. * target.h (struct ao_ref_s): Declare. * tree-ssa-alias.c: Include target.h. (call_may_clobber_ref_p_1): Use the ref_may_alias_errno target hook. * Makefile.in (tree-ssa-alias.o): Adjust dependencies. (targhooks.o): Likewise. * doc/tm.texi.in (TARGET_REF_MAY_ALIAS_ERRNO): Document. * doc/tm.texi (TARGET_REF_MAY_ALIAS_ERRNO): Copy documentation. Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/doc/tm.texi trunk/gcc/doc/tm.texi.in trunk/gcc/target.def trunk/gcc/target.h trunk/gcc/targhooks.c trunk/gcc/targhooks.h trunk/gcc/tree-ssa-alias.c
[Bug tree-optimization/47179] [4.5/4.6 Regression] SPU: errno misoptimization around malloc call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47179 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added AssignedTo|rguenth at gcc dot gnu.org |uweigand at gcc dot gnu.org --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-14 15:04:16 UTC --- Re-assigning to Uli for the SPU part. I suggest not fixing this for 4.5 (it's a pretty arcane corner case anyway, esp. on SPU I guess).
[Bug fortran/47293] New: libquadmath: strtoflt128 - C99 hex floating point format missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47293 Summary: libquadmath: strtoflt128 - C99 hex floating point format missing Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org (At some point, I - or someone else - should really create a libquadmath component in Bugzilla.) Follow up to http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00369.html strtoflt128 currently does not support the C99 hex floating point format However, there is: gethex in gdtoa/strtodg.c (called from strtoflt128) thus it might already be implemented. From POSIX 2003 for strtod: The expected form of the subject sequence is an optional plus or minus sign, then one of the following: [...] * A 0x or 0X, then a non-empty sequence of hexadecimal digits optionally containing a radix character, then an optional binary exponent part
[Bug debug/47292] Violation of DWARF-3 spec for DW_FORM_strp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47292 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-14 15:19:29 UTC --- I think RedHat 4.4.4 is nowhere close to FSF GCC 4.4.x what debug info is concerned. Thus I would suggest to report this bug to RedHat and/or try to reproduce the issue with a stock FSF GCC.
[Bug fortran/47293] libquadmath: strtoflt128 - NAN not correctly read and C99 hex floating point format missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47293
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Summary|libquadmath: strtoflt128 - |libquadmath: strtoflt128 -
|C99 hex floating point |NAN not correctly read and
|format missing |C99 hex floating point
||format missing
--- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-14
15:36:52 UTC ---
Additional problem: The NAN string to float128 conversion does not seem to
work.
[The way NaN is printed by the float128-string conversion function is also a
bit odd, but it seems to work (with libgfortran).]
The program below prints:
+N.aN00e+02
+7.82797652694030368547e-4942
The a similar Fortran program prints (value printed as hex):
000 8000 -- for NaN (gfortran and ifort)
0 C000 0 -- for the NaN string (= 0.78280E-4941)
If one debugs gdtoa/strtodg.c, one sees that STRTOG_NaN is properly detected.
Thus, either the bits are wrong in strtodg -- or it is wrongly handled in
strtoflt128.
Example (strtoflt128 was called quadmath_strtopQ before renaming.)
#include quadmath.h
#include stdlib.h /* For abort. */
#include stdio.h /* For printf. */
int main ()
{
__float128 r;
char str[200];
r = nanq(NULL);
quadmath_dtoaq (str, sizeof (str), 20, r);
printf(%s\n, str);
r = 3.0q;
/* quadmath_strtopQ (NaN, NULL, r); */
r = strtoflt128 (NaN, NULL);
quadmath_dtoaq (str, sizeof (str), 20, r);
printf(%s\n, str);
if (!isnanq(r)) abort();
return 0;
}
[Bug target/46037] --enable-stage1-languages=c,lto --enable-languages=c,lto --with-build-config=bootstrap-lto fails on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46037 --- Comment #26 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-14 15:42:17 UTC --- Author: rguenth Date: Fri Jan 14 15:42:09 2011 New Revision: 168793 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168793 Log: 2011-01-14 Jan Hubicka j...@suse.cz Jack Howarth howa...@bromo.med.uc.edu PR target/46037 * config/darwin.c (darwin_override_options): Honor flag_gtoggle when checking debug_info_level. Test write_symbols instead of debug_hooks-var_location when setting flag_var_tracking_uninit. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin.c
[Bug c/47273] References to unaligned packed structure members not allowed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47273 --- Comment #6 from Waldemar Valdas Bancewicz waldemarbancewicz at ruggedcom dot com 2011-01-14 15:42:57 UTC --- About Comment #4: This is a question to the GCC/G++ team. How are unaligned pointers dealt with? I came up with the following possible options: (1) Compiler inserts the following code whenever a pointer is dereferenced: if b is aligned return address of b else do aligned read before pointer and after pointer, bitshift and mask each read and merge to get data Problems with this approach: - Unnecessary extra operations for each aligned pointer dereference. - The else part needs to be atomic and, since most architectures don't have such an atomic operation, we need to insert a disable interrupts and enable interrupts pair. It would be weird pushing this responsibility to the compiler since a compiler, in general, shouldn't know anything about how interrupts are implemented for a particular architecture. (2) Compiler pushes the responsibility to the hardware. (2.1) An unaligned memory accesses causes an exception and the above else part is done in the ISR. (2.2) An unaligned memory accesses is dealt with hardware. I don't see how option #1 is possible so, to my limited understanding, the compiler shouldn't care if memory accesses are aligned or not.
[Bug c++/47294] New: definition of function template can be explicitly-qualified with a namespace it isn't a member of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47294
Summary: definition of function template can be
explicitly-qualified with a namespace it isn't a
member of
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
namespace N
{
void f();
}
templatetypename T
void N::f(T) // ERROR does not match any declaration in N
{
}
int main()
{
::f(0);
}
This is forbidden by [namespace.memdef]p2 but g++ accepts it without error.
EDG, Clang and Sun reject it.
If there isn't an (incompatible) overload of N::f then g++ rejects it.
[Bug tree-optimization/14799] [tree-ssa] convert a sequence of ifs to a switch statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14799
Tom de Vries tom at codesourcery dot com changed:
What|Removed |Added
CC||tom at codesourcery dot com
--- Comment #3 from Tom de Vries tom at codesourcery dot com 2011-01-14
15:45:56 UTC ---
The example from the description field looks like this at tree level (optimized
dump with 4.5.1). It takes until late in the rtl untill the duplicate call
blocks are collapsed.
...
foo (int a)
{
bb 2:
if (a_1(D) == 30)
goto bb 3;
else
goto bb 4;
bb 3:
bar (); [tail call]
goto bb 10;
bb 4:
if (a_1(D) == 31)
goto bb 5;
else
goto bb 6;
bb 5:
bar (); [tail call]
goto bb 10;
bb 6:
if (a_1(D) == 53)
goto bb 7;
else
goto bb 8;
bb 7:
bar (); [tail call]
goto bb 10;
bb 8:
if (a_1(D) == 23)
goto bb 9;
else
goto bb 10;
bb 9:
bar (); [tail call]
bb 10:
return;
}
...
If the duplicate blocks would have been collapsed, it would look like this:
...
foo (int a)
{
bb 2:
if (a_1(D) == 30)
goto bb 9;
else
goto bb 4;
bb 4:
if (a_1(D) == 31)
goto bb 9;
else
goto bb 6;
bb 6:
if (a_1(D) == 53)
goto bb 9;
else
goto bb 8;
bb 8:
if (a_1(D) == 23)
goto bb 9;
else
goto bb 10;
bb 9:
bar (); [tail call]
bb 10:
return;
}
...
for this representation, the patch from PR 46935 comment 5 should work.
[Bug middle-end/46935] We should recognize expanded switch statement and convert 2 way switch statements into shift mask test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46935 --- Comment #6 from Tom de Vries tom at codesourcery dot com 2011-01-14 15:48:03 UTC --- Related bug: PR 14799.
[Bug fortran/46817] Missing copyright header in libquadmath/*.[hc]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46817 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|NEW Last reconfirmed||2011.01.14 15:53:53 Resolution|FIXED | Ever Confirmed|0 |1 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-14 15:53:53 UTC --- Reopen. The header mentions libiberty all over the place, e.g. This file is part of the libiberty library. which does not make sense. I should have updated the license after copying it. Thus: To do - change the bogus libiberty to libquadmath in the four files.
[Bug c++/47273] References to unaligned packed structure members not allowed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47273 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW Component|c |c++ --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-14 15:56:17 UTC --- I don't know why we do not allow references to bind to unaligned data, the Intel C++ compiler seems to accept the example. Pointers and references are the same as far as optimizers and code generation are concerned. For targets where the hardware cannot do unaligned loads/stores a read-and-mask/read-modify-write cycle is used. Accessing unaligned data can never be assumed to be atomic (not even with hardware unaligned load/store support as the data may cross cache-line boundaries).
[Bug c++/47294] definition of function template can be explicitly-qualified with a namespace it isn't a member of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47294 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-01-14 15:58:21 UTC --- some similarities to PR 42018
[Bug c++/47273] References to unaligned packed structure members not allowed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47273
--- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-14
16:02:06 UTC ---
It works with
typedef int T __attribute__((aligned(1)));
struct s {
T a;
T GetValr() { return a; }
} __attribute__((packed));
int main() {
struct s s1;
s1.GetValr() = 5;
}
so it's probably to guard you against crashes on targets that do
not support unaligned accesses (*(int) is aligned but s1.b is not).
Note that the above will still not do what is necessary for such
targets.
The pointer case is probably supported for legacy reasons.
[Bug fortran/47295] New: libquadmath: List __complex128 and constants in the .texi file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47295 Summary: libquadmath: List __complex128 and constants in the .texi file Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org libquadmath.h contains a typedef and several macros (constants), which should be listed in the documentation. typedef _Complex float __attribute__((mode(TC))) __complex128; // Macros #define FLT128_MAX 1.18973149535723176508575932662800702e4932Q #define FLT128_MIN 3.36210314311209350626267781732175260e-4932Q #define FLT128_EPSILON 1.92592994438723585305597794258492732e-34Q #define FLT128_DENORM_MIN 6.475175119438025110924438958227646552e-4966Q #define FLT128_MANT_DIG 113 #define FLT128_MIN_EXP (-16381) #define FLT128_MAX_EXP 16384 // TODO -- One day, we need to add the following macros: // FLT128_DIG, FLT128_MIN_10_EXP, FLT128_MAX_10_EXP #define HUGE_VALQ __builtin_huge_valq() The math constants are added via http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00332.html +#define M_Eq2.7182818284590452353602874713526625Q /* e */ +#define M_LOG2Eq1.4426950408889634073599246810018921Q /* log_2 e */ +#define M_LOG10Eq 0.4342944819032518276511289189166051Q /* log_10 e */ +#define M_LN2q 0.6931471805599453094172321214581766Q /* log_e 2 */ +#define M_LN10q 2.3025850929940456840179914546843642Q /* log_e 10 */ +#define M_PIq 3.1415926535897932384626433832795029Q /* pi */ +#define M_PI_2q 1.5707963267948966192313216916397514Q /* pi/2 */ +#define M_PI_4q 0.7853981633974483096156608458198757Q /* pi/4 */ +#define M_1_PIq 0.3183098861837906715377675267450287Q /* 1/pi */ +#define M_2_PIq 0.6366197723675813430755350534900574Q /* 2/pi */ +#define M_2_SQRTPIq 1.1283791670955125738961589031215452Q /* 2/sqrt(pi) */ +#define M_SQRT2q1.4142135623730950488016887242096981Q /* sqrt(2) */ +#define M_SQRT1_2q 0.7071067811865475244008443621048490Q /* 1/sqrt(2) */
[Bug target/46037] --enable-stage1-languages=c,lto --enable-languages=c,lto --with-build-config=bootstrap-lto fails on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46037 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #27 from Jack Howarth howarth at nitro dot med.uc.edu 2011-01-14 16:14:44 UTC --- Fixed at r168793.
[Bug fortran/47296] New: I/O Segfault when running out of file descriptors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47296 Summary: I/O Segfault when running out of file descriptors Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: jvdeli...@gcc.gnu.org Found at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/8843f2317cb565cd# On Linux, I need to use either much higher numbers ( 1024) or set the number of file descriptors down using, e.g. ulimit -S -n 20 Valgrind then shows: Begin assignment unit ** try to connect chosen unit = 27 ==26968== Warning: invalid file descriptor 25 in syscall open() ==26968== Use of uninitialised value of size 8 ==26968==at 0x4EFC6BF: _gfortrani_new_unit (open.c:509) ==26968==by 0x4EFC994: _gfortran_st_open (open.c:702) ==26968==by 0x400BF5: assignunit.1532 (hj4.f90:38)
[Bug c++/47291] [4.6 Regression] ICE: SIGSEGV in size_binop_loc (fold-const.c:1427) with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47291 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||dodji at gcc dot gnu.org --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2011-01-14 16:36:51 UTC --- It is caused by revision 168681: http://gcc.gnu.org/ml/gcc-cvs/2011-01/msg00299.html
[Bug c/47297] New: Inconsistent float-point to integer results depending on -O flag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47297
Summary: Inconsistent float-point to integer results depending
on -O flag
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mate...@loskot.net
The following program converts with truncation double precision float-point
value to signed 16-bit integer:
$ cat trunc-min.c
#include stdio.h
#include stdint.h
int main()
{
double a;
int16_t b;
a = -32769;
b = (int16_t)a;
printf(%d\n, b);
}
According to the C standard, behaviour of this program is undefined.
In spite of the fact the behavior is undefined, I suspect the intent
is to be consistent (which appears to be for lots of other
values I have tried), but they are not.
Different optimisation yields different result:
$ gcc -O0 trunc-min.c
$ ./a.out
32767
$ gcc -O2 trunc-min.c
$ ./a.out
-32768
A friend of mine advised me: in one case the cvttsd2si instruction is used
and for the other gcc does the conversion internally.
Though, I have no experience to confirm for sure.
I didn't find any reports about similar issues in the database. Though, closest
could be Bug 27682
Environment:
OS: x86_64 GNU/Linux (Ubuntu)
GCC: gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
[Bug c/47297] Inconsistent float-point to integer results depending on -O flag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47297 --- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot com 2011-01-14 17:04:30 UTC --- On Fri, 14 Jan 2011, mateusz at loskot dot net wrote: In spite of the fact the behavior is undefined, I suspect the intent is to be consistent (which appears to be for lots of other values I have tried), but they are not. No, the intent is not to be consistent. (The intent is that each instance of such a conversion executed in the abstract machine results in an unspecified value, as per C99 Annex F, rather than more fully optimizing based on undefined behavior, but not for anything more consistent than producing unspecified values.)
[Bug objc/45989] Some objc.dg-struct-layout-encoding-1 tests XPASS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45989 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-01/msg00996.htm ||l AssignedTo|unassigned at gcc dot |ro at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.6.0 --- Comment #10 from Rainer Orth ro at gcc dot gnu.org 2011-01-14 17:15:41 UTC --- Mine, patch submitted.
[Bug rtl-optimization/47245] [4.6 Regression] Invalid immediate offset for Thumb VFP store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47245 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org 2011-01-14 17:37:14 UTC --- Duplicate *** This bug has been marked as a duplicate of bug 47246 ***
[Bug target/47246] [4.6 Regression] Invalid immediate offset for Thumb VFP store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47246 --- Comment #3 from Richard Earnshaw rearnsha at gcc dot gnu.org 2011-01-14 17:37:14 UTC --- *** Bug 47245 has been marked as a duplicate of this bug. ***
[Bug c++/45940] [trans-mem] Error of unsafe function even if annotated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45940 --- Comment #12 from Aldy Hernandez aldyh at gcc dot gnu.org 2011-01-14 18:18:07 UTC --- Properly fixed here; awaiting approval. http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01003.html
[Bug go/47219] ICE mems_in_disjoint_alias_sets_p, at alias.c:401
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47219 --- Comment #2 from Ian Lance Taylor ian at airs dot com 2011-01-14 18:23:28 UTC --- Proposed patch at http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00916.html .
[Bug go/47219] ICE mems_in_disjoint_alias_sets_p, at alias.c:401
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47219 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-01-14 18:27:40 UTC --- sparc-sun-solaris2.11 bootstrap with Go included succeeded now (with a couple of libgo patches already posted), make check still running, but gcc/testsuite/go testresults look good: === go Summary === # of expected passes5746 # of unexpected failures16 # of expected failures48 # of untested testcases4 Thanks. Rainer
[Bug objc/45989] Some objc.dg-struct-layout-encoding-1 tests XPASS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45989 --- Comment #11 from Rainer Orth ro at gcc dot gnu.org 2011-01-14 18:47:53 UTC --- Author: ro Date: Fri Jan 14 18:47:50 2011 New Revision: 168806 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168806 Log: 2011-01-08 Dominique d'Humieres domi...@lps.ens.fr Rainer Orth r...@cebitec.uni-bielefeld.de PR objc/45989 * objc.dg/gnu-encoding/struct-layout-encoding-1_generate.c (switchfiles): XFAIL objc.dg-struct-layout-encoding-1/t02[57-9]_main.m execution tests on i?86-*-*, x86_64-*-*, and powerpc*-apple-darwin* ilp32. XFAIL objc.dg-struct-layout-encoding-1/t03[01]_main.m execution tests on i?86-*-* and x86_64-*-*. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/objc.dg/gnu-encoding/struct-layout-encoding-1_generate.c
[Bug objc/45989] Some objc.dg-struct-layout-encoding-1 tests XPASS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45989 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #12 from Rainer Orth ro at gcc dot gnu.org 2011-01-14 18:51:06 UTC --- Fixed for 4.6.0.
[Bug c++/45940] [trans-mem] Error of unsafe function even if annotated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45940 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED
[Bug c++/47273] References to unaligned packed structure members not allowed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47273 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #9 from Andrew Pinski pinskia at gcc dot gnu.org 2011-01-14 19:05:06 UTC --- This was an explicit change in the C++ front-end. See http://gcc.gnu.org/ml/gcc-patches/2003-07/msg01664.html .
[Bug fortran/38536] ICE with C_LOC in resolve.c due to not properly going through expr-ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38536 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Keywords|ice-on-valid-code |ice-on-invalid-code --- Comment #20 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-01-14 19:42:58 UTC --- (In reply to comment #19) Similarly, c_loc(comp(1:2)%elem) is valid as long as elem is the only item in the derived type *and* no padding is happening. (As padding often occurs, one could always reject it.) I don't think so, at least not in F 2003. comp(1:2) is an array slice, which is never interoperable. The language in F 2008 appears unchanged, so I guess the same applies there. And comp(1:1)%elem is always contiguous - but that's also a strange way of writing it. (Actually, I think that comp(1:1)%elem _is_ simply contiguous - though I am not sure gfc_simply_contiguous does detect this.) That would be fairly easy to change. Can you open a PR for this?
[Bug fortran/47296] I/O Segfault when running out of file descriptors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47296 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-14 19:48:26 UTC --- The problems seems to be that opp-file is not set for scratch files (STATUS_SCRATCH) when tempfile fails. Thus, open_external just returns. Then, in new_unit in the error handling block, opp-file_len is used and unpack_filename tries to read the string. However, accessing opp-file crashes in fstrlen. It might work if one sets file_len to 0 in tempfile. But maybe something cleverer can be done.
[Bug fortran/47296] I/O Segfault when running out of file descriptors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47296 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.01.14 19:52:52 AssignedTo|unassigned at gcc dot |jvdelisle at gcc dot |gnu.org |gnu.org Ever Confirmed|0 |1 --- Comment #2 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-01-14 19:52:52 UTC --- I will take this one.
[Bug fortran/47260] DLLEXPORT: TREE_PUBLIC for procedures lost between trans-decl.c and tree.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47260 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #13 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-14 20:01:06 UTC --- (In reply to comment #12) Rather more tricky to get gcc built in mingw than I would have liked, but... it's all fixed. I can export with DLLEXPORT or with a .def file. Thanks for the quick fix! Thanks for the feedback. Close as FIXED (on the 4.6 trunk) as I do not plan to backport it to 4.5.
[Bug libfortran/47285] G format outputs wrong number of characters when decimal supplied in literal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47285 --- Comment #3 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-01-14 20:01:18 UTC --- *** Bug 47284 has been marked as a duplicate of this bug. ***
[Bug libfortran/47284] G format outputs wrong number of asterixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47284 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-01-14 20:01:18 UTC --- This is actually the same bug as 47285. I am developing a more diverse test case as I work it. The exact spot is in write_float.def. Surprising sometimes how long we go before these show up. :) Thanks for bug reports. *** This bug has been marked as a duplicate of bug 47285 ***
[Bug middle-end/47298] New: -O3 destroys beautifully vectorized code obtained at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47298 Summary: -O3 destroys beautifully vectorized code obtained at -O2 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@pci.uzh.ch current trunk generates really fast vectorized code for the following testcase (a 12x12x12 matrix multiply, c=c+a*b, benchmarked with a,b,c in cache) as can be seen from the assembly: cat compare.f90 SUBROUTINE HARD_NN_12_12_12(C,A,B) REAL(KIND=8), INTENT(INOUT) :: C(12,*) REAL(KIND=8), INTENT(IN):: B(12,*), A(12,*) INTEGER ::i,j,l DO j=1,12 ; DO i=1,12; DO l=1,12 C(i,j)=C(i,j)+A(i,l)*B(l,j) ENDDO ; ENDDO ; ENDDO END SUBROUTINE HARD_NN_12_12_12 however, this only happens with: gfortran-trunk -O2 -funroll-loops -ftree-vectorize -ffast-math -march=corei7 -msse4.2 compare.f90 while switch -O2 to -O3 causes 'bad' code. gfortran-trunk -O3 -funroll-loops -ftree-vectorize -ffast-math -march=corei7 -msse4.2 compare.f90 with the following tester below -O2 runs in about 4.4s -O3 runs in about 7.0s cat test_compare.f90 REAL(KIND=8), DIMENSION(12,12) :: A,B,C A=0 ; B=0 ; C=0 DO I=1,1000 CALL HARD_NN_12_12_12(C,12,A,12,B,12) ENDDO END
[Bug middle-end/47298] -O3 destroys beautifully vectorized code obtained at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47298 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-14 20:43:15 UTC --- It's faster for me with -O3 (Athlon64, using -march=native).
[Bug middle-end/47298] -O3 destroys beautifully vectorized code obtained at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47298 --- Comment #2 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-01-14 20:52:54 UTC --- (In reply to comment #1) It's faster for me with -O3 (Athlon64, using -march=native). well not on model name : Intel(R) Xeon(R) CPU X5550 @ 2.67GHz stepping: 5 I have 8Gflops with -O2 and somewhat more than 4 with -O3 BTW, the proper test program is cat test_compare.f90 REAL(KIND=8), DIMENSION(12,12) :: A,B,C A=0 ; B=0 ; C=0 DO I=1,1000 CALL HARD_NN_12_12_12(C,A,B) ENDDO END
[Bug middle-end/47298] -O3 destroys beautifully vectorized code obtained at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47298 --- Comment #3 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-01-14 21:02:04 UTC --- Actually, also on AMD I have at -O2 9.4s -O3 11.8s model : 9 model name : AMD Opteron(tm) Processor 6176 SE stepping: 1
[Bug rtl-optimization/47299] New: Widening multiply optimization generates bad code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47299
Summary: Widening multiply optimization generates bad code
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: uweig...@gcc.gnu.org
CC: ber...@codesourcery.com, rguent...@suse.de
Building the following test case with current mainline on i386:
unsigned short test (unsigned char val) __attribute__ ((noinline));
unsigned short
test (unsigned char val)
{
return val * 255;
}
int
main(int argc, char**argv)
{
printf (test(val=40) = %x\n, test(0x40));
return 0;
}
We get the following (correct) output with -O0:
test(val=40) = 3fc0
and the following incorrect output with -O2:
test(val=40) = ffc0
The problem appears to be related to this piece of code in expand_expr_real2,
case WIDEN_MULT_EXPR:
expand_operands (treeop0, treeop1, NULL_RTX, op0, op1,
EXPAND_NORMAL);
temp = expand_widening_mult (mode, op0, op1, target,
unsignedp, this_optab);
expand_operands will expand the constant 255 into QImode and return a
(const_int -1) for op1. Passing this constant into expand_widening_mult then
apparently generates a simple negation operation in HImode instead (via
expand_const_mult) ...
It seems this code came in here:
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01327.html
Any suggestions how this ought to be handled?
[Bug c++/47289] [C++0x] ICE in tsubst_pack_expansion (triggered by decltype)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47289 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2011-01-14 21:26:50 UTC --- Author: jason Date: Fri Jan 14 21:26:47 2011 New Revision: 168822 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168822 Log: PR c++/47289 * pt.c (coerce_template_parms): Fix error recovery. Added: trunk/gcc/testsuite/g++.dg/cpp0x/variadic105.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/46933] [4.6 Regression] Revision 167781 failed g++.dg/other/first-global.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46933 Alexandre Oliva aoliva at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.01.14 21:33:47 CC||aoliva at gcc dot gnu.org AssignedTo|unassigned at gcc dot |aoliva at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Alexandre Oliva aoliva at gcc dot gnu.org 2011-01-14 21:33:47 UTC --- Mine
[Bug libstdc++/13631] Problems in messages
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13631 --- Comment #30 from François Dumont fdumont at gcc dot gnu.org 2011-01-14 21:36:34 UTC --- Created attachment 22967 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22967 locale message facet patch Hi Here is a patch proposition based on revision 168822. I can't apply it because the locale messages facet are not working on my platform, even without any patch. If I change my linux distrib or if they work after the next upgrade I will try to work on it again. For info a regression has been reported using this patch so it is surely not yet ready. François
[Bug c++/47289] [C++0x] ICE in tsubst_pack_expansion (triggered by decltype)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47289 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-01-14 21:41:31 UTC --- Fixed.
[Bug rtl-optimization/47299] Widening multiply optimization generates bad code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47299
--- Comment #1 from rguenther at suse dot de rguenther at suse dot de
2011-01-14 21:49:32 UTC ---
On Fri, 14 Jan 2011, uweigand at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47299
Summary: Widening multiply optimization generates bad code
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: uweig...@gcc.gnu.org
CC: ber...@codesourcery.com, rguent...@suse.de
Building the following test case with current mainline on i386:
unsigned short test (unsigned char val) __attribute__ ((noinline));
unsigned short
test (unsigned char val)
{
return val * 255;
}
int
main(int argc, char**argv)
{
printf (test(val=40) = %x\n, test(0x40));
return 0;
}
We get the following (correct) output with -O0:
test(val=40) = 3fc0
and the following incorrect output with -O2:
test(val=40) = ffc0
The problem appears to be related to this piece of code in expand_expr_real2,
case WIDEN_MULT_EXPR:
expand_operands (treeop0, treeop1, NULL_RTX, op0, op1,
EXPAND_NORMAL);
temp = expand_widening_mult (mode, op0, op1, target,
unsignedp, this_optab);
expand_operands will expand the constant 255 into QImode and return a
(const_int -1) for op1. Passing this constant into expand_widening_mult then
apparently generates a simple negation operation in HImode instead (via
expand_const_mult) ...
It seems this code came in here:
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01327.html
Any suggestions how this ought to be handled?
I think we need to pass the narrow mode explicitly.
Richard.
[Bug target/19162] [4.0 regression] ICE while building libobjc's sendmsg.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19162 --- Comment #15 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org 2011-01-14 21:50:17 UTC --- Author: mrs Date: Fri Jan 14 21:50:11 2011 New Revision: 168824 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=168824 Log: PR 19162 * objc-act.c (generate_struct_by_value_array): Do not output a definition for struct_forward_array. Modified: trunk/gcc/objc/ChangeLog
[Bug c++/47289] [C++0x] ICE in tsubst_pack_expansion (triggered by decltype)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47289 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org Target Milestone|4.6.0 |--- --- Comment #5 from Jason Merrill jason at gcc dot gnu.org 2011-01-14 22:22:19 UTC --- Fixed.
[Bug c++/46933] [4.6 Regression] Revision 167781 failed g++.dg/other/first-global.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46933 Alexandre Oliva aoliva at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED AssignedTo|aoliva at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #2 from Alexandre Oliva aoliva at gcc dot gnu.org 2011-01-14 22:29:47 UTC --- Fixed in revision 167791.
