[Bug c++/50258] New: -std=gnu++0x should allow in-class initialization of static const floating types without constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50258
Bug #: 50258
Summary: -std=gnu++0x should allow in-class initialization of
static const floating types without constexpr
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jyass...@gcc.gnu.org
In c++98 mode, gcc accepts in-class initialization of static const floating
members as an extension. This extension have been removed in C++0x mode, even
when gnu extensions are specifically requested with -std=gnu++0x. It would be
nice to keep the extension, especially since the C++0x draft was only changed
to disallow it in the FDIS.
$ gcc-4.6 --version
gcc-4.6 (GCC) 4.6.1
$ cat test.cc
struct Foo {
static const double d = 3.14;
};
const double Foo::d;
$ gcc-4.6 -c -Wall test.cc
$ gcc-4.6 -c -Wall -std=gnu++0x test.cc
test.cc:2:27: error: 'constexpr' needed for in-class initialization of static
data member 'd' of non-integral type
test.cc:4:19: error: 'const double Foo::d' is not a static member of 'struct
Foo'
test.cc:4:14: error: uninitialized const 'Foo::d' [-fpermissive]
$
[Bug ada/37245] GDB reports No definition of var1 in current context. for an existing variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37245 Arnaud Charlet charlet at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||charlet at gcc dot gnu.org Resolution||FIXED Target Milestone|--- |4.6.1 Known to fail|| --- Comment #6 from Arnaud Charlet charlet at gcc dot gnu.org 2011-09-01 06:33:31 UTC --- Closing then, thanks for checking
[Bug other/49533] [4.7 regression] Revision 174989 (ipa-inline-transform.c) regressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49533 --- Comment #10 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-09-01 06:44:39 UTC --- (In reply to comment #9) has this been fixed? No.
[Bug fortran/50259] New: Internal Error at (1): gfc_resolve_expr(): Bad expression type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50259 Bug #: 50259 Summary: Internal Error at (1): gfc_resolve_expr(): Bad expression type Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@pci.uzh.ch The following invalid code (note the continuation) MODULE cp_parser_types TYPE cp_parser_type CHARACTER(LEN=1) :: comment_character(2), CHARACTER (len=default_path_length), DIMENSION(:,:), POINTER :: initial_variables END TYPE cp_parser_type END MODULE cp_parser_types yields: Internal Error at (1): gfc_resolve_expr(): Bad expression type
[Bug tree-optimization/50178] [4.6 regression] ICE with gfortran -O3, not with gfortran -02
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50178
Ira Rosen irar at il dot ibm.com changed:
What|Removed |Added
CC||irar at il dot ibm.com
--- Comment #5 from Ira Rosen irar at il dot ibm.com 2011-09-01 07:01:07 UTC
---
The problem here is that in vectorizable_call we replace the original call with
a dummy stmt and also remove its stmt_vec_info, which causes the segfault when
we try to access it through related pattern stmt. I'm testing the following
patch that updates related pattern stmt to be the dummy stmt:
Index: tree-vect-stmts.c
===
--- tree-vect-stmts.c (revision 178373)
+++ tree-vect-stmts.c (working copy)
@@ -1583,6 +1583,14 @@ vectorizable_call (gimple stmt, gimple_stmt_iterat
new_stmt = gimple_build_assign (gimple_call_lhs (stmt),
build_zero_cst (type));
set_vinfo_for_stmt (new_stmt, stmt_info);
+ /* For pattern statements make the related statement to point to
+ NEW_STMT in order to be able to retrieve the original statement
+ information later. */
+ if (is_pattern_stmt_p (stmt_info))
+{
+ gimple related = STMT_VINFO_RELATED_STMT (stmt_info);
+ STMT_VINFO_RELATED_STMT (vinfo_for_stmt (related)) = new_stmt;
+}
set_vinfo_for_stmt (stmt, NULL);
STMT_VINFO_STMT (stmt_info) = new_stmt;
gsi_replace (gsi, new_stmt, false);
@@ -4957,11 +4965,7 @@ vect_transform_stmt (gimple stmt, gimple_stmt_iter
the stmt_info of ORIG_STMT_IN_PATTERN. See more details in the
documentation of vect_pattern_recog. */
if (STMT_VINFO_IN_PATTERN_P (stmt_vinfo))
- {
- gcc_assert (STMT_VINFO_RELATED_STMT (stmt_vinfo)
- == orig_scalar_stmt);
- STMT_VINFO_VEC_STMT (stmt_vinfo) = vec_stmt;
- }
+ STMT_VINFO_VEC_STMT (stmt_vinfo) = vec_stmt;
}
}
r175074 really fixed this problem since now we don't need to retrieve the
original def stmt.
[Bug fortran/50252] [OOP] Error message on call x%y (x not declared) can be more informative
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50252
--- Comment #3 from Arjen Markus arjen.markus895 at gmail dot com 2011-09-01
07:18:30 UTC ---
Hi Janus,
that seems quite to the point and it is much more straightforward than
my (minimal)
adjustment. Thanks.
The reason I brought this is that is a fairly recent addition and I
got puzzled by the
complaint that it was a syntax error.
Regards,
Arjen
2011/8/31 janus at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50252
--- Comment #2 from janus at gcc dot gnu.org 2011-08-31 19:31:10 UTC ---
Ok, here is one thing that could be easily done. Preliminary patch, not
regtested. Does this sound like an improvement?
Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c (revision 178293)
+++ gcc/fortran/match.c (working copy)
@@ -3639,15 +3639,24 @@ done:
}
-/* Match the call of a type-bound procedure, if CALL%var has already been
- matched and var found to be a derived-type variable. */
+/* Match the call of a type-bound procedure, if 'CALL var' has already been
+ matched. */
static match
match_typebound_call (gfc_symtree* varst)
{
gfc_expr* base;
+ gfc_symbol *sym;
match m;
+ sym = varst-n.sym;
+ if (sym-ts.type != BT_DERIVED sym-ts.type != BT_CLASS)
+ {
+ gfc_error (Base object '%s' in type-bound procedure call at %C
+ is not of derived type, sym-name);
+ return MATCH_ERROR;
+ }
+
base = gfc_get_expr ();
base-expr_type = EXPR_VARIABLE;
base-symtree = varst;
@@ -3718,7 +3727,7 @@ gfc_match_call (void)
procedure call. */
if ((sym-attr.flavor != FL_PROCEDURE
|| gfc_is_function_return_value (sym, gfc_current_ns))
- (sym-ts.type == BT_DERIVED || sym-ts.type == BT_CLASS))
+ gfc_peek_char() == '%')
return match_typebound_call (st);
/* If it does not seem to be callable (include functions so that the
--
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You reported the bug.
[Bug middle-end/50260] New: internal compiler error: Segmentation fault at ../../gcc/gcc/tree-ssa-live.c:88
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50260 Bug #: 50260 Summary: internal compiler error: Segmentation fault at ../../gcc/gcc/tree-ssa-live.c:88 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@pci.uzh.ch this started failing in the last 48h or so, with the following stack trace Program received signal SIGSEGV, Segmentation fault. var_map_base_init (map=0x16bb070) at ../../gcc/gcc/tree-ssa-live.c:88 88if (!ann-base_var_processed) (gdb) bt #0 var_map_base_init (map=0x16bb070) at ../../gcc/gcc/tree-ssa-live.c:88 #1 0x009dd3f2 in coalesce_ssa_name () at ../../gcc/gcc/tree-ssa-coalesce.c:1397 #2 0x009909a9 in remove_ssa_form (sa=0x14adce0) at ../../gcc/gcc/tree-outof-ssa.c:909 #3 rewrite_out_of_ssa (sa=0x14adce0) at ../../gcc/gcc/tree-outof-ssa.c:1143 #4 0x0066173b in gimple_expand_cfg () at ../../gcc/gcc/cfgexpand.c:4152 #5 0x0088a3b7 in execute_one_pass (pass=0x149e7e0) at ../../gcc/gcc/passes.c:2063 #6 0x0088a725 in execute_pass_list (pass=0x149e7e0) at ../../gcc/gcc/passes.c:2118 #7 0x0098e01e in tree_rest_of_compilation (fndecl=0x75b49300) at ../../gcc/gcc/tree-optimize.c:420 #8 0x006812c6 in cgraph_expand_function (node=0x77e7fea0) at ../../gcc/gcc/cgraphunit.c:1797 #9 0x0068300b in cgraph_expand_all_functions () at ../../gcc/gcc/cgraphunit.c:1856 #10 cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:2126 #11 0x0068369a in cgraph_finalize_compilation_unit () at ../../gcc/gcc/cgraphunit.c:1310 #12 0x0083e8fd in write_global_declarations () at ../../gcc/gcc/langhooks.c:303 #13 0x0092bf22 in compile_file (argc=15, argv=0x7fffdb38) at ../../gcc/gcc/toplev.c:564 #14 do_compile (argc=15, argv=0x7fffdb38) at ../../gcc/gcc/toplev.c:1886 #15 toplev_main (argc=15, argv=0x7fffdb38) at ../../gcc/gcc/toplev.c:1962 #16 0x763c5b7d in __libc_start_main () from /lib64/libc.so.6 #17 0x0050317d in _start () at ../sysdeps/x86_64/elf/start.S:113 testcase: MODULE cp_parser_methods INTEGER, PARAMETER :: default_string_length=80 INTEGER, PARAMETER :: default_path_length=250 TYPE ilist_type LOGICAL :: in_use END TYPE ilist_type TYPE cp_parser_type CHARACTER(LEN=default_path_length) :: ifn INTEGER:: icol,icol1,icol2 TYPE(ilist_type), POINTER :: ilist END TYPE cp_parser_type TYPE cp_error_type END TYPE cp_error_type CONTAINS FUNCTION cts(i) RESULT(res) CHARACTER(len=6) :: res END FUNCTION cts FUNCTION parser_location(parser,error) RESULT(res) TYPE(cp_parser_type), POINTER:: parser TYPE(cp_error_type), INTENT(inout) :: error CHARACTER(len=default_path_length+default_string_length) :: res LOGICAL :: failure IF (.NOT. failure) THEN res=file:'//TRIM(parser%ifn)//' line://cts(parser%icol) END IF END FUNCTION parser_location SUBROUTINE parser_get_integer(parser,at_end, error) TYPE(cp_parser_type), POINTER:: parser TYPE(cp_error_type), INTENT(inout) :: error LOGICAL :: failure, my_at_end IF (.NOT.failure) THEN IF (.NOT.parser%ilist%in_use) THEN CALL cp_assert(A// TRIM(parser_location(parser,error))) END IF END IF END SUBROUTINE parser_get_integer SUBROUTINE parser_get_string(parser,at_end,error) TYPE(cp_parser_type), POINTER:: parser LOGICAL, INTENT(out), OPTIONAL :: at_end TYPE(cp_error_type), INTENT(inout) :: error LOGICAL :: failure, my_at_end IF (.NOT.failure) THEN IF (PRESENT(at_end)) THEN CALL cp_assert(s//TRIM(parser_location(parser,error))) END IF END IF END SUBROUTINE parser_get_string END MODULE cp_parser_methods fails at gfortran -O3 bug.f90 compiles at gfortran -O2 bug.f90
[Bug fortran/50259] Internal Error at (1): gfc_resolve_expr(): Bad expression type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50259 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-09-01 07:57:03 UTC --- With all of my GCC version (4.1, 4.3, 4.4, 4.5, 4.6 and 4.7), I get the following error: CHARACTER (len=default_path_length), DIMENSION(:,:), POINTER :: 1 Error: Expected another dimension in array declaration at (1) This is followed by some more errors. In GCC 4.4, 4.5, 4.6, I get as last error the mentioned ICE: Internal Error at (1): gfc_is_constant_expr(): Unknown expression type While with GCC 4.1 and 4.3 but also with GCC 4.7 (2011-08-31, Rev. 178351) I do not get an ICE.
[Bug c++/50261] New: [c++0x] ICE on brace-initialize an array member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50261
Bug #: 50261
Summary: [c++0x] ICE on brace-initialize an array member
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kikair...@gmail.com
An ICE occurs with this code:
template typename T
struct ca {
T elem[1];
// ICE occurs ...
ca(const T (s)[1]): elem{{s}} { } // here
//ca(const T (s)[1]): elem({{s}}) { } // or here.
//ca(const T (s)[1]): elem(s) { } // but not here (rejects correctly.)
//ca(const T (s)[1]): elem{s} { } // also rejects correctly.
// also occurs ...
ca(const T v): elem{{v}} { } // here
//ca(const T v): elem{{{v}}} { } // and here, or more braces.
//ca(const T v): elem{v} { } // pass.
//ca(const T v): elem({v}) { } // pass (with warning).
};
int main() {
int a[1] = {0};
caint d(a);
caint e(a[0]);
}
causes:
test.cc: In instantiation of 'caT::ca(const T ()[1]) [with T = int]':
test.cc:20:13: required from here
test.cc:6:31: internal compiler error: in cxx_eval_bare_aggregate, at
cp/semantics.c:6679
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-snapshot/README.Bugs for instructions.
tested:
gcc version 4.6.1 (Debian 4.6.1-3)
gcc version 4.7.0 20110816 (experimental) [trunk revision 177785] (Debian
20110816-1)
[Bug target/50242] __attribute__((naked)) is not implemented on IA32 (x86)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50242
--- Comment #4 from congruwer at yahoo dot co.uk 2011-09-01 08:09:59 UTC ---
Doesn't work:
---(start)---
inline __attribute__((always_inline)) void foobar();
asm (.globl __6foobarv; .type __6foobarv, @function;\n
__6foobarv: ret; .size __6foobarv, . - __6foobarv;\n);
void test()
{
foobar();
}
---(end)---
test.cpp:1:44: error: inline function 'void foobar()' used but never defined
[Bug target/50242] __attribute__((naked)) is not implemented on IA32 (x86)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50242 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-09-01 08:12:30 UTC --- Obviously it can't be inline... You can't inline a naked function either.
[Bug c++/34949] Dead code in empty destructors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949 congruwer at yahoo dot co.uk changed: What|Removed |Added CC||congruwer at yahoo dot ||co.uk --- Comment #8 from congruwer at yahoo dot co.uk 2011-09-01 08:12:49 UTC --- I have seen a very similar problem in empty constructors.
[Bug tree-optimization/50178] [4.6 regression] ICE with gfortran -O3, not with gfortran -02
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50178 --- Comment #6 from irar at gcc dot gnu.org 2011-09-01 08:29:41 UTC --- Author: irar Date: Thu Sep 1 08:29:33 2011 New Revision: 178396 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178396 Log: PR tree-optimization/50178 * tree-vect-stmts.c (vectorizable_call): Update the related pattern statement before deleting the original call. (vect_transform_stmt): Don't expect the related pattern statement to match the original statement after transformation. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/vect/pr50178.f90 Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/tree-vect-stmts.c
[Bug c++/50255] Linker stumbles over non-grouped text/rodata for a non-virtual thunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50255 Caolan McNamara caolanm at redhat dot com changed: What|Removed |Added CC||caolanm at redhat dot com, ||jakub at redhat dot com --- Comment #3 from Caolan McNamara caolanm at redhat dot com 2011-09-01 08:29:54 UTC --- caolanm-jakub: this is the one I mentioned as FOSDEM 11. caolanm-sberg: able to attach something standalone that can reproduce this, i.e. .ii
[Bug target/50256] AVR GCC - several unnecessary register moves
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50256 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011-09-01 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-01 08:35:16 UTC --- GCC 4.3.x is no longer maintained, please try a newer version.
[Bug c/50254] gcc-4.5 -fstrict-aliasing -fschedule-insns optimization produces wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50254
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-01
08:38:15 UTC ---
qentry-next = (void *)qhead;
is voiolating strict aliasing rules if you ever end up loading/storing
qentry-next-{prev,next}.
[Bug c++/50255] Linker stumbles over non-grouped text/rodata for a non-virtual thunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50255 --- Comment #4 from Stephan Bergmann stephan.bergmann.secondary at googlemail dot com 2011-09-01 08:39:59 UTC --- caolanm: will work on it, yes (wanted to clarify first whether looking at those group name mismatches is actually looking in the right direction)
[Bug tree-optimization/50178] [4.6 regression] ICE with gfortran -O3, not with gfortran -02
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50178 --- Comment #7 from irar at gcc dot gnu.org 2011-09-01 08:47:05 UTC --- Author: irar Date: Thu Sep 1 08:46:59 2011 New Revision: 178397 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178397 Log: PR tree-optimization/50178 * gfortran.dg/vect/pr50178.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/vect/pr50178.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug libobjc/49804] regression gcc4.7 from 20110709 to 20110716 on ia64, sparc64 freebsd9.0 Configuration mismatch! [libgcc-extra-parts] Error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49804
--- Comment #2 from Anton Shterenlikht mexas at bristol dot ac.uk 2011-09-01
08:52:43 UTC ---
I haven't looked at it for a while.
It seems ia64 is indeed fixed, I've built gcc-4.7.0.20110730.
However sparc64 still gives this error.
Building 4.7.0.20110730:
gmake[3]: Leaving directory `/usr/ports/lang/gcc47/work/build/gcc'
Checking multilib configuration for libgcc...
gmake[3]: Entering directory
`/usr/ports/lang/gcc47/work/build/sparc64-portbld-freebsd9.0/libgcc'
# If this is the top-level multilib, build all the other
# multilibs.
gmake[4]: Entering directory
`/usr/ports/lang/gcc47/work/build/sparc64-portbld-freebsd9.0/libgcc'
if [ -z ]; then \
true; \
else \
rootpre=`${PWDCMD-pwd}`/; export rootpre; \
srcrootpre=`cd ../.././../gcc-4.7-20110730/libgcc; ${PWDCMD-pwd}`/; export
srcrootpre; \
lib=`echo ${rootpre} | sed -e 's,^.*/\([^/][^/]*\)/$,\1,'`; \
compiler=/usr/ports/lang/gcc47/work/build/./gcc/xgcc
-B/usr/ports/lang/gcc47/work/build/./gcc/ -
B/usr/local/sparc64-portbld-freebsd9.0/bin/
-B/usr/local/sparc64-portbld-freebsd9.0/lib/ -isystem /
usr/local/sparc64-portbld-freebsd9.0/include -isystem
/usr/local/sparc64-portbld-freebsd9.0/sys-inc
lude ; \
for i in `${compiler} --print-multi-lib 2/dev/null`; do \
dir=`echo $i | sed -e 's/;.*$//'`; \
if [ ${dir} = . ]; then \
true; \
else \
if [ -d ../${dir}/${lib} ]; then \
flags=`echo $i | sed -e 's/^[^;]*;//' -e 's/@/ -/g'`; \
if (cd ../${dir}/${lib}; gmake
AR=/usr/local/sparc64-portbld-freebsd9.0/bin/ar AR_FLAGS=
rc CC=/usr/ports/lang/gcc47/work/build/./gcc/xgcc
-B/usr/ports/lang/gcc47/work/build/./gcc/ -B/us
r/local/sparc64-portbld-freebsd9.0/bin/
-B/usr/local/sparc64-portbld-freebsd9.0/lib/ -isystem /usr/
local/sparc64-portbld-freebsd9.0/include -isystem
/usr/local/sparc64-portbld-freebsd9.0/sys-include
CFLAGS=-g -O2 -pipe -I/usr/local/include -fno-strict-aliasing DESTDIR=
EXTRA_OFILES= HD
EFINES= INSTALL=/usr/bin/install -c -o root -g wheel INSTALL_DATA=install
-o root -g wheel -m
444 INSTALL_PROGRAM=install -s -o root -g wheel -m 555 LDFLAGS=
LOADLIBES= RANLIB=/usr/loc
al/sparc64-portbld-freebsd9.0/bin/ranlib SHELL=/bin/sh prefix=/usr/local
exec_prefix=/usr/loc
al libdir=/usr/local/lib/gcc47
libsubdir=/usr/local/lib/gcc47/gcc/sparc64-portbld-freebsd9.0/4.
7.0 tooldir=/usr/local/sparc64-portbld-freebsd9.0 \
CFLAGS=-g -O2 -pipe -I/usr/local/include
-fno-strict-aliasing ${flags} \
CCASFLAGS= ${flags} \
FCFLAGS= ${flags} \
FFLAGS= ${flags} \
ADAFLAGS= ${flags} \
prefix=/usr/local \
exec_prefix=/usr/local \
GCJFLAGS= ${flags} \
GOCFLAGS=-O2 -g ${flags} \
CXXFLAGS=-g -O2 -pipe -I/usr/local/include
-fno-strict-aliasing ${flags}
\
LIBCFLAGS=-g -O2 -pipe -I/usr/local/include
-fno-strict-aliasing ${flags}
\
LIBCXXFLAGS=-g -O2 -pipe -I/usr/local/include
-fno-strict-aliasing -fno-im
plicit-templates ${flags} \
LDFLAGS= ${flags} \
MULTIFLAGS=${flags} \
DESTDIR= \
INSTALL=/usr/bin/install -c -o root -g wheel \
INSTALL_DATA=install -o root -g wheel -m 444 \
INSTALL_PROGRAM=install -s -o root -g wheel -m 555 \
INSTALL_SCRIPT=install -o root -g wheel -m 555 \
all); then \
true; \
else \
exit 1; \
fi; \
else true; \
fi; \
fi; \
done; \
fi
gmake[4]: Leaving directory
`/usr/ports/lang/gcc47/work/build/sparc64-portbld-freebsd9.0/libgcc'
# If the gcc directory specifies which extra parts to
# build for this target, and the libgcc configuration also
# specifies, make sure they match. This can be removed
# when the gcc directory no longer holds libgcc configuration;
# it is useful when migrating a target.
Configuration mismatch!
Extra parts from gcc directory: crtbegin.o crtbeginS.o crtend.o crtendS.o
crtfastmath.o
Extra parts from libgcc: crtfastmath.o
exit 1
gmake[3]: *** [libgcc-extra-parts] Error 1
gmake[3]: Leaving directory
`/usr/ports/lang/gcc47/work/build/sparc64-portbld-freebsd9.0/libgcc'
gmake[2]: *** [all-stage1-target-libgcc] Error 2
gmake[2]: Leaving directory `/usr/ports/lang/gcc47/work/build'
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory `/usr/ports/lang/gcc47/work/build'
gmake: *** [bootstrap-lean] Error 2
*** Error code 1
Stop in /usr/ports/lang/gcc47.
*** Error code 1
[Bug middle-end/50260] [4.7 Regression] internal compiler error: Segmentation fault at ../../gcc/gcc/tree-ssa-live.c:88
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50260 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-01 CC||matz at gcc dot gnu.org Target Milestone|--- |4.7.0 Summary|internal compiler error:|[4.7 Regression] internal |Segmentation fault at |compiler error: |../../gcc/gcc/tree-ssa-live |Segmentation fault at |.c:88 |../../gcc/gcc/tree-ssa-live ||.c:88 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-01 08:59:54 UTC --- Confirmed. The PARM_DECL never has its var_ann allocated (it's the string result length). It's also unused which is why it doesn't have an annotation. Probably Michas change triggered this.
[Bug tree-optimization/50178] [4.6 regression] ICE with gfortran -O3, not with gfortran -02
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50178 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #8 from Ira Rosen irar at il dot ibm.com 2011-09-01 09:05:01 UTC --- Fixed.
[Bug libstdc++/50257] [C++0x] unordered_map slow initialization due to huge __prime_list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50257 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Summary|unordered_map slow |[C++0x] unordered_map slow |initialization due to huge |initialization due to huge |__prime_list|__prime_list --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-01 09:06:47 UTC --- Indeed, this is the right place to ask, but also consider the mailing list for anything not strictly speaking a bug but an enhancement. Anyway, to begin with, we can definitely special case the default value of 10 and avoid the lower_bound call, seems a sensible optimization anyway, but to be honest I'm a bit surprised that you can see that in the profile vs, eg, the time spent allocating memory in _M_allocate_buckets immediately afterward. Can you clarify this?
[Bug c++/34949] Dead code in empty destructors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949 --- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2011-09-01 09:10:11 UTC --- It looks to me that the C++ FE could detect that the vtable pointer update would adjust it to itself (I even can't construct a testcase that would adjust it _not_ to itself ...).
[Bug target/50242] __attribute__((naked)) is not implemented on IA32 (x86)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50242 --- Comment #6 from congruwer at yahoo dot co.uk 2011-09-01 09:16:18 UTC --- Why not? In any case, without inline it also doesn't work: test.s: Assembler messages: test.s:628: Warning: .type pseudo-op used outside of .def/.endef ignored. test.s:628: Error: junk at end of line, first unrecognized character is `_' test.s:629: Warning: .size pseudo-op used outside of .def/.endef ignored. test.s:629: Error: junk at end of line, first unrecognized character is `_' I've tried fixing the problem, but made no headway. I can get gas so swallow it by copying what the C++ compiler emits for a function, but that just gives a linker error later on: test.cpp:16: undefined reference to `foobar()' In any case, the function really should be inline... what now? Use sed to edit the .s file? Will that preserve C++ line number information? (Debugging would be a real pain if all the line numbers were shifted by a byte or two.)
[Bug target/50242] __attribute__((naked)) is not implemented on IA32 (x86)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50242 --- Comment #7 from congruwer at yahoo dot co.uk 2011-09-01 09:21:33 UTC --- Answering my own question: because of the ret instruction. Duh.
[Bug libstdc++/50257] [C++0x] unordered_map slow initialization due to huge __prime_list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50257 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-01 09:23:59 UTC --- Created attachment 25156 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25156 Mainline patchlet optimizing for 10
[Bug libstdc++/50257] [C++0x] unordered_map slow initialization due to huge __prime_list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50257 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-01 09:27:04 UTC --- I just attached a patchlet (vs mainline, 4.6.x may require a bit of tweaking, the patch is trivial anyway) implementing the straightforward optimization for the value of 10. Please let me know how it does on your code.
[Bug c++/34949] Dead code in empty destructors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2011-09-01
09:31:54 UTC ---
Of course the C++ FE adjusts it to its vtable, it is needed if the body
of the dtor or anything it calls needs to use it.
Andrew's suggestion IMHO makes sense, perhaps using Micha's proposal to say
that
at the end of a destructor *this = volatile{};
Then DSE could happily nuke the vtable ptr stores (or any other stores to the
object being destructed).
[Bug c/50254] gcc-4.5 -fstrict-aliasing -fschedule-insns optimization produces wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50254
Vladimir Zapolskiy vzapolskiy at gmail dot com changed:
What|Removed |Added
Attachment #25154|0 |1
is obsolete||
--- Comment #2 from Vladimir Zapolskiy vzapolskiy at gmail dot com 2011-09-01
09:37:00 UTC ---
Created attachment 25157
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25157
test code
(In reply to comment #1)
qentry-next = (void *)qhead;
is voiolating strict aliasing rules if you ever end up loading/storing
qentry-next-{prev,next}.
Thank you very much for the quick response.
I managed to reduce a test case and hopefully understand strict aliasing rules.
[Bug c/50254] gcc-4.5 -fstrict-aliasing -fschedule-insns optimization produces wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50254 Vladimir Zapolskiy vzapolskiy at gmail dot com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #3 from Vladimir Zapolskiy vzapolskiy at gmail dot com 2011-09-01 09:37:33 UTC --- Closed, thanks.
[Bug tree-optimization/49960] inconsistant outputs when enabling autopar for a self -dependence testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49960
--- Comment #2 from razya at gcc dot gnu.org 2011-09-01 09:57:21 UTC ---
(In reply to comment #1)
Created attachment 24901 [details]
self dependence testcase
Another testcase failing due to a slightly different problem with the self data
dependence analysis:
#include stdio.h
#define MB 100
#define NA 70
#define MA 80
int T[MB][MA],A[MA][NA],B[MB][NA];
void MRTRBR(int MA_1, int NA_1, int MB_1)
{
int i,j, t,k;
for (k = 3; k NA_1; k++)
for (i= 3; i MA_1; i++)
for (j = 3; j MB_1; j++)
{
t = T[i][j];
T[i][j] = t+2+A[i][k]*B[j][k];
}
}
void main ()
{
int j,i;
for (i= 3; i MA; i++)
for (j = 3; j MB; j++)
T[i][j] = (ij?i:j);
MRTRBR (MA,NA,MB);
for (i= MA-1; i MA; i++)
for (j = MB-10; j MB; j++)
printf (i %d j %d T[i][j] = %d\n,i,j,T[i][j]);
}
autopar parallelizes the k loop (I reduced the threshold of # of iterations to
enable parallelization of the outer loop), because
the data dependence analysis claims that the dependence between
the writes to T[i][j] is (0,0,0).
This causes inconsistent runs:
./a.out
i 79 j 90 T[i][j] = 216
i 79 j 91 T[i][j] = 217
i 79 j 92 T[i][j] = 220
i 79 j 93 T[i][j] = 219
i 79 j 94 T[i][j] = 222
i 79 j 95 T[i][j] = 221
i 79 j 96 T[i][j] = 222
i 79 j 97 T[i][j] = 223
i 79 j 98 T[i][j] = 224
i 79 j 99 T[i][j] = 225
./a.out
i 79 j 90 T[i][j] = 224
i 79 j 91 T[i][j] = 225
i 79 j 92 T[i][j] = 226
i 79 j 93 T[i][j] = 227
i 79 j 94 T[i][j] = 228
i 79 j 95 T[i][j] = 229
i 79 j 96 T[i][j] = 230
i 79 j 97 T[i][j] = 231
i 79 j 98 T[i][j] = 232
i 79 j 99 T[i][j] = 233
[Bug middle-end/50262] New: PTA doesn't disambiguate locally allocated heap objects from pointed to by arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50262
Bug #: 50262
Summary: PTA doesn't disambiguate locally allocated heap
objects from pointed to by arguments
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: rgue...@gcc.gnu.org
char *r;
char
foo (char *p, int len)
{
char *q = __builtin_malloc (len);
*p = 1;
*q = 2;
r = q;
return *p;
}
doesn't optimize return *p; into return 1; even when *q store can't alias *p.
This matters e.g. for the string length optimization I'm working on.
Testcase for the latter is e.g.:
#include string.h
#include stdlib.h
char *
foo (char *p, char *r)
{
char *q = malloc (strlen (p) + strlen (r) + 64);
if (q == NULL) return NULL;
strcpy (q, p);
strcat (q, /);
strcat (q, abcde);
strcat (q, r);
strcat (q, /);
return q;
}
[Bug target/50193] ARM: ICE on a | (b negative-constant)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50193 Andrew Stubbs ams at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-09-01 CC||ams at gcc dot gnu.org AssignedTo|unassigned at gcc dot |ams at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Andrew Stubbs ams at gcc dot gnu.org 2011-09-01 10:19:03 UTC --- The problem appears to be that the predicate accepts any constant, without checking the range. I'll post a patch shortly.
[Bug middle-end/50262] PTA doesn't disambiguate locally allocated heap objects from pointed to by arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50262 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||alias Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-09-01 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-09-01 11:10:21 UTC --- Mine. I have some partial patches somewhere and at least an idea how to start to disentangle the mess that causes us to give up here.
[Bug fortran/50252] [OOP] Error message on call x%y (x not declared) can be more informative
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50252 --- Comment #4 from janus at gcc dot gnu.org 2011-09-01 11:28:35 UTC --- Unfortunately the patch in comment #2 did not survive the regression test. It fails at least on: FAIL: gfortran.dg/dynamic_dispatch_10.f03 -O0 (test for excess errors) FAIL: gfortran.dg/coarray_14.f90 -O (test for errors, line 39) FAIL: gfortran.dg/coarray_8.f90 -O (test for errors, line 36) FAIL: gfortran.dg/proc_ptr_comp_pass_6.f90 -O (test for excess errors) FAIL: gfortran.dg/typebound_call_12.f03 -O (test for excess errors) FAIL: gfortran.dg/typebound_call_14.f03 -O (test for excess errors) FAIL: gfortran.dg/typebound_call_4.f03 -O (test for errors, line 41)
[Bug libstdc++/50257] [C++0x] unordered_map slow initialization due to huge __prime_list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50257 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-01 11:31:42 UTC --- Created attachment 25158 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25158 Alternate patchlet Or we can do this, which optimizes 0 too, should be also useful.
[Bug tree-optimization/50208] [4.7 Regression] ICE: in vinfo_for_stmt at tree-vectorizer.h:598 with -ftree-vectorize -fno-tree-fre -fno-tree-pre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50208 --- Comment #3 from Ira Rosen irar at il dot ibm.com 2011-09-01 11:42:24 UTC --- Created attachment 25159 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25159 patch Right. The attached patch does the suggested checks also in vect_handle_widen_mult_by_const(). I'll test it on Sunday. Thanks, Ira
[Bug tree-optimization/50208] [4.7 Regression] ICE: in vinfo_for_stmt at tree-vectorizer.h:598 with -ftree-vectorize -fno-tree-fre -fno-tree-pre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50208 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added CC||irar at il dot ibm.com --- Comment #4 from Ira Rosen irar at il dot ibm.com 2011-09-01 11:44:19 UTC --- (In reply to comment #2) I have no idea whether this can be invoked from slp vectorizer and what to do in that case. Pattern detection is not called from SLP at the moment.
[Bug c++/50258] [C++0x] -std=gnu++0x should allow in-class initialization of static const floating types without constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50258 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-09-01 11:51:36 UTC --- That extension has been deprecated for years: http://gcc.gnu.org/onlinedocs/gcc/Deprecated-Features.html
[Bug c++/50255] Linker stumbles over non-grouped text/rodata for a non-virtual thunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50255 --- Comment #5 from Stephan Bergmann stephan.bergmann.secondary at googlemail dot com 2011-09-01 12:10:54 UTC --- By the way, the problem of the rodata section having a different GroupName than the text section is also present when you compile vbasheetobjects.cxx with plain (non-RedHat-modified) GCC 4.6.0 and GCC 4.6.1, respectively.
[Bug ada/50263] New: Constant integer in multidimensional array 'Range(X) crashes GNAT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50263 Bug #: 50263 Summary: Constant integer in multidimensional array 'Range(X) crashes GNAT Classification: Unclassified Product: gcc Version: 4.4.6 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: gnub...@lyse.isobeef.org Created attachment 25160 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25160 Sample Ada source code to show the crash When using a constant integer in a 'Range(X) value of an multidimensional array, gnatmake crashes with a bug box. However, using a constant works. Having the following definitions type Matrix_Type is array (1..3, 1..3) of Integer; First_Range : constant Integer := 1; Matrix : Matrix_Type := (others = (others = 0)); GNAT will crash when compiling Matrix'Range(First_Range) When First_Range is replaced by First_Range : constant := 1; everything is fine. See attached source code to reproduce this. I'm using GNATMAKE 4.4.6 from Debian Testing. $ gnatmake constant_integer_as_array_range_value_crashes_gnat.adb gcc-4.4 -c constant_integer_as_array_range_value_crashes_gnat.adb +===GNAT BUG DETECTED==+ | 4.4.6 (i486-pc-linux-gnu) Assert_Failure sinfo.adb:1563 | | Error detected at constant_integer_as_array_range_value_crashes_gnat.adb:15:19| | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc-4.4 or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. constant_integer_as_array_range_value_crashes_gnat.adb compilation abandoned gnatmake: constant_integer_as_array_range_value_crashes_gnat.adb compilation error Exit code 4.
[Bug middle-end/50251] [4.7 Regression] Revision 178353 caused many test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50251 --- Comment #2 from vries at gcc dot gnu.org 2011-09-01 12:43:40 UTC --- Created attachment 25161 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25161 testcase for -O2 To reproduce with O2: i686-pc-linux-gnu-gcc 20010209-1.c -O2 -c
[Bug middle-end/50251] [4.7 Regression] Revision 178353 caused many test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50251
--- Comment #3 from vries at gcc dot gnu.org 2011-09-01 13:06:45 UTC ---
Created attachment 25162
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25162
optimized dump
1. The alloca in main is transformed into this declaration:
unnamed-unsigned:8 D.2129[24];
and accessed like this:
iftmp.6_13 = MEM[symbol: D.2129, index: ivtmp.30_31, step: 4,
offset: 4294967292B];
MEM[symbol: D.2129, index: ivtmp.30_31, step: 4, offset: 0B] = D.2105_15;
D.2099_18 = MEM[(int *)D.2129][5]{lb: 0 sz: 4};
MEM[symbol: D.2129, index: ivtmp.30_31, step: 4, offset: 0B] = 0;
2. __builtin_stack_restore/__builtin_stack_restore in main are not optimized
away, because the restored value is potentially used. The restored value is the
same as the current value, so the restore is redundant, but that's not checked
in optimize_stack_restore.
saved_stack.3_5 = __builtin_stack_save ();
__builtin_stack_restore (saved_stack.3_5);
[Bug c/50264] New: -Wdisabled-optimizations without -O generates strange errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50264 Bug #: 50264 Summary: -Wdisabled-optimizations without -O generates strange errors Classification: Unclassified Product: gcc Version: 4.3.4 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: paulo.ma...@csr.com Try: echo 'char id[] = x;' id_test.c Then: $ gcc-4.3.4 -Wdisabled-optimization -c id_test.c cc1: warning: -funit-at-a-time is required for inlining of functions that are only called once That warning looks like a bug to me and Ian.
[Bug middle-end/50251] [4.7 Regression] Revision 178353 caused many test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50251
--- Comment #4 from vries at gcc dot gnu.org 2011-09-01 13:25:56 UTC ---
Created attachment 25163
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25163
dump before ira
main contains references to frame:
(insn 29 28 30 6 (set (reg:SI 63 [ D.2099 ])
(mem/s:SI (plus:SI (reg/f:SI 20 frame)
(const_int -12 [0xfff4])) [2 D.2129+20 S4 A32]))
20010209-1.c:16 64 {*movsi_internal}
(nil))
[Bug bootstrap/50265] New: [4.7 Regression] Bootstrap failure BufferedImage.java:336:0: internal compiler error: Segmentation fault on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50265 Bug #: 50265 Summary: [4.7 Regression] Bootstrap failure BufferedImage.java:336:0: internal compiler error: Segmentation fault on *-apple-darwin* Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr Bootstrap fails on *-apple-darwin* with libtool: compile: /opt/gcc/build_w/./gcc/gcj -B/opt/gcc/build_w/x86_64-apple-darwin10.8.0/i386/libjava/ -B/opt/gcc/build_w/x86_64-apple-darwin10.8.0/i386/libjava/ -B/opt/gcc/build_w/./gcc/ -B/opt/gcc/gcc4.7w/x86_64-apple-darwin10.8.0/bin/ -B/opt/gcc/gcc4.7w/x86_64-apple-darwin10.8.0/lib/ -isystem /opt/gcc/gcc4.7w/x86_64-apple-darwin10.8.0/include -isystem /opt/gcc/gcc4.7w/x86_64-apple-darwin10.8.0/sys-include -m32 -ffloat-store -fomit-frame-pointer -Usun -fclasspath= -fbootclasspath=../../../../work/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -m32 -c -fsource-filename=/opt/gcc/build_w/x86_64-apple-darwin10.8.0/i386/libjava/classpath/lib/classes -MT java/awt/image.lo -MD -MP -MF java/awt/image.deps @java/awt/image.list -fno-common -o java/awt/.libs/image.o /opt/gcc/work/libjava/classpath/java/awt/image/BufferedImage.java: In class 'java.awt.image.BufferedImage': /opt/gcc/work/libjava/classpath/java/awt/image/BufferedImage.java: In method 'java.awt.image.BufferedImage.createDefaultIndexedColorModel(boolean)': In file included from /opt/gcc/work/libjava/classpath/java/awt/image/BufferedImage.java:635:0, from /opt/gcc/work/libjava/classpath/java/awt/image/BufferStrategy.java:77, from /opt/gcc/work/libjava/classpath/java/awt/image/BandedSampleModel.java:757, from /opt/gcc/work/libjava/classpath/java/awt/image/BandCombineOp.java:215, from /opt/gcc/work/libjava/classpath/java/awt/image/AreaAveragingScaleFilter.java:266, from /opt/gcc/work/libjava/classpath/java/awt/image/AffineTransformOp.java:610, from built-in:70: /opt/gcc/work/libjava/classpath/java/awt/image/BufferedImage.java:336:0: internal compiler error: Segmentation fault This failure occurred between revisions 178381 and 178393 (see http://gcc.gnu.org/ml/gcc-regression/2011-09/msg0.html ) and requires -O2. Note that if I move away the install directory: /opt/gcc/gcc4.7w or if I use /opt/gcc/build_w/./gcc/gcj -B/opt/gcc/build_w/x86_64-apple-darwin10.8.0/i386/libjava/ -B/opt/gcc/build_w/gcc/ -fomit-frame-pointer -Usun -fclasspath= -fbootclasspath=../../../../work/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -O2 -c -fsource-filename=/opt/gcc/build_w/x86_64-apple-darwin10.8.0/i386/libjava/classpath/lib/classes -MT java/awt/image.lo -MD -MP -MF java/awt/image.deps @java/awt/image.list the error becomes /opt/gcc/work/libjava/classpath/java/awt/image/BufferedImage.java: In class 'java.awt.image.BufferedImage': /opt/gcc/work/libjava/classpath/java/awt/image/BufferedImage.java: In method 'java.awt.image.BufferedImage.createDefaultIndexedColorModel(boolean)': In file included from built-in:6:0: /opt/gcc/work/libjava/classpath/java/awt/image/BufferedImage.java:336:0: internal compiler error: Segmentation fault I don't see why the install director appears when building the gcc components.
[Bug middle-end/50266] New: internal compiler error: in decode_addr_const, at varasm.c:2638
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50266 Bug #: 50266 Summary: internal compiler error: in decode_addr_const, at varasm.c:2638 Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: b...@arklinux.org Created attachment 25164 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25164 Preprocessed source Compiling u-boot with gcc 4.6.1 with the fix from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50116 applied results in clocks.c: In function 'enable_basic_clocks': clocks.c:657:13: internal compiler error: in decode_addr_const, at varasm.c:2638 (this is the same error as 50116, except the ICE moved by the 6 lines that were inserted in the patch for 50116. I don't have permissions to reopen 50116.) Attaching preprocessed source.
[Bug middle-end/50266] internal compiler error: in decode_addr_const, at varasm.c:2638
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50266
bero at arklinux dot org changed:
What|Removed |Added
Attachment #25164|0 |1
is obsolete||
--- Comment #1 from bero at arklinux dot org 2011-09-01 15:16:15 UTC ---
Created attachment 25165
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25165
Reduced test case
Reduced test case:
struct a {
unsigned int a;
unsigned int b;
};
struct a *const p = (struct a *)0x4A004100;
void bug50116(void)
{
unsigned int i = 0;
unsigned int *const x[] = {
p-a,
p-b,
0
};
(*(volatile unsigned int *)((x[i])) = (unsigned int)((unsigned
int)((*(volatile unsigned int *)(x[i]);
}
[Bug target/50116] [4.6 Regression] internal compiler error: in decode_addr_const, at varasm.c:2632
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50116 bero at arklinux dot org changed: What|Removed |Added CC||bero at arklinux dot org --- Comment #4 from bero at arklinux dot org 2011-09-01 15:16:58 UTC --- The patch doesn't fix it. I don't have sufficient access to reopen this bug, so I've filed a new bug including a reduced test case as bug 50266.
[Bug fortran/50050] Internal compiler error free_expr0 at expr.c:3709 via gfc_done_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50050 --- Comment #14 from Mikael Morin mikael at gcc dot gnu.org 2011-09-01 15:52:42 UTC --- Author: mikael Date: Thu Sep 1 15:52:39 2011 New Revision: 178424 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178424 Log: 2011-09-01 Mikael Morin mikael.mo...@sfr.fr PR fortran/50050 * resolve.c (gfc_expr_to_initialize): Don't copy rank. Free copied shape. Recalculate shape and rank. 2011-09-01 Mikael Morin mikael.mo...@sfr.fr PR fortran/50050 * gfortran.dg/alloc_comp_initializer_3.f90: New test. * gfortran.dg/pointer_comp_init.f90: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/alloc_comp_initializer_3.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/pointer_comp_init_1.f90 Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/resolve.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
[Bug fortran/50259] Internal Error at (1): gfc_resolve_expr(): Bad expression type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50259 --- Comment #2 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-09-01 16:03:29 UTC --- (In reply to comment #1) I get with 4.7.0 ([trunk revision 178394]) Internal Error at (1): gfc_is_constant_expr(): Unknown expression type (strangely, I can't reproduce the exact error message I posted earlier )
[Bug fortran/50259] Internal Error at (1): gfc_resolve_expr(): Bad expression type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50259 --- Comment #3 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-09-01 16:15:07 UTC --- (In reply to comment #2) (strangely, I can't reproduce the exact error message I posted earlier ) actually could be due to this: ==30794== Invalid read of size 8 ==30794==at 0x577F6A: resolve_fl_derived0(gfc_symbol*) (resolve.c:11575) ==30794==by 0x580EC2: resolve_fl_derived(gfc_symbol*) (resolve.c:11709) ==30794==by 0x575D9E: resolve_symbol(gfc_symbol*) (resolve.c:11981) ==30794==by 0x593366: traverse_ns(gfc_symtree*, void (*)(gfc_symbol*)) (symbol.c:3344) ==30794==by 0x598AFB: gfc_traverse_ns(gfc_namespace*, void (*)(gfc_symbol*)) (symbol.c:3360) ==30794==by 0x5800BB: resolve_types(gfc_namespace*) (resolve.c:13524) ==30794==by 0x574E93: gfc_resolve(gfc_namespace*) (resolve.c:13623) ==30794==by 0x56AB83: gfc_parse_file() (parse.c:4539) ==30794==by 0x5A4255: gfc_be_parse_file() (f95-lang.c:250) ==30794==by 0x92BED7: toplev_main(int, char**) (toplev.c:548) ==30794==by 0x6521B7C: (below main) (in /lib64/libc-2.11.2.so) ==30794== Address 0x713a350 is 0 bytes inside a block of size 48 free'd ==30794==at 0x4C25F7B: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==30794==by 0x59808B: gfc_free_charlen(gfc_charlen*, gfc_charlen*) (symbol.c:3218) ==30794==by 0x5650CD: reject_statement() (parse.c:1692) ==30794==by 0x56526C: _ZL10match_wordPKcPF5matchvEP5locus.part.3 (parse.c:70) ==30794==by 0x565A5F: decode_statement() (parse.c:283) ==30794==by 0x5670C4: next_statement() (parse.c:731) ==30794==by 0x5680E5: parse_spec(gfc_statement) (parse.c:2049) ==30794==by 0x56AC3D: gfc_parse_file() (parse.c:4242) ==30794==by 0x5A4255: gfc_be_parse_file() (f95-lang.c:250) ==30794==by 0x92BED7: toplev_main(int, char**) (toplev.c:548) ==30794==by 0x6521B7C: (below main) (in /lib64/libc-2.11.2.so) ==30794== ==30794== Invalid read of size 4 ==30794==at 0x57B21E: _ZL15resolve_charlenP11gfc_charlen.isra.45 (resolve.c:9662) ==30794==by 0x577F7C: resolve_fl_derived0(gfc_symbol*) (resolve.c:11576) ==30794==by 0x580EC2: resolve_fl_derived(gfc_symbol*) (resolve.c:11709) ==30794==by 0x575D9E: resolve_symbol(gfc_symbol*) (resolve.c:11981) ==30794==by 0x593366: traverse_ns(gfc_symtree*, void (*)(gfc_symbol*)) (symbol.c:3344) ==30794==by 0x598AFB: gfc_traverse_ns(gfc_namespace*, void (*)(gfc_symbol*)) (symbol.c:3360) ==30794==by 0x5800BB: resolve_types(gfc_namespace*) (resolve.c:13524) ==30794==by 0x574E93: gfc_resolve(gfc_namespace*) (resolve.c:13623) ==30794==by 0x56AB83: gfc_parse_file() (parse.c:4539) ==30794==by 0x5A4255: gfc_be_parse_file() (f95-lang.c:250) ==30794==by 0x92BED7: toplev_main(int, char**) (toplev.c:548) ==30794==by 0x6521B7C: (below main) (in /lib64/libc-2.11.2.so) ==30794== Address 0x713a378 is 40 bytes inside a block of size 48 free'd ==30794==at 0x4C25F7B: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==30794==by 0x59808B: gfc_free_charlen(gfc_charlen*, gfc_charlen*) (symbol.c:3218) ==30794==by 0x5650CD: reject_statement() (parse.c:1692) ==30794==by 0x56526C: _ZL10match_wordPKcPF5matchvEP5locus.part.3 (parse.c:70) ==30794==by 0x565A5F: decode_statement() (parse.c:283) ==30794==by 0x5670C4: next_statement() (parse.c:731) ==30794==by 0x5680E5: parse_spec(gfc_statement) (parse.c:2049) ==30794==by 0x56AC3D: gfc_parse_file() (parse.c:4242) ==30794==by 0x5A4255: gfc_be_parse_file() (f95-lang.c:250) ==30794==by 0x92BED7: toplev_main(int, char**) (toplev.c:548) ==30794==by 0x6521B7C: (below main) (in /lib64/libc-2.11.2.so) ==30794== ==30794== Invalid read of size 8 ==30794==at 0x57B240: _ZL15resolve_charlenP11gfc_charlen.isra.45 (resolve.c:9669) ==30794==by 0x577F7C: resolve_fl_derived0(gfc_symbol*) (resolve.c:11576) ==30794==by 0x580EC2: resolve_fl_derived(gfc_symbol*) (resolve.c:11709) ==30794==by 0x575D9E: resolve_symbol(gfc_symbol*) (resolve.c:11981) ==30794==by 0x593366: traverse_ns(gfc_symtree*, void (*)(gfc_symbol*)) (symbol.c:3344) ==30794==by 0x598AFB: gfc_traverse_ns(gfc_namespace*, void (*)(gfc_symbol*)) (symbol.c:3360) ==30794==by 0x5800BB: resolve_types(gfc_namespace*) (resolve.c:13524) ==30794==by 0x574E93: gfc_resolve(gfc_namespace*) (resolve.c:13623) ==30794==by 0x56AB83: gfc_parse_file() (parse.c:4539) ==30794==by 0x5A4255: gfc_be_parse_file() (f95-lang.c:250) ==30794==by 0x92BED7: toplev_main(int, char**) (toplev.c:548) ==30794==by 0x6521B7C: (below main) (in /lib64/libc-2.11.2.so) ==30794== Address 0x713a350 is 0 bytes inside a block of size 48 free'd ==30794==at 0x4C25F7B: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==30794==by 0x59808B: gfc_free_charlen(gfc_charlen*, gfc_charlen*) (symbol.c:3218) ==30794==by 0x5650CD: reject_statement() (parse.c:1692)
[Bug fortran/50259] Internal Error at (1): gfc_resolve_expr(): Bad expression type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50259 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2011-09-01 16:20:06 UTC --- With valgrind, I get now: test.f90:4.19: CHARACTER (len=default_path_length), DIMENSION(:,:), POINTER :: 1 Error: Expected another dimension in array declaration at (1) test.f90:5: initial_variables 1 Error: Unclassifiable statement at (1) ==31867== Invalid read of size 8 ==31867==at 0x574B9A: resolve_fl_derived0(gfc_symbol*) (resolve.c:11587) ==31867==by 0x57DAF2: resolve_fl_derived(gfc_symbol*) (resolve.c:11721) ==31867==by 0x5729CE: resolve_symbol(gfc_symbol*) (resolve.c:11993) ... ==31867== Address 0x70958f0 is 0 bytes inside a block of size 48 free'd ==31867==at 0x4C2892E: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==31867==by 0x594CAB: gfc_free_charlen(gfc_charlen*, gfc_charlen*) (symbol.c:3218) ==31867==by 0x561CFD: reject_statement() (parse.c:1692) ... ==31867== Invalid read of size 4 ==31867==at 0x577E4E: _ZL15resolve_charlenP11gfc_charlen.isra.45 (resolve.c:9674) ==31867==by 0x574BAC: resolve_fl_derived0(gfc_symbol*) (resolve.c:11588) ==31867==by 0x57DAF2: resolve_fl_derived(gfc_symbol*) (resolve.c:11721) ==31867==by 0x5729CE: resolve_symbol(gfc_symbol*) (resolve.c:11993) ... ==31867== Invalid write of size 4 ==31867==at 0x577E73: _ZL15resolve_charlenP11gfc_charlen.isra.45 (resolve.c:9677) ==31867==by 0x574BAC: resolve_fl_derived0(gfc_symbol*) (resolve.c:11588) ==31867==by 0x57DAF2: resolve_fl_derived(gfc_symbol*) (resolve.c:11721) ==31867==by 0x5729CE: resolve_symbol(gfc_symbol*) (resolve.c:11993) ... ==31867== Invalid read of size 4 ==31867==at 0x5757C1: gfc_resolve_expr(gfc_expr*) (resolve.c:6099) ==31867==by 0x577DFA: resolve_index_expr(gfc_expr*) (resolve.c:9654) ==31867==by 0x577E87: _ZL15resolve_charlenP11gfc_charlen.isra.45 (resolve.c:9681) ==31867==by 0x574BAC: resolve_fl_derived0(gfc_symbol*) (resolve.c:11588) ... test.f90:7.26: END MODULE cp_parser_types 1 Internal Error at (1): gfc_resolve_expr(): Bad expression type
[Bug middle-end/50251] [4.7 Regression] Revision 178353 caused many test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50251
--- Comment #5 from vries at gcc dot gnu.org 2011-09-01 16:29:16 UTC ---
Created attachment 25166
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25166
ira dump
and after ira, the reference to framereg is still there:
...
(insn 29 28 30 6 (set (reg:SI 0 ax [orig:63 D.2099 ] [63])
(mem/s:SI (plus:SI (reg/f:SI 20 frame)
(const_int -12 [0xfff4])) [2 D.2129+20 S4 A32]))
20010209-1.c:16 64 {*movsi_internal}
(nil))
...
Normally, framereg gets eliminated in ira using either of the following 2
rules:
...
{ FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM},\
{ FRAME_POINTER_REGNUM, HARD_FRAME_POINTER_REGNUM}}\
...
For main, ix86_can_eliminate limits this to only the first rule:
...
static bool
ix86_can_eliminate (const int from, const int to)
{
if (stack_realign_fp)
return ((from == ARG_POINTER_REGNUM
to == HARD_FRAME_POINTER_REGNUM)
|| (from == FRAME_POINTER_REGNUM
to == STACK_POINTER_REGNUM));
else
return to == STACK_POINTER_REGNUM ? !frame_pointer_needed : true;
}
...
stack_realign_fp is true for main, so for 'from == FRAME_POINTER_REGNUM', only
'to == STACK_POINTER_REGNUM' is allowed.
reload then itself switches off the first rule here:
...
/* If we have some registers we think can be eliminated, scan all insns to
see if there is an insn that sets one of these registers to something
other than itself plus a constant. If so, the register cannot be
eliminated. Doing this scan here eliminates an extra pass through the
main reload loop in the most common case where register elimination
cannot be done. */
for (insn = first; insn num_eliminable; insn = NEXT_INSN (insn))
if (INSN_P (insn))
note_stores (PATTERN (insn), mark_not_eliminable, NULL);
...
due to the stack restore:
...
(insn 32 31 33 6 (set (reg/f:SI 7 sp)
(reg/f:SI 59 [ saved_stack.3D.2111 ])) 64 {*movsi_internal}
(expr_list:REG_DEAD (reg/f:SI 59 [ saved_stack.3D.2111 ])
(expr_list:REG_ARGS_SIZE (const_int 0 [0])
(nil
...
reload then notes that there is no way to eliminate framereg and sets framereg
in bad_spill_regs_global
...
if (! can_eliminate)
spill_hard_reg (from, 1);
...
The reloads for insn 29 are this, and framereg is still used:
...
Reloads for insn # 29
Reload 0: reload_in (SI) = (mem/s:SI (plus:SI (reg/f:SI 20 frame)
(const_int -12))
[2 D.2129+20 S4 A32])
GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 1), optional
reload_in_reg: (mem/s:SI (plus:SI (reg/f:SI 20 frame)
(const_int -12))
[2 D.2129+20 S4 A32])
...
The documentation for HARD_FRAME_POINTER_REGNUM says the following:
...
When this macro is defined, you must also indicate in your definition of
ELIMINABLE_REGS how to eliminate FRAME_POINTER_REGNUM into either
HARD_FRAME_POINTER_REGNUM or STACK_POINTER_REGNUM.
...
I don't know whether ix86_can_eliminate in the current state violates this
rule, but modifying ix86_can_eliminate to allow the
'FRAME_POINTER_REGNUM - HARD_FRAME_POINTER_REGNUM' elimination allows the
compilation to succeed and the executable to run successfully.
[Bug libfortran/50192] Wrong character comparision with wide strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50192 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-09-01 16:41:45 UTC --- Fixed on trunk, 4.6 and 4.5. Backporting to 4.4 failed because the test case ICE'd due to PR 50267. Closing as fixed; if anybody feels differently, maybe it would be wise to tackle PR 50267 first.
[Bug libstdc++/50257] [C++0x] unordered_map slow initialization due to huge __prime_list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50257 --- Comment #5 from Justin SB justin at fathomdb dot com 2011-09-01 17:06:04 UTC --- Created attachment 25167 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25167 Test case Test case that stresses unordered_map construction
[Bug libstdc++/50257] [C++0x] unordered_map slow initialization due to huge __prime_list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50257 --- Comment #6 from Justin SB justin at fathomdb dot com 2011-09-01 17:33:32 UTC --- Thanks so much for the help. I created a test case (attached) and tried out the patch (the second version); it is a big improvement. Here are the timings: g++ -g -O3 --std=c++0x test.cc Without patch: user0m13.201s With patch: user0m10.237s --- The special casing is obviously a bit of a hack, so I wondered if we could do better by doing a linear scan if the value is less than a threshold (which would have a much nicer memory pattern). It was a small improvement, but nowhere near what the special-casing of the value 10 does: With linear scan for small n: user0m12.561s I therefore believe the real win is because the special case allows the compiler to optimize away the entire lookup in __prime_list, because the function is inlined and the value of n is known. --- There is a comment in hashtable_policy: // XXX This is a hack. There's no good reason for any of // _Prime_rehash_policy's member functions to be inline. However, I think that (with the patch) this isn't true any more. There's a big performance win by avoiding touching __prime_list, so at least the special case should remain inline. --- Based on your malloc comment, I'm using tcmalloc which is a bit faster than the default allocator, which is probably why it showed up; the patch still knocks the same ~3 seconds off the time: g++ -g -O3 --std=c++0x test.cc -ltcmalloc Without patch, with -ltcmalloc user0m10.173s With patch, with -ltcmalloc user0m7.288s --- In terms of the (non cumulative) cpu cycles spent in the lookup vs new/delete: With -ltcmalloc: Without patch: 44% iter() / 48% memory. With patch: 34% iter() / 63% memory With stock malloc: Without patch: 38% iter() / 58% memory With patch: 18% iter() / 79% memory So memory is indeed a big cost, but as I was using tcmalloc I was able to see that the constructor was surprisingly expensive (spending about as much time in the constructor as I was in allocation or deallocation) --- TLDR: The patch works for me, and I think it's a significant win, because it allows the compiler to optimize __prime_list away entirely.
[Bug libstdc++/50257] [C++0x] unordered_map slow initialization due to huge __prime_list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50257 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-09-01 AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-01 17:54:14 UTC --- Ah, very good. Thanks a lot for all your help. Indeed, I'm seeing similar numbers on my machine. Thus, I would say, let's go with this kind of tweak for now: indeed, it looks like an hack, but having default construction, move constructor, faster is important, and as you noticed, it's also about having the common case inline, vs the out of line lower_bound call. Also, I should add, it's an hack, but I mild one, in my opinion, because we are doing it at an abstraction level, _Prime_rehash_policy, which is exactly the same at which the __prime_list is managed, thus we know for sure it begins by 2, etc. Only 10 it's a bit out of the blue at this level. Anyway, with another contributor, we are also in the process of improving, streamlining, these _Prime_rehash_policy functions for other reasons, I'll see later on if we can (re-)implement this kind of tweak in a better way.
[Bug middle-end/50251] [4.7 Regression] Revision 178353 caused many test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50251 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||areg.melikadamyan at gmail ||dot com --- Comment #6 from H.J. Lu hjl.tools at gmail dot com 2011-09-01 18:03:29 UTC --- fold_builtin_alloca_for_var should record stack alignment change due to + /* Declare array. */ + elem_type = build_nonstandard_integer_type (BITS_PER_UNIT, 1); + n_elem = size * 8 / BITS_PER_UNIT; + align = MIN (size * 8, BIGGEST_ALIGNMENT); + array_type = build_array_type_nelts (elem_type, n_elem); + var = create_tmp_var (array_type, NULL); + DECL_ALIGN (var) = align; +
[Bug go/46986] Go is not supported on Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986 --- Comment #6 from Anders F Björklund afb at users dot sourceforge.net 2011-09-01 18:09:02 UTC --- Created attachment 25168 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25168 updated patch for 4.6.1 hello world tests OK on Snow Leopard, with patch
[Bug go/46986] Go is not supported on Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986 Anders F Björklund afb at users dot sourceforge.net changed: What|Removed |Added CC||afb at users dot ||sourceforge.net --- Comment #7 from Anders F Björklund afb at users dot sourceforge.net 2011-09-01 18:11:32 UTC --- Another problem is that the -static-libgo flag doesn't work, because the static library has the same name and location as the dynamic lib and therefore darwin will always prefer the dynamic library. It probably needs to be renamed (to something like libgo_static.a), since otherwise the -Wl,-search_paths_first flag is needed to avoid picking up libgo.dylib even if it comes later in the paths...
[Bug fortran/50050] Internal compiler error free_expr0 at expr.c:3709 via gfc_done_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50050 --- Comment #15 from Mikael Morin mikael at gcc dot gnu.org 2011-09-01 19:20:05 UTC --- Author: mikael Date: Thu Sep 1 19:19:55 2011 New Revision: 178427 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178427 Log: 2011-09-01 Mikael Morin mikael.mo...@sfr.fr PR fortran/50050 * resolve.c (gfc_expr_to_initialize): Don't copy rank. Free copied shape. Recalculate shape and rank. 2011-09-01 Mikael Morin mikael.mo...@sfr.fr PR fortran/50050 * gfortran.dg/alloc_comp_initializer_3.f90: New test. * gfortran.dg/pointer_comp_init.f90: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/alloc_comp_initializer_3.f90 branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/pointer_comp_init_1.f90 Modified: branches/gcc-4_4-branch/gcc/fortran/ChangeLog branches/gcc-4_4-branch/gcc/fortran/resolve.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
[Bug libstdc++/50268] New: [C++0x] bitset doesn't sanitize input
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268
Bug #: 50268
Summary: [C++0x] bitset doesn't sanitize input
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: marc.gli...@normalesup.org
#include bitset
#include iostream
int main(){
std::bitset1 b(3);
std::cout b.count() std::endl;
}
Prints 1 with -std=c++98 and 2 with -std=c++0x.
(I noticed it while wondering why _M_are_all_aux uses popcount, which isn't
optimal)
[Bug libstdc++/50268] [C++0x] bitset doesn't sanitize input
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-01 19:23:37 UTC --- Any idea where the problem is?
[Bug middle-end/50251] [4.7 Regression] Revision 178353 caused many test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50251
--- Comment #7 from vries at gcc dot gnu.org 2011-09-01 19:26:48 UTC ---
fold_builtin_alloca_for_var should record stack alignment change
After expand_var for D.2129 with 128-bit alignment, x_rtl looks like this:
...
(gdb) p x_rtl
$20 = {expr = {x_pending_stack_adjust = 0, x_inhibit_defer_pop = 0,
x_stack_pointer_delta = 0, x_saveregs_value = 0x0, x_apply_args_value = 0x0,
x_forced_labels = 0x0}, emit = {x_reg_rtx_no = 70,
x_first_label_num = 11, x_first_insn = 0x0, x_last_insn = 0x0,
sequence_stack = 0xf7d5557c, x_cur_insn_uid = 2, x_cur_debug_insn_uid = 1,
x_last_location = 0, regno_pointer_align_length = 159,
regno_pointer_align = 0x981a428 }, varasm = {pool = 0xf7df9294,
deferred_constants = 0}, args = {pops_args = 0, size = 0, pretend_args_size =
0, arg_offset_rtx = 0x0, info = {words = 0, nregs = 0,
regno = 0, fastcall = 0, sse_words = 0, sse_nregs = 0, warn_avx = 0,
warn_sse = 0, warn_mmx = 0, sse_regno = 0, mmx_words = 0, mmx_nregs = 0,
mmx_regno = 0, maybe_vaarg = 0, caller = 0,
float_in_sse = 0, call_abi = SYSV_ABI}, internal_arg_pointer = 0x0},
subsections = {hot_section_label = 0x0, cold_section_label = 0x0,
hot_section_end_label = 0x0, cold_section_end_label = 0x0},
eh = {ehr_stackadj = 0x0, ehr_handler = 0x0, ehr_label = 0x0, sjlj_fc = 0x0,
sjlj_exit_after = 0x0, action_record_data = 0x0, call_site_record = {0x0,
0x0}}, outgoing_args_size = 0, return_rtx = 0x0,
hard_reg_initial_vals = 0x0, stack_protect_guard = 0x0,
x_nonlocal_goto_handler_labels = 0x0, x_return_label = 0x0,
x_naked_return_label = 0x0, x_stack_slot_list = 0x0, frame_space_list = 0x0,
x_stack_check_probe_note = 0x0, x_arg_pointer_save_area = 0x0, drap_reg =
0x0, x_frame_offset = 0, x_parm_birth_insn = 0x0, x_used_temp_slots = 0x0,
x_avail_temp_slots = 0x0, x_temp_slot_level = 0,
stack_alignment_needed = 128, preferred_stack_boundary = 32,
parm_stack_boundary = 0, max_used_stack_slot_alignment = 128,
stack_alignment_estimated = 128, epilogue_delay_list = 0x0,
accesses_prior_frames = false, calls_eh_return = false, saves_all_registers =
false, has_nonlocal_goto = false, has_asm_statement = false,
all_throwers_are_sibcalls = false, limit_stack = false,
profile = false, uses_const_pool = false, uses_pic_offset_table = false,
uses_eh_lsda = false, tail_call_emit = false, arg_pointer_save_area_init =
false, frame_pointer_needed = false,
maybe_hot_insn_p = true, stack_realign_needed = false, stack_realign_tried =
false, need_drap = false, stack_realign_processed = false,
stack_realign_finalized = false, dbr_scheduled_p = false,
nothrow = false, asm_clobbers = {0, 0}}
...
These are the relevant values set by expand_one_var:
...
stack_alignment_estimated = 128
stack_alignment_needed = 128
max_used_stack_slot_alignment = 128
...
Is there anything needed that expand_var doesn't do?
[Bug libstdc++/50268] [C++0x] bitset doesn't sanitize input
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268
--- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-01
19:29:23 UTC ---
Urgh, I can't believe it's here:
#ifdef __GXX_EXPERIMENTAL_CXX0X__
constexpr bitset(unsigned long long __val) noexcept
: _Base(__val) { }
#else
[Bug middle-end/50260] [4.7 Regression] internal compiler error: Segmentation fault at ../../gcc/gcc/tree-ssa-live.c:88
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50260 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org 2011-09-01 19:30:20 UTC --- Also reproduces on Mozilla build with C++ code.
[Bug middle-end/50251] [4.7 Regression] Revision 178353 caused many test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50251 --- Comment #8 from H.J. Lu hjl.tools at gmail dot com 2011-09-01 19:32:54 UTC --- alloca is special with stack alignment. We may need to take the new change into account.
[Bug fortran/50269] New: Wrongly rejects element of assumed-shape array in C_LOC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50269 Bug #: 50269 Summary: Wrongly rejects element of assumed-shape array in C_LOC Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Reported by Ian Bush in comp.lang.fortran, http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/71338937cf348f26 b = c_loc( aa( 1 ) ) 1 Error: Assumed-shape array 'aa' at (1) cannot be an argument to the procedure 'c_loc' because it is not C interoperable Program gf Use iso_c_binding Real( c_double ), Dimension( 1:10 ), Target :: a Call test( a ) Contains Subroutine test( aa ) Real( c_double ), Dimension( : ), Target :: aa Type( c_ptr ), Pointer :: b b = c_loc( aa( 1 ) ) End Subroutine test End Program gf
[Bug libstdc++/50268] [C++0x] bitset doesn't sanitize input
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-09-01 AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Ever Confirmed|0 |1
[Bug fortran/50267] [4.4] ICE in lhd_set_decl_assembler_name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50267 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-09-01 19:42:14 UTC --- Not a regression as 4.4 first introduced kind=4 character strings. Additional, a work around exists: Compiling without -O. Thus, I vote for WONTFIX (alias FIXED in 4.5+).
[Bug fortran/50050] Internal compiler error free_expr0 at expr.c:3709 via gfc_done_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50050 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #16 from Mikael Morin mikael at gcc dot gnu.org 2011-09-01 19:45:11 UTC --- Fixed for 4.4.7, 4.5.4, 4.6.2 and 4.7.0. Thanks for the report.
[Bug c++/50270] New: Some symbols are exported even when -fvisibility=hidden is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50270
Bug #: 50270
Summary: Some symbols are exported even when
-fvisibility=hidden is used
Classification: Unclassified
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: almeida...@gmail.com
Created attachment 25169
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25169
Output of gcc -E -fvisibility=hidden -fvisibility-inlines-hidden -fPIC -Wall
-Wextra -shared foo.c
When I compile foo.cc with the following command:
$gcc -fvisibility=hidden -fvisibility-inlines-hidden -fPIC -Wall -Wextra
-shared foo.cc -olibfoo.so
There are still quite a few exported symbols. For instance:
_ZNSt6vectorI3FooSaIS0_EE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPS0_S2_EERKS0_
which should not be exported. This is what objdump -T displays:
23b2 w DF .text 02d2 Base
_ZNSt6vectorI3FooSaIS0_EE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPS0_S2_EERKS0_
In readelf -s it comes out in .dynsym as:
62: 23b2 722 FUNCWEAK DEFAULT 12
_ZNSt6vectorI3FooSaIS0_EE
To my understanding my shared library shouldn't be exporting any symbols.
$gcc -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)
$lsb_release -a
No LSB modules are available.
Distributor ID:Ubuntu
Description:Ubuntu 10.04.3 LTS
Release:10.04
Codename:lucid
I could not add more than one attachment, so I added gcc -E output as an
attachment and foo.cc code goes here:
#include vector
class __attribute__ ((visibility (hidden))) Foo {
public:
int m() {
return 0;
}
};
int main(void) {
std::vectorFoo v;
v.push_back(Foo());
return 0;
}
[Bug c++/50270] Some symbols are exported even when -fvisibility=hidden is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50270 --- Comment #1 from Rafael Almeida almeidaraf at gmail dot com 2011-09-01 19:57:04 UTC --- Created attachment 25170 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25170 Preprocessed file generated by -save-temps
[Bug c++/50270] Some symbols are exported even when -fvisibility=hidden is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50270 --- Comment #2 from Rafael Almeida almeidaraf at gmail dot com 2011-09-01 19:57:50 UTC --- Created attachment 25171 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25171 foo.s generated by -save-temps
[Bug c++/50270] Some symbols are exported even when -fvisibility=hidden is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50270 --- Comment #3 from Rafael Almeida almeidaraf at gmail dot com 2011-09-01 19:58:45 UTC --- Created attachment 25172 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25172 Output of -save-temps -v
[Bug c++/50270] Some symbols are exported even when -fvisibility=hidden is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50270
--- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org 2011-09-01
19:59:18 UTC ---
Small testcase:
template class a class __attribute__ ((visibility (default))) vector {
public:
vector(){t=2;};
void push_back(a){t++;};
int t;
};
class __attribute__ ((visibility (hidden))) Foo {
public:
int m() {
return 0;
}
};
int main(void) {
vectorFoo v;
v.push_back(Foo());
return 0;
}
Everything should be hidden except for main().
[Bug fortran/50269] Wrongly rejects element of assumed-shape array in C_LOC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50269
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #1 from kargl at gcc dot gnu.org 2011-09-01 20:24:42 UTC ---
This allows the code to compile, but one then gets a segfault
or the right answer depending on memory layout. I think
trans-expr.c(conv_isocbinding_procedure) needs to be updated
as well, but don't know what needs to be done (yet).
Index: resolve.c
===
--- resolve.c (revision 178329)
+++ resolve.c (working copy)
@@ -2809,7 +2809,8 @@ gfc_iso_c_func_interface (gfc_symbol *sy
interoperable. */
if (args_sym args_sym-attr.dimension)
{
- if (args_sym-as-type == AS_ASSUMED_SHAPE)
+ if (args_sym-as-type == AS_ASSUMED_SHAPE
+ args-expr-ref-u.ar.type != AR_ELEMENT)
{
gfc_error (Assumed-shape array '%s' at %L
cannot be an argument to the
troutmask:sgk[215] gfc4x -o z foo.f90 ./z
Calling test()
c_loc(aa) = 140737488344288
troutmask:sgk[216] gfc4x -o z foo.f90 ./z
Segmentation fault (core dumped)
program gf
use iso_c_binding
real(c_double), dimension(1:10), target :: a
! a = 42
! print *, 'Calling test()'
call test(a)
contains
subroutine test(aa)
real(c_double), dimension(:), target :: aa
type(c_ptr), pointer :: b
b = c_loc(aa(1))
print '(A,I0)', 'c_loc(aa) = ', b
end subroutine test
end program gf
[Bug middle-end/50260] [4.7 Regression] internal compiler error: Segmentation fault at ../../gcc/gcc/tree-ssa-live.c:88
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50260 --- Comment #3 from Pat Haugen pthaugen at gcc dot gnu.org 2011-09-01 20:34:00 UTC --- This also shows up on PowerPC in the 3 cpu2000 benchmarks 178.galgel, 191.fma3d and 200.sixtrack.
[Bug fortran/50269] Wrongly rejects element of assumed-shape array in C_LOC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50269
--- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-09-01
21:10:05 UTC ---
(In reply to comment #1)
This allows the code to compile, but one then gets a segfault
or the right answer depending on memory layout. I think
trans-expr.c(conv_isocbinding_procedure) needs to be updated
as well, but don't know what needs to be done (yet).
It might be that it accesses the descriptor instead of desc.data.
- if (args_sym-as-type == AS_ASSUMED_SHAPE)
+ if (args_sym-as-type == AS_ASSUMED_SHAPE
+ args-expr-ref-u.ar.type != AR_ELEMENT)
{
gfc_error (Assumed-shape array '%s' at %L
cannot be an argument to the
I think one should use the opportunity to update it to Fortran 2008, which
allows also assumed/deferred-shape arrays - if they are contiguous:
F2008, 15.2.3.6 C LOC (X):
Argument. X shall have either the POINTER or TARGET attribute. It shall not be
a coindexed object. It shall either be a variable with interoperable type and
kind type parameters, or be a scalar, nonpolymorphic variable with no length
type parameters. If it is allocatable, it shall be allocated. If it is a
pointer, it shall be associated. If it is an array, it shall be contiguous and
have nonzero size. It shall not be a zero-length string.
Note: It talks about contiguous and not simply contiguous, which means that
it is not compile-time checkable (unless strides are used or a vector index). I
think there is also a coindexed check missing.
Fortran 2003 had in 15.1.2.5 C LOC (X):
Argument. X shall either
(1) have interoperable type and type parameters and be
(a) a variable that has the TARGET attribute and is interoperable,
(b) an allocated allocatable variable that has the TARGET attribute
and is not an array of zero size, or
(c) an associated scalar pointer, or
(2) be a nonpolymorphic scalar, have no length type parameters, and be
(a) a nonallocatable, nonpointer variable that has the TARGET attribute,
(b) an allocated allocatable variable that has the TARGET attribute, or
(c) an associated pointer.
[Bug target/50256] AVR GCC - several unnecessary register moves
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50256 --- Comment #2 from NickParker at Eaton dot com 2011-09-01 21:30:41 UTC --- I have the latest AVR GCC release from 2010-01-10 (4.3.3) and this is what I am using.
[Bug tree-optimization/50183] ICE in verify_ssa for 416.gamess when optimizing using profile data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50183 --- Comment #6 from William J. Schmidt wschmidt at gcc dot gnu.org 2011-09-01 21:41:19 UTC --- This PHI: bb 43: # err2.395_561 = PHI err2.395_219(41) is removed by the second call to remove_phi in translate_scalar_reduction_to_array (graphite-sese-to-poly.c). There appears to be an implicit assumption in remove_phi that the PHI result is only used in debug statements. This is not the case here because of the immediate use: bb 45: # err2.395_571 = PHI err2.395_561(43) I don't know anything about the graphite code, so it's not clear to me whether the existence of this immediate use should have kept this from being a candidate for transformation, or whether remove_phi needs additional logic. My guess is the former. At this point I think we need a domain expert to look into this one...
[Bug libstdc++/50268] [C++0x] bitset doesn't sanitize input
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-01 22:17:00 UTC --- Created attachment 25173 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25173 Draft patch Hi Marc. This is a patch I'm working on. Can you see anything obviously wrong with it? And / or simple improvements? (we want the fix for 4.6 too, I think) The issue of course is that for a constexpr constructor we can't do anything in the body (at the time somebody decided to disregard the issue completely ;) but luckily we can on the unsigned long long itself with a constexpr helper. Overall I think we are not doing more work here compared to C++03.
[Bug go/46986] Go is not supported on Darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added CC||howarth at nitro dot ||med.uc.edu --- Comment #8 from Jack Howarth howarth at nitro dot med.uc.edu 2011-09-01 22:48:23 UTC --- (In reply to comment #6) Created attachment 25168 [details] updated patch for 4.6.1 hello world tests OK on Snow Leopard, with patch This patch fails on darwin11 when applied to gcc-4_6-branch... f=`echo sort/sort.lo | sed -e 's/.lo$/.o/'`; missing-objcopy -j __GNU_GO.__go_export $f sort.gox.tmp mv -f sort.gox.tmp sort.gox /bin/sh: missing-objcopy: command not found make[4]: *** [sort.gox] Error 127 make[4]: *** Waiting for unfinished jobs It seems to required binutils to be installed (which we really want to avoid).
[Bug libstdc++/50268] [C++0x] bitset doesn't sanitize input
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Attachment #25173|0 |1 is obsolete|| --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-01 22:54:43 UTC --- Comment on attachment 25173 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25173 Draft patch S*it, patch is badly wrong: in general we really want to zero the unused bits of the highest word not of the __val. But the highest word either is all zeros anyway or has excess non zero bits beyond _Nb because written by __val, thus we have to restrict the zeroing of the highest bits of __val to this case.
[Bug c++/50271] New: [C++0x] G++ fails to handle combination of explicit and deduced variadic template arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50271
Bug #: 50271
Summary: [C++0x] G++ fails to handle combination of explicit
and deduced variadic template arguments
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
This should be accepted:
templateclass T, class U struct A { };
templateclass... T, class ... U void f( AT,U...p);
void g() {
fint(
Aint,unsigned(),
Ashort,unsigned short()
);
}
but we end up deducing T to be {int,int,short} rather than {int,short} as it
should be.
[Bug libstdc++/50268] [C++0x] bitset doesn't sanitize input
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50268 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-09-02 01:35:06 UTC --- Created attachment 25174 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25174 Updated draft This one is much better, and actually should lead to slightly better code than C++98, because we don't do anything if _Nw 1 (the 32-bit case is also better but doesn't optimize the case _Nb % _GLIBCXX_BITSET_BITS_PER_WORD == 0 _Nb % _GLIBCXX_BITSET_BITS_PER_ULL != 0. I don't care much these times)
[Bug c/50272] New: A case that PRE optimization hurts performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50272
Bug #: 50272
Summary: A case that PRE optimization hurts performance
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jiangning@arm.com
For the following simple test case, PRE optimization hoists computation
(s!=1) into the default branch of the switch statement, and finally causes
very poor code generation. This problem occurs in both X86 and ARM, and I
believe it is also a problem for other targets.
int f(char *t) {
int s=0;
while (*t s != 1) {
switch (s) {
case 0:
s = 2;
break;
case 2:
s = 1;
break;
default:
if (*t == '-')
s = 1;
break;
}
t++;
}
return s;
}
Taking X86 as an example, with option -O2 you may find 52 instructions
generated like below,
f:
0:55 push %ebp
1:31 c0xor%eax,%eax
3:89 e5mov%esp,%ebp
5:57 push %edi
6:56 push %esi
7:53 push %ebx
8:8b 55 08 mov0x8(%ebp),%edx
b:0f b6 0a movzbl (%edx),%ecx
e:84 c9test %cl,%cl
10:74 50je 62 f+0x62
12:83 c2 01 add$0x1,%edx
15:85 c0test %eax,%eax
17:75 23jne3c f+0x3c
19:8d b4 26 00 00 00 00 lea0x0(%esi,%eiz,1),%esi
20:0f b6 0a movzbl (%edx),%ecx
23:84 c9test %cl,%cl
25:0f 95 c0 setne %al
28:89 c7mov%eax,%edi
2a:b8 02 00 00 00 mov$0x2,%eax
2f:89 fbmov%edi,%ebx
31:83 c2 01 add$0x1,%edx
34:84 dbtest %bl,%bl
36:74 2aje 62 f+0x62
38:85 c0test %eax,%eax
3a:74 e4je 20 f+0x20
3c:83 f8 02 cmp$0x2,%eax
3f:74 1fje 60 f+0x60
41:80 f9 2d cmp$0x2d,%cl
44:74 22je 68 f+0x68
46:0f b6 0a movzbl (%edx),%ecx
49:83 f8 01 cmp$0x1,%eax
4c:0f 95 c3 setne %bl
4f:89 dfmov%ebx,%edi
51:84 c9test %cl,%cl
53:0f 95 c3 setne %bl
56:89 demov%ebx,%esi
58:21 f7and%esi,%edi
5a:eb d3jmp2f f+0x2f
5c:8d 74 26 00 lea0x0(%esi,%eiz,1),%esi
60:b0 01mov$0x1,%al
62:5b pop%ebx
63:5e pop%esi
64:5f pop%edi
65:5d pop%ebp
66:c3 ret
67:90 nop
68:b8 01 00 00 00 mov$0x1,%eax
6d:5b pop%ebx
6e:5e pop%esi
6f:5f pop%edi
70:5d pop%ebp
71:c3 ret
But with command line option -O2 -fno-tree-pre, there are only 12
instructions generated, and the code would be very clean like below,
f:
0:55 push %ebp
1:31 c0xor%eax,%eax
3:89 e5mov%esp,%ebp
5:8b 55 08 mov0x8(%ebp),%edx
8:80 3a 00 cmpb $0x0,(%edx)
b:74 0eje 1b f+0x1b
d:80 7a 01 00 cmpb $0x0,0x1(%edx)
11:b0 02mov$0x2,%al
13:ba 01 00 00 00 mov$0x1,%edx
18:0f 45 c2 cmovne %edx,%eax
1b:5d pop%ebp
1c:c3 ret
[Bug c/50272] A case that PRE optimization hurts performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50272 --- Comment #1 from Jiangning Liu jiangning.liu at arm dot com 2011-09-02 05:11:38 UTC --- Richard gave some analysis at http://gcc.gnu.org/ml/gcc/2011-08/msg00037.html
