[Bug bootstrap/52466] gcc-4.7.0-RC-20120302 fails to build for --target=lm32-rtems4.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52466 --- Comment #3 from Joel Sherrill 2012-11-04 06:33:10 UTC --- Following up on my earlier message. Jon Beniston (original author) or Sebastien Bourdeauducq (current maintainer) ... please reply. This particular issue should be simple to the port maintainer. Also someone familiar with the exception model specification magic should be able to get this one addressed. Please.
[Bug target/55194] h8300 ICE during conftest in libgcc dwarf2out:7605
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55194 --- Comment #3 from Joel Sherrill 2012-11-04 06:22:22 UTC --- I added Jakub because I think this was the patch which broke it: Author: jakub Date: Mon Aug 20 18:56:49 2012 + PR rtl-optimization/54294 * fwprop.c (all_uses_available_at): Ignore debug insns in between def_insn and target_insn when checking whether the shortcut is possible.
[Bug target/55194] h8300 ICE during conftest in libgcc dwarf2out:7605
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55194 --- Comment #2 from Joel Sherrill 2012-11-04 06:20:02 UTC --- git bisect should help: [0e797c2e325bfe0676fc9b9e5baee01aefb164f5] /cp 2012-08-20 Paolo Carlini [joel@baltimore gcc]$ git bisect good Bisecting: 1 revision left to test after this (roughly 1 step) [29b2949ccfc068c78899358ca40218f3518b00dd] PR rtl-optimization/54294 * fwprop.c (all_uses_available_at): Ignore debug insns in between def_insn and target_insn when checking whether the shortcut is possible. [joel@baltimore gcc]$ git bisect good Bisecting: 0 revisions left to test after this (roughly 0 steps) [2bf99680c2012de150798c933642aa4c82a85410] 2012-08-20 Tobias Burnus
[Bug tree-optimization/55200] RubyLang complex.c Internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55200 --- Comment #4 from Chris Lundquist 2012-11-04 05:32:44 UTC --- Updated. For quick reference, the line described in context can be found here. https://github.com/ruby/ruby/blob/v1_9_3_286/complex.c#L1988
[Bug tree-optimization/55200] RubyLang complex.c Internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55200 --- Comment #3 from Chris Lundquist 2012-11-04 05:30:05 UTC --- Created attachment 28607 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28607 Rubylang complex.i under GCC 4.8
[Bug tree-optimization/55200] RubyLang complex.c Internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55200 Andrew Pinski changed: What|Removed |Added Component|c |tree-optimization --- Comment #2 from Andrew Pinski 2012-11-04 05:19:56 UTC --- Can you attach the preprocessed source?
[Bug c/55200] RubyLang complex.c Internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55200 --- Comment #1 from Chris Lundquist 2012-11-04 05:00:51 UTC --- Please let me know what further information I can provide. Unfortunately I was unable to make a simple test case. I can't figure out why it is dying on a matched } to close a function.
[Bug c/55200] New: RubyLang complex.c Internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55200 Bug #: 55200 Summary: RubyLang complex.c Internal compiler error Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: clundqu...@bluebox.net When compiling rubylang under gcc4.8 I hit an internal compiler error from cc1. FWIW The project compiles under (MacPorts gcc47 4.7.2_2) To reproduce: $ git clone git://github.com/ruby/ruby.git $ cd ruby $ git checkout v1_9_3_286 $ autoconf $ ./configure $ make --- $ uname -a Darwin localhost 12.2.0 Darwin Kernel Version 12.2.0: Sat Aug 25 00:48:52 PDT 2012; root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64 $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin12/4.8.0/lto-wrapper Target: x86_64-apple-darwin12 Configured with: ../gcc-4.8-20121028/configure --prefix=/opt/local --build=x86_64-apple-darwin12 --enable-languages=c,c++,objc,obj-c++,fortran,java --libdir=/opt/local/lib/gcc48 --includedir=/opt/local/include/gcc48 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-4.8 --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-4.8 --with-gxx-include-dir=/opt/local/include/gcc48/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --with-ppl=/opt/local --with-cloog=/opt/local --enable-cloog-backend=isl --disable-cloog-version-check --enable-stage1-checking --disable-multilib --enable-lto --enable-libstdcxx-time --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket --with-pkgversion='MacPorts gcc48 4.8-20121028_0' Thread model: posix gcc version 4.8.0 20121028 (experimental) (MacPorts gcc48 4.8-20121028_0) localhost:ruby clundquist$ make CC = gcc LD = ld LDSHARED = gcc -dynamic -bundle CFLAGS = -O3 -ggdb -Wall -Wextra -Wno-unused-parameter -Wno-parentheses -Wno-long-long -Wno-missing-field-initializers -Werror=pointer-arith -Werror=write-strings -Werror=declaration-after-statement -Werror=implicit-function-declaration -pipe XCFLAGS = -include ruby/config.h -include ruby/missing.h -fvisibility=hidden -DRUBY_EXPORT CPPFLAGS = -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -I. -I.ext/include/x86_64-darwin12.2.0 -I./include -I. DLDFLAGS = -Wl,-undefined,dynamic_lookup -Wl,-multiply_defined,suppress -Wl,-flat_namespace SOLIBS = compiling complex.c complex.c:1988:1: internal compiler error: in inline_call, at ipa-inline-transform.c:269 } ^ complex.c:1988:1: internal compiler error: Abort trap: 6 gcc: internal compiler error: Abort trap: 6 (program cc1) make: *** [complex.o] Abort trap: 6 make: *** Deleting file `complex.o'
[Bug libstdc++/54075] [4.7.1] unordered_map insert 3x slower than 4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075
James Y Knight changed:
What|Removed |Added
CC||foom at fuhm dot net
--- Comment #34 from James Y Knight 2012-11-04 04:55:30
UTC ---
Well, I haven't looked into this issue in detail, but, it looks like everyone
is about the same speed if you put a foo.{reserve or rehash}(n) before the
inserts.
Unfortunately, it doesn't look as simple as the new impl calling for a rehash
more often than the old, cause it's not. So, I don't know if the slowness is
because rehash is now a lot slower, or if insert is slower but only if there
aren't a huge number of empty buckets.
I'll also note that libc++'s implementation (seen here:
http://llvm.org/svn/llvm-project/libcxx/trunk/) appears to be getting the same
speed as the old libstdc++ implementation, while appearing to have
approximately the same bucket datastructure as the new libstdc++
implementation. That says to me that it should be *possible* somehow to make
the new version fast.
[Bug target/54747] config/bfin/bfin.c:2721: possible missing break ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54747 Joel Sherrill changed: What|Removed |Added CC||joel at gcc dot gnu.org --- Comment #1 from Joel Sherrill 2012-11-04 03:56:33 UTC --- Bernd... does the git bisect help you narrow down a fix?
[Bug target/55192] bfin generates invalid assembly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55192 --- Comment #1 from Joel Sherrill 2012-11-04 03:55:28 UTC --- Output of git bisect [joel@baltimore gcc]$ git bisect good Bisecting: 3 revisions left to test after this (roughly 2 steps) [5169661db3501031dfeb1971582809a702d6cebe] Integrate lexical block into source_location. [joel@baltimore gcc]$ git bisect bad Bisecting: 0 revisions left to test after this (roughly 1 step) [d452a16984ecc2f20644649f33c8ee38b246cbf0] * dbgcnt.def (sched_breakdep): New counter. * haifa-sched.c (update_insn_after_change): New static function, broken out of haifa_change_pattern. (haifa_change_pattern): Call it. (dep_t heap vecs): Declare. (INSN_COST): Define earlier. (next_cycle_replace_deps, next_cycle_apply): New static variables. (apply_replacement): New static function. (recompute_todo_spec): New argument FOR_BACKTRACK. All callers changed. Handle DEP_REPLACE deps. (contributes_to_priority_p): False for replaceable deps. (must_restore_pattern_p, restore_pattern): New static functions. (schedule_insn): Use them. Apply replacements for broken deps. (struct haifa_saved_data): Add new fields to keep track of replacements. (save_backtrack_point): Initialize them. (undo_replacements_for_backtrack): New static function. (restore_last_backtrack_point, free_topmost_backtrack_point): Use it and keep track of replacements. (perform_replacements_new_cycle, undo_all_replacements): New static functions. (schedule_block): Call these two as necessary. Call find_modifiable_mems. (try_ready): Tweak the assert. Check for DEP_POSTPONED. * sched-deps.c: Include "emit-rtl.h". (init_dep_1): Initialize DEP_NONREG, DEP_MULTIPLE and DEP_REPLACE. (dep_spec_p): True for DEP_REPLACE deps. (mark_as_hard): New static variable. (update_dep): Update DEP_NONREG and DEP_MULTIPLE. (add_dependence_list): New argument hard. All callers changed. Set and clear mark_as_hard around function body. (add_dependence_list_and_free): Likewise. (haifa_note_mem_dep): Set DEP_NONREG. (haifa_note_dep): Likewise if mark_as_hard is true. (sched_analyze_insn): Switch loop with if statement testing for sel_sched_p. (struct mem_inc_info): New. (attempt_change, parse_add_or_inc, find_inc, find_mem): New static functions. (find_modifiable_mems): New function. * sched-int.h (struct dep_replacement): New. (struct _dep): Add replace, nonreg and multiple fields. Make type and cost bitfields. (UNKNOWN_DEP_COST): Change to match the bitfield. (DEP_NONREG, DEP_MULTIPLE, DEP_REPLACE): New macros. (DEP_POSTPONED): New macro. (DEP_CANCELLED): Renumber. (find_modifiable_mems): Declare. (enum SCHED_FLAGS): Add DONT_BREAK_DEPENDENCIES. * sched-rgn.c (init_ready_list): Set TODO_SPEC here. (new_ready): Don't set HARD_DEP, use DEP_POSTPONED. (debug_dependencies): Dump DEP_NONREG and DEP_MULTIPLE. * Makefile.in (sched-deps.o): Update dependencies. * config/c6x/c6x.c (in_hwloop): New static variable. (c6x_set_sched_flags): If it is true, add DONT_BREAK_DEPENDENCIES. (hwloop_optimize): Set and clear it around preliminary scheduling pass. [joel@baltimore gcc]$ * I think this might be too far since this appears to be powerpc specific. [joel@baltimore gcc]$ git bisect bad Bisecting: 0 revisions left to test after this (roughly 0 steps) [77ff7cbfe77156dc41943effa80948572fe383fa] 2012-09-19 Tulio Magno Quites Machado Filho [joel@baltimore gcc]$
[Bug middle-end/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195 --- Comment #2 from dave.anglin at bell dot net 2012-11-04 02:52:31 UTC --- On 3-Nov-12, at 4:45 PM, amylaar at gcc dot gnu.org wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195 > > --- Comment #1 from Jorn Wolfgang Rennecke gnu.org> 2012-11-03 20:45:10 UTC --- > Could you attach preprocessed source and the exact options passsed > to cc1 > (from -v --save-temos compilation) so that I can look at this in a > cross > environment? Unfortunately, -v -save-temps doesn't save the java source from a list input. So far, I've only seen this with jc1. I imagine this is because the input is huge. This is compilation command: /home/dave/gnu/gcc/objdir/./gcc/jc1 ../../../gcc/libjava/classpath/lib/ gnu/javax/swing/text/html/parser/HTML_401F.class -fuse-divide- subroutine -fuse-boehm-gc -fnon-call-exceptions -fkeep-inline- functions -quiet -dumpbase HTML_401F.class -auxbase-strip gnu/javax/ swing/text/html/parser/.libs/HTML_401F.o -g -O2 -Wno-deprecated - version -fencoding=UTF-8 -fbootstrap-classes -fsource-filename=/home/ dave/gnu/gcc/objdir/hppa-linux-gnu/libjava/classpath/lib/classes -fPIC -fbootclasspath=./:../../../gcc/libjava/classpath/lib/ -faux-classpath HTML_401F.zip -MD_ -MT gnu/javax/swing/text/html/parser/HTML_401F.lo - MF gnu/javax/swing/text/html/p arser/HTML_401F.deps -o HTML_401F.s Dave -- John David Anglindave.ang...@bell.net
[Bug middle-end/55198] [4.8 Regression] libquadmath/math/fmaq.c:233:7: internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55198 Andrew Pinski changed: What|Removed |Added Component|libquadmath |middle-end Target Milestone|--- |4.8.0 --- Comment #1 from Andrew Pinski 2012-11-04 02:38:37 UTC --- >Probably introduced by: Exposed as this is a change in the library and the compiler is crashing with a valid input that the change introduced.
[Bug fortran/55199] New: Equivalenced variable has wrong type when used with generic member function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55199 Bug #: 55199 Summary: Equivalenced variable has wrong type when used with generic member function Classification: Unclassified Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: towns...@astro.wisc.edu Created attachment 28606 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28606 Test program to reproduce the error The attached program fails to compile, with the following error: assoc_err.f90:49.8: a = a + b 1 Error: Operands of binary numeric operator '+' at (1) are REAL(4)/TYPE(foo_t) However, the equivalence statement has b => f%func(1.), which has a type of REAL(4) and not TYPE(foo_t). The problem goes away if I replace the generic function reference with a specific one: b => f%func_1(1.)
[Bug middle-end/54838] [4.8 Regression] ICE: in merge_latch_edges, at cfgloop.c:678 with -ftracer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54838 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |mpolacek at gcc dot gnu.org |gnu.org | --- Comment #4 from Marek Polacek 2012-11-04 02:33:36 UTC --- Looking into it.
[Bug libquadmath/55198] New: [4.8 Regression] libquadmath/math/fmaq.c:233:7: internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55198
Bug #: 55198
Summary: [4.8 Regression] libquadmath/math/fmaq.c:233:7:
internal compiler error
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libquadmath
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dang...@gcc.gnu.org
Host: hppa2.0w-hp-hpux11.11
Target: hppa2.0w-hp-hpux11.11
Build: hppa2.0w-hp-hpux11.11
libtool: compile: /test/gnu/gcc/objdir/./gcc/xgcc
-B/test/gnu/gcc/objdir/./gcc/
-B/opt/gnu/gcc/gcc-4.8/hppa2.0w-hp-hpux11.11/bin/
-B/opt/gnu/gcc/gcc-4.8/hppa2.0w-hp-hpux11.11/lib/ -isystem
/opt/gnu/gcc/gcc-4.8/hppa2.0w-hp-hpux11.11/include
-isystem /opt/gnu/gcc/gcc-4.8/hppa2.0w-hp-hpux11.11/sys-include
-DHAVE_CONFIG_H
-I. -I../../../gcc/libquadmath -g -O2 -MT math/fmaq.lo -MD -MP -MF
math/.deps/f
maq.Tpo -c ../../../gcc/libquadmath/math/fmaq.c -fPIC -DPIC -o
math/.libs/fmaq.o../../../gcc/libquadmath/math/fmaq.c: In function
'fmaq':../../../gcc/libquadmath/math/fmaq.c:233:7: internal compiler error: in
expand_asm_operands, at stmt.c:912
asm volatile ("" : : "m" (v.value));
^../../../gcc/libquadmath/math/fmaq.c:233:7: internal compiler error: Aborted
Probably introduced by:
2012-10-31 Tobias Burnus
Joseph Myers
David S. Miller
Ulrich Drepper
Marek Polacek :
Petr Baudis
* math/complex.c (csqrtq): NaN and INF fixes.
* math/sqrtq.c (sqrt): NaN, INF and < 0 fixes.
* math/expm1q.c (expm1q): Changes from GLIBC. Use expq for
large parameters. Fix errno for boundary conditions.
* math/finiteq.c (finiteq): Add comment.
* math/fmaq.c (fmaq): Changes from GLIBC. Fix missing underflows
and bad results for some subnormal results. Fix sign of inexact
zero return. Fix sign of exact zero return.
Ensure additions are not scheduled after fetestexcept.
-bash-3.2$ ./xgcc -B./ -v
Reading specs from ./specs
COLLECT_GCC=./xgcc
COLLECT_LTO_WRAPPER=./lto-wrapper
Target: hppa2.0w-hp-hpux11.11
Configured with: ../gcc/configure --with-gnu-as --with-as=/opt/gnu/bin/as
--enable-shared --with-local-prefix=/opt/gnu --prefix=/opt/gnu/gcc/gcc-4.8
--with-gmp=/opt/gnu/gcc/gmp --enable-threads=posix --enable-debug=no
--disable-nls --without-cloog --without-ppl
--enable-languages=c,c++,objc,java,ada,obj-c++
Thread model: posix
gcc version 4.8.0 20121103 (experimental) [trunk revision 193124] (GCC)
[Bug other/54490] [4.7 Regression] ICE: Spill failure in newlib build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54490 --- Comment #5 from Joel Sherrill 2012-11-04 01:56:28 UTC --- Created attachment 28605 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28605 Preprocessed test case - from newlib
[Bug other/54490] [4.7 Regression] ICE: Spill failure in newlib build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54490
Joel Sherrill changed:
What|Removed |Added
CC||joel at gcc dot gnu.org
--- Comment #4 from Joel Sherrill 2012-11-04 01:55:21
UTC ---
Still happening but on a different file. Preprocessed source attached.
xgcc (GCC) 4.8.0 20121103 (experimental) [trunk revision 193124]
Short command to go with preprocessed source:
/home/joel/v850/tools/b-gcc-svn-avr-rtems4.11/./gcc/xgcc
-B/home/joel/v850/tools/b-gcc-svn-avr-rtems4.11/./gcc/ -mmcu=avr25 -Os
-mcall-prologues -Wall -fno-builtin -g -O2 -c t.c
Fails similarly at -O2 and -Os. Works at -O0.
Full command:
/home/joel/v850/tools/b-gcc-svn-avr-rtems4.11/./gcc/xgcc
-B/home/joel/v850/tools/b-gcc-svn-avr-rtems4.11/./gcc/ -nostdinc
-B/home/joel/v850/tools/b-gcc-svn-avr-rtems4.11/avr-rtems4.11/avr25/newlib/
-isystem
/home/joel/v850/tools/b-gcc-svn-avr-rtems4.11/avr-rtems4.11/avr25/newlib/targ-include
-isystem /home/joel/v850/tools/gcc-svn/newlib/libc/include
-B/home/joel/v850/install/avr-rtems4.11/bin/
-B/home/joel/v850/install/avr-rtems4.11/lib/ -isystem
/home/joel/v850/install/avr-rtems4.11/include -isystem
/home/joel/v850/install/avr-rtems4.11/sys-include -mmcu=avr25
-DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
-DPACKAGE_VERSION=\"1.20.0\" -DPACKAGE_STRING=\"newlib\ 1.20.0\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I.
-I../../../../../../gcc-svn/newlib/libc/time -Os -DPREFER_SIZE_OVER_SPEED
-mcall-prologues -D_COMPILING_NEWLIB -DMALLOC_PROVIDED -DEXIT_PROVIDED
-DSIGNAL_PROVIDED -DREENTRANT_SYSCALLS_PROVIDED -DHAVE_NANOSLEEP -DHAVE_BLKSIZE
-DHAVE_FCNTL -DHAVE_ASSERT_FUNC -D_NO_GETLOGIN -D_NO_GETPWENT -D_NO_GETUT
-D_NO_GETPASS -D_NO_SIGSET -D_NO_WORDEXP -D_NO_POPEN -Wall -fno-builtin -g
-O2 -c -o lib_a-tzset_r.o `test -f 'tzset_r.c' || echo
'../../../../../../gcc-svn/newlib/libc/time/'`tzset_r.c
../../../../../../gcc-svn/newlib/libc/time/tzset_r.c: In function '_tzset_r':
../../../../../../gcc-svn/newlib/libc/time/tzset_r.c:203:1: error: unable to
find a register to spill in class 'R0_REG'
}
^
../../../../../../gcc-svn/newlib/libc/time/tzset_r.c:203:1: error: this is the
insn:
(insn 474 471 477 34 (set (mem:QI (post_dec:HI (reg/f:HI 32 __SP_L__)) [0 S1
A8])
(subreg:QI (reg/f:HI 441) 1))
../../../../../../gcc-svn/newlib/libc/time/tzset_r.c:128 1 {pushqi1}
(expr_list:REG_ARGS_SIZE (const_int 13 [0xd])
(nil)))
../../../../../../gcc-svn/newlib/libc/time/tzset_r.c:203:1: internal compiler
error: in spill_failure, at reload1.c:2124
0x84b8885 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc-svn/gcc/rtl-error.c:110
0x84b84ff spill_failure
../../gcc-svn/gcc/reload1.c:2124
0x84b84ff find_reload_regs
../../gcc-svn/gcc/reload1.c:2050
0x84b84ff select_reload_regs
../../gcc-svn/gcc/reload1.c:2070
0x84b84ff reload(rtx_def*, int)
../../gcc-svn/gcc/reload1.c:991
0x83e31fd do_reload
../../gcc-svn/gcc/ira.c:4636
0x83e31fd rest_of_handle_reload
../../gcc-svn/gcc/ira.c:4737
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
make: *** [lib_a-tzset_r.o] Error 1
[Bug fortran/55197] Use statement for omp_lib causes ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55197 Tobias Burnus changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-03 CC||burnus at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Tobias Burnus 2012-11-03 23:28:00 UTC --- Confirmed. The problem is that we do in module.c's gfc_use_modules: gfc_use_module (module_list); if (module_list->intrinsic) free_rename (module_list->rename); But then in trans-decl.c's gfc_trans_use_stmts: for (rent = use_stmt->rename; rent; rent = rent->next) While freeing the memory is probably fine for build-in intrinsic modules like ISO_Fortran_env and ISO_C_Binding; however, doing so for intrinsic modules which are loaded for a file is wrong. (Side note: We should free the rename list in trans-decl.c to avoid mem leaks.)
[Bug fortran/55197] New: Use statement for omp_lib causes ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55197 Bug #: 55197 Summary: Use statement for omp_lib causes ICE Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: eh.toussa...@gmail.com The following short program causes an ICE in (MinGW) gfortran 4.7.0. use, intrinsic :: omp_lib, only: omp_get_num_threads end $ gfortran -c -fopenmp tmp.f90 tmp.f90:1:0: internal compiler error: in gfc_trans_use_stmts, at fortran/trans-d ecl.c:4133 Both the 'intrinsic' attribute and the 'only' clause are required to trip the error. $ gcc -v Using built-in specs. COLLECT_GCC=E:\mingw\bin\gcc.exe COLLECT_LTO_WRAPPER=e:/mingw/bin/../libexec/gcc/mingw32/4.7.0/lto-wrapper.exe Target: mingw32 Configured with: ../gcc-4.7.0/configure --enable-languages=c,c++,ada,fortran,obj c,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgo mp --disable-win32-registry --enable-libstdcxx-debug --disable-build-poststage1- with-cxx --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw Thread model: win32 gcc version 4.7.0 (GCC)
[Bug target/54791] AIX-only: Constructors are not called in main program.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54791 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-03 Ever Confirmed|0 |1 --- Comment #9 from David Edelsohn 2012-11-03 22:48:06 UTC --- > So just to be 100% sure on this: If I want to be sure all my constructors are > called I should not have any of them inlined. Correct ? > What about if I have a constructor body/implementation inside a class > declaration ? Does the compiler inline that as well? I guess it might. I am not positive that inlining is the problem, but that seems like a good hypothesis. collect2 scans object files looking for constructors by name, e.g., GLOBAL__I_ You can look at the global symbols using $ nm -BCpg .o If the constructors are visible when NOT inlined and disappear when they are inlined, that is the problem. If "nm" cannot see them, the mechanism for creating the list of constructors (and destructors) cannot see them either. > So how do you see this case. Is it not a bug? I mean I am expecting my > constructors to be called and they are not. > Do you know a easy way to solve this without modifying all my constructors ? > (any compiler options perhaps, ..using __attribute__((constructor)) ) ? The methods already are constructors. Additional attributes will not make a difference. If you can create a small, self-contained testcase with a constructor that works or does not work depending on inlined, I can look. I am not sure how inlined constructors are recorded in ELF files. This sounds like a bug, but it will take some investigation to figure out how difficult it is to fix given the behavior of AIX and GCC. Inlined constructors may not be a practical option on AIX. Also, please use the GCC Bugzilla interface for comments and attaching testcases, not email replies. There probably is a way to add attachments using email, but I do not know how and Bugzilla is much more useful without all of the email history already present in the comment history.
[Bug target/54255] FAIL: gcc.target/i386/asm-dialect-1.c (test for excess errors) fails on x86_64/i686 darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54255 --- Comment #4 from hjl at gcc dot gnu.org 2012-11-03 21:39:10 UTC --- Author: hjl Date: Sat Nov 3 21:39:06 2012 New Revision: 193127 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193127 Log: Add check_effective_target_masm_intel PR target/54255 * lib/target-supports.exp (check_effective_target_masm_intel): New proc. * gcc.target/i386/asm-dialect-1.c: Use dg-require-effective-target masm_intel. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/asm-dialect-1.c trunk/gcc/testsuite/lib/target-supports.exp
[Bug middle-end/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195 --- Comment #1 from Jorn Wolfgang Rennecke 2012-11-03 20:45:10 UTC --- Could you attach preprocessed source and the exact options passsed to cc1 (from -v --save-temos compilation) so that I can look at this in a cross environment?
[Bug bootstrap/55196] New: GCC 4.8 build error : link error on OS X 10.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55196 Bug #: 55196 Summary: GCC 4.8 build error : link error on OS X 10.6 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: xcode...@xif.fr GCC 4.8 build error On Mac OS X 10.6.8 (x86_64) configured with ./configure --enable-languages=c,c++,objc,obj-c++ --prefix=/usr _ g++ -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -o cc1 c/c-lang.o c-family/stub-objc.o attribs.o c/c-errors.o c/c-decl.o c/c-typeck.o c/c-convert.o c/c-aux-info.o c/c-objc-common.o c/c-parser.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o tree-mudflap.o i386-c.o darwin-c.o cc1-checksum.o libbackend.a main.o tree-browser.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a -lintl ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -lmpc -lmpfr -lgmp -L../zlib -lz ld: warning: ignoring file libcommon-target.a, file was built for archive which is not the architecture being linked (x86_64) ld: warning: ignoring file libcommon.a, file was built for archive which is not the architecture being linked (x86_64) ld: warning: ignoring file ../libcpp/libcpp.a, file was built for archive which is not the architecture being linked (x86_64) ld: warning: ignoring file ../libdecnumber/libdecnumber.a, file was built for archive which is not the architecture being linked (x86_64) Undefined symbols for architecture x86_64: [LOT OF SYMBOLS...] ld: symbol(s) not found for architecture x86_64 collect2: erreur: ld a retourné 1 code d'état d'exécution make[3]: *** [cc1] Error 1 make[2]: *** [all-stage1-gcc] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [all] Error 2 _ Thanks
[Bug target/54791] AIX-only: Constructors are not called in main program.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54791 --- Comment #8 from Adi 2012-11-03 19:14:41 UTC --- Thank you for your response. (Sorry for the repeated emails. I did it because I got delivery failures on the first 4 mails.) So just to be 100% sure on this: If I want to be sure all my constructors are called I should not have any of them inlined. Correct ? What about if I have a constructor body/implementation inside a class declaration ? Does the compiler inline that as well? I guess it might. So how do you see this case. Is it not a bug? I mean I am expecting my constructors to be called and they are not. Do you know a easy way to solve this without modifying all my constructors ? (any compiler options perhaps, ..using __attribute__((constructor)) ) ? PS: If I want to send you an attachment in a mail what format should it be ? txt, doc ? I got some delivery failures,... that's why I am asking. From: dje at gcc dot gnu.org To: adivilce...@yahoo.com Sent: Saturday, November 3, 2012 3:48 PM Subject: [Bug target/54791] AIX-only: Constructors are not called in main program. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54791 --- Comment #7 from David Edelsohn 2012-11-03 13:48:46 UTC --- The New York area has experienced a major natural disaster. I am located near NYC. GCC support is provided by volunteers. Repeatedly resending your message will not elicit a faster response. AIX uses the XCOFF file format, not ELF. The object files do not contain .ctor or .init sections to define constructors. The GCC collect2 wrapper scans object files for constructors and creates a function to call them. If the constructors are inlined, the symbols might not appear when the object files are scanned, preventing them from being included in the list of constructors to call.
[Bug tree-optimization/55188] [4.8 regression] FAIL: gcc.dg/pr19105.c scan-tree-dump-times reassoc1 "Optimizing range tests v_[0-9]*.D. -.2, 2. and -.3, 4.[\n\r]* into" 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55188 Andreas Schwab changed: What|Removed |Added Target|m68k-*-*| --- Comment #1 from Andreas Schwab 2012-11-03 18:55:00 UTC --- Also fails on powerpc.
[Bug rtl-optimization/54524] [4.6/4.7 Regression] Spurious add on sum of bitshifts (forward-propagate issue)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54524 --- Comment #9 from Jan Smets 2012-11-03 18:25:32 UTC --- Verified. Thanks Andrew. (Should I mark it as Resolved?)
[Bug c/50928] m32c ICE building RTEMS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50928 --- Comment #3 from Joel Sherrill 2012-11-03 17:23:38 UTC --- Created attachment 28604 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28604 libgcc preprocessed file which trips bug Description on how to reproduce given messages.
[Bug c/50928] m32c ICE building RTEMS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50928
--- Comment #2 from Joel Sherrill 2012-11-03 17:22:30
UTC ---
xgcc (GCC) 4.8.0 20121103 (experimental) [trunk revision 193124]
Now fails just building libgcc with what appears to be the same error.
Short command line for preprocessed source I will attach
/home/joel/v850/tools/b-gcc-svn/./gcc/xgcc
-B/home/joel/v850/tools/b-gcc-svn/./gcc/ -c m32c_bug.c -O2 -mcpu=m32cm
At -O0, it compiles
Full command line:
/home/joel/v850/tools/b-gcc-svn/./gcc/xgcc
-B/home/joel/v850/tools/b-gcc-svn/./gcc/ -nostdinc
-B/home/joel/v850/tools/b-gcc-svn/m32c-rtems4.11/newlib/ -isystem
/home/joel/v850/tools/b-gcc-svn/m32c-rtems4.11/newlib/targ-include -isystem
/home/joel/v850/tools/gcc-svn/newlib/libc/include
-B/home/joel/v850/install/m32c-rtems4.11/bin/
-B/home/joel/v850/install/m32c-rtems4.11/lib/ -isystem
/home/joel/v850/install/m32c-rtems4.11/include -isystem
/home/joel/v850/install/m32c-rtems4.11/sys-include-g -O2 -mcpu=m32cm -O2
-I../../../../gcc-svn/libgcc/../newlib/libc/sys/rtems/include -g -O2 -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem
./include -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector
-Dinhibit_libc -I. -I. -I../../.././gcc -I../../../../gcc-svn/libgcc
-I../../../../gcc-svn/libgcc/. -I../../../../gcc-svn/libgcc/../gcc
-I../../../../gcc-svn/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o
_ffssi2.o -MT _ffssi2.o -MD -MP -MF _ffssi2.dep -DL_ffssi2 -c
../../../../gcc-svn/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
../../../../gcc-svn/libgcc/libgcc2.c: In function '__ffssi2':
../../../../gcc-svn/libgcc/libgcc2.c:524:1: error: unable to find a register to
spill in class 'A_REGS'
}
^
../../../../gcc-svn/libgcc/libgcc2.c:524:1: error: this is the insn:
(insn 58 56 59 10 (set (reg:HI 0 r0 [orig:26 D.2772 ] [26])
(zero_extend:HI (mem/u/j:QI (plus:PSI (subreg:PSI (reg:SI 68 [ D.2773
]) 0)
(symbol_ref:PSI ("__clz_tab") [flags 0x40] )) [0 __clz_tab S1 A8])))
../../../../gcc-svn/libgcc/libgcc2.c:522 115 {zero_extendqihi2}
(expr_list:REG_DEAD (reg:SI 68 [ D.2773 ])
(nil)))
../../../../gcc-svn/libgcc/libgcc2.c:524:1: internal compiler error: in
spill_failure, at reload1.c:2124
0x849f565 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc-svn/gcc/rtl-error.c:110
0x849f2c3 spill_failure
../../gcc-svn/gcc/reload1.c:2124
0x849f2c3 find_reload_regs
../../gcc-svn/gcc/reload1.c:2050
0x849f2c3 select_reload_regs
../../gcc-svn/gcc/reload1.c:2070
0x849f2c3 reload(rtx_def*, int)
../../gcc-svn/gcc/reload1.c:991
0x83cb8ea do_reload
../../gcc-svn/gcc/ira.c:4636
0x83cb8ea rest_of_handle_reload
../../gcc-svn/gcc/ira.c:4737
[Bug bootstrap/52466] gcc-4.7.0-RC-20120302 fails to build for --target=lm32-rtems4.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52466 Joel Sherrill changed: What|Removed |Added CC||joel at gcc dot gnu.org Version|unknown |4.8.0 --- Comment #2 from Joel Sherrill 2012-11-03 17:08:34 UTC --- Still broken xgcc (GCC) 4.8.0 20121103 (experimental) [trunk revision 193124] Any chance I can get some advice on how to fix this? The autoconf probe just isn't finding what it expects.
[Bug target/55194] h8300 ICE during conftest in libgcc dwarf2out:7605
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55194 --- Comment #1 from Joel Sherrill 2012-11-03 17:07:01 UTC --- Sorry... bad cut and paste. The assembly is OK. The cross compiler generates an ICE.
[Bug middle-end/55195] New: [4.8 Regression] shorten_branches generates incorrect forward branch distances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195 Bug #: 55195 Summary: [4.8 Regression] shorten_branches generates incorrect forward branch distances Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org CC: amyl...@gcc.gnu.org Host: hppa-unknown-linux-gnu Target: hppa-unknown-linux-gnu Build: hppa-unknown-linux-gnu /bin/sh ./libtool --tag=GCJ --mode=compile /home/dave/gnu/gcc/objdir/./gcc/gcj -B/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libjava/ -B/home/dave/gnu/gcc/objdir /./gcc/ -B/home/dave/opt/gnu/gcc/gcc-4.8.0/hppa-linux-gnu/bin/ -B/home/dave/opt/ gnu/gcc/gcc-4.8.0/hppa-linux-gnu/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-4.8.0/ hppa-linux-gnu/include -isystem /home/dave/opt/gnu/gcc/gcc-4.8.0/hppa-linux-gnu/ sys-include-fclasspath= -fbootclasspath=../../../gcc/libjava/classpath/lib - -encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c -o gnu/javax/swin g/text/html/parser/HTML_401F.lo -fsource-filename=/home/dave/gnu/gcc/objdir/hppa -linux-gnu/libjava/classpath/lib/classes -MT gnu/javax/swing/text/html/parser/HT ML_401F.lo -MD -MP -MF gnu/javax/swing/text/html/parser/HTML_401F.deps @gnu/java x/swing/text/html/parser/HTML_401F.list libtool: compile: /home/dave/gnu/gcc/objdir/./gcc/gcj -B/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libjava/ -B/home/dave/gnu/gcc/objdir/./gcc/ -B/home/dave/opt/gnu/gcc/gcc-4.8.0/hppa-linux-gnu/bin/ -B/home/dave/opt/gnu/gcc/gcc-4.8.0/hppa-linux-gnu/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-4.8.0/hppa-linux-gnu/include -isystem /home/dave/opt/gnu/gcc/gcc-4.8.0/hppa-linux-gnu/sys-include -fclasspath= -fbootclasspath=../../../gcc/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c -fsource-filename=/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libjava/classpath/lib/classes -MT gnu/javax/swing/text/html/parser/HTML_401F.lo -MD -MP -MF gnu/javax/swing/text/html/parser/HTML_401F.deps @gnu/javax/swing/text/html/parser/HTML_401F.list -fPIC -o gnu/javax/swing/text/html/parser/.libs/HTML_401F.o /tmp/cc4e6qnd.s: Assembler messages: /tmp/cc4e6qnd.s:79330: Error: Field out of range [-8192..8191] (8316). /tmp/cc4e6qnd.s:79362: Error: Field out of range [-8192..8191] (8280). /tmp/cc4e6qnd.s:79395: Error: Field out of range [-8192..8191] (8244). /tmp/cc4e6qnd.s:79428: Error: Field out of range [-8192..8191] (8208). make[3]: *** [gnu/javax/swing/text/html/parser/HTML_401F.lo] Error 1 /bin/sh ./libtool --tag=GCJ --mode=compile /home/dave/gnu/gcc/objdir/./gcc/gcj -B/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libjava/ -B/home/dave/gnu/gcc/objdir /./gcc/ -B/home/dave/opt/gnu/gcc/gcc-4.8.0/hppa-linux-gnu/bin/ -B/home/dave/opt/ gnu/gcc/gcc-4.8.0/hppa-linux-gnu/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-4.8.0/ hppa-linux-gnu/include -isystem /home/dave/opt/gnu/gcc/gcc-4.8.0/hppa-linux-gnu/ sys-include-fclasspath= -fbootclasspath=../../../gcc/libjava/classpath/lib - -encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c -o gnu/java/nio/c harset.lo -fsource-filename=/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libjava/cla sspath/lib/classes -MT gnu/java/nio/charset.lo -MD -MP -MF gnu/java/nio/charset. deps @gnu/java/nio/charset.list libtool: compile: /home/dave/gnu/gcc/objdir/./gcc/gcj -B/home/dave/gnu/gcc/objd ir/hppa-linux-gnu/libjava/ -B/home/dave/gnu/gcc/objdir/./gcc/ -B/home/dave/opt/g nu/gcc/gcc-4.8.0/hppa-linux-gnu/bin/ -B/home/dave/opt/gnu/gcc/gcc-4.8.0/hppa-lin ux-gnu/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-4.8.0/hppa-linux-gnu/include -is ystem /home/dave/opt/gnu/gcc/gcc-4.8.0/hppa-linux-gnu/sys-include -fclasspath= - fbootclasspath=../../../gcc/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecat ed -fbootstrap-classes -g -O2 -c -fsource-filename=/home/dave/gnu/gcc/objdir/hpp a-linux-gnu/libjava/classpath/lib/classes -MT gnu/java/nio/charset.lo -MD -MP -M F gnu/java/nio/charset.deps @gnu/java/nio/charset.list -fPIC -o gnu/java/nio/.l ibs/charset.o /tmp/ccKzEAz7.s: Assembler messages: /tmp/ccKzEAz7.s:105074: Error: Field out of range [-8192..8191] (9344). /tmp/ccKzEAz7.s:105079: Error: Field out of range [-8192..8191] (9288). /tmp/ccKzEAz7.s:105084: Error: Field out of range [-8192..8191] (9232). /tmp/ccKzEAz7.s:105089: Error: Field out of range [-8192..8191] (9176). /tmp/ccKzEAz7.s:105094: Error: Field out of range [-8192..8191] (9120). /tmp/ccKzEAz7.s:105099: Error: Field out of range [-8192..8191] (9064). /tmp/ccKzEAz7.s:105104: Error: Field out of range [-8192..8191] (9008). /tmp/ccKzEAz7.s:105109: Error: Field out of range [-8192..8191] (8952). /tmp/ccKzEAz7.s:105114: Error: Field out of range [-8192..8191
[Bug debug/55193] ICE in in simplify_const_unary_operation, at simplify-rtx.c:1659
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55193 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-03 CC||mpolacek at gcc dot ||gnu.org, vmakarov at gcc ||dot gnu.org Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #1 from Marek Polacek 2012-11-03 16:58:10 UTC --- Started http://gcc.gnu.org/viewcvs?view=revision&revision=192719
[Bug tree-optimization/55191] [4.8 Regression] ICE in compute_antic at tree-ssa-pre.c:2511
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55191 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-03 CC||mpolacek at gcc dot ||gnu.org, steven at gcc dot ||gnu.org Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #1 from Marek Polacek 2012-11-03 16:46:17 UTC --- Started with http://gcc.gnu.org/viewcvs?view=revision&revision=193047
[Bug tree-optimization/55187] [4.8 regression] FAIL: gcc.dg/autopar/pr49960.c scan-tree-dump-times parloops "SUCCESS: may be parallelized" 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55187 --- Comment #2 from Jan Hubicka 2012-11-03 16:44:14 UTC --- > --- Comment #1 from Andreas Schwab 2012-11-03 > 15:23:25 UTC --- > Also fails on powerpc, likely universal. Yes, it fails for me too, I am looking into it. Honza
[Bug target/55194] New: h8300 ICE during conftest in libgcc dwarf2out:7605
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55194
Bug #: 55194
Summary: h8300 ICE during conftest in libgcc dwarf2out:7605
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@gcc.gnu.org
When building newlib using the gcc-svn head, the compiler generates assembly
language that cannot be assembled by the binutils cvs head or 2.22
xgcc (GCC) 4.8.0 20121103 (experimental) [trunk revision 193124]
This is enough to trip the bug:
/home/joel/v850/tools/b-gcc-svn/./gcc/xgcc
-B/home/joel/v850/tools/b-gcc-svn/./gcc/ -c -O2 -g h8300_bug.c
Dropping the -g is sufficient to let it compile.
Test case is very basic:
int main(int argc, char **argv)
{
return 0;
}
The full command line:
configure:3374: /home/joel/v850/tools/b-gcc-svn/./gcc/xgcc
-B/home/joel/v850/tools/b-gcc-svn/./gcc/ -nostdinc
-B/home/joel/v850/tools/b-gcc-svn/h8300-rtems4.11/newlib/ -isystem
/home/joel/v850/tools/b-gcc-svn/h8300-rtems4.11/newlib/targ-include -isystem
/home/joel/v850/tools/gcc-svn/newlib/libc/include
-B/home/joel/v850/install/h8300-rtems4.11/bin/
-B/home/joel/v850/install/h8300-rtems4.11/lib/ -isystem
/home/joel/v850/install/h8300-rtems4.11/include -isystem
/home/joel/v850/install/h8300-rtems4.11/sys-include-o conftest -g -O2
conftest.c >&5
conftest.c:16:1: internal compiler error: in value_format, at dwarf2out.c:7605
}
^
0x8266d9f value_format
../../gcc-svn/gcc/dwarf2out.c:7605
0x8284966 output_value_format
../../gcc-svn/gcc/dwarf2out.c:7618
0x8284966 output_abbrev_section
../../gcc-svn/gcc/dwarf2out.c:7651
0x8284966 dwarf2out_finish
../../gcc-svn/gcc/dwarf2out.c:22527
[Bug debug/55193] New: ICE in in simplify_const_unary_operation, at simplify-rtx.c:1659
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55193 Bug #: 55193 Summary: ICE in in simplify_const_unary_operation, at simplify-rtx.c:1659 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: martin.kronbich...@it.uu.se Created attachment 28603 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28603 Delta-reduced test case With gcc trunk (rev 193123) on x86-64 linux: $ g++-4.8 -v Using built-in specs. COLLECT_GCC=g++-4.8 COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-linux-gnu/4.8.0/lto-wrapper Target: x86_64-linux-gnu Configured with: ../gcc_trunk/configure --enable-languages=c,c++,fortran --prefix=/usr/local --program-suffix=-4.8 --enable-shared --enable-linker-build-id --with-system-zlib --without-included-gettext --enable-threads=posix --enable-nls --enable-libstdcxx-time=yes --disable-multilib --enable-plugin --disable-werror --with-tune=corei7-avx --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-isl=/usr/local --with-cloog=/usr/local Thread model: posix gcc version 4.8.0 20121103 (experimental) (GCC) I compile the attached test case with command line: $ g++-4.8 -g -Og testcase2.i -c which leads to the ICE below. The error only appears with both -Og and -g specified. testcase2.i: In function ‘void foo(FEValues&, Tensor&, vector&)’: testcase2.i:49:7: internal compiler error: in simplify_const_unary_operation, at simplify-rtx.c:1659 } ^ 0x8a7063 simplify_const_unary_operation(rtx_code, machine_mode, rtx_def*, machine_mode) ../../gcc_trunk/gcc/simplify-rtx.c:1659 0x89ddda simplify_unary_operation(rtx_code, machine_mode, rtx_def*, machine_mode) ../../gcc_trunk/gcc/simplify-rtx.c:783 0x698a50 cselib_expand_value_rtx_1 ../../gcc_trunk/gcc/cselib.c:1826 0x699d6e cselib_expand_value_rtx_cb(rtx_def*, bitmap_head_def*, int, rtx_def* (*)(rtx_def*, bitmap_head_def*, int, void*), void*) ../../gcc_trunk/gcc/cselib.c:1534 0xa27488 vt_expand_var_loc_chain ../../gcc_trunk/gcc/var-tracking.c:8063 0xa27488 vt_expand_loc_callback ../../gcc_trunk/gcc/var-tracking.c:8225 0x69891f cselib_expand_value_rtx_1 ../../gcc_trunk/gcc/cselib.c:1687 0x699d6e cselib_expand_value_rtx_cb(rtx_def*, bitmap_head_def*, int, rtx_def* (*)(rtx_def*, bitmap_head_def*, int, void*), void*) ../../gcc_trunk/gcc/cselib.c:1534 0xa27cb7 vt_expand_var_loc_chain ../../gcc_trunk/gcc/var-tracking.c:8063 0xa27cb7 vt_expand_1pvar ../../gcc_trunk/gcc/var-tracking.c:8340 0xa2832f emit_note_insn_var_location ../../gcc_trunk/gcc/var-tracking.c:8394 0xd1da97 htab_traverse_noresize ../../gcc_trunk/libiberty/hashtab.c:784 0xa28cd7 emit_notes_for_changes ../../gcc_trunk/gcc/var-tracking.c:8757 0xa290c1 emit_notes_in_bb ../../gcc_trunk/gcc/var-tracking.c:9187 0xa290c1 vt_emit_notes ../../gcc_trunk/gcc/var-tracking.c:9249 0xa29839 variable_tracking_main_1 ../../gcc_trunk/gcc/var-tracking.c:10068 0xa29839 variable_tracking_main() ../../gcc_trunk/gcc/var-tracking.c:10082
[Bug c/55192] New: bfin generates invalid assembly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55192 Bug #: 55192 Summary: bfin generates invalid assembly Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: j...@gcc.gnu.org Created attachment 28602 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28602 Tarball of preprocessed C and generated assembly When building newlib using the gcc-svn head, the compiler generates assembly language that cannot be assembled by the binutils cvs head or 2.22 xgcc (GCC) 4.8.0 20121103 (experimental) [trunk revision 193124] Attached are the preprocessed C code and generated assembly. This is sufficient to trip the issue: /home/joel/v850/tools/b-gcc-svn/./gcc/xgcc -B/home/joel/v850/tools/b-gcc-svn/./gcc/ -c -fno-builtin -g -O2 -fshort-enums bfin_test.c /opt/rtems-4.11/bin/bfin-rtems4.11-as bfin_test.s bfin_test.s: Assembler messages: bfin_test.s:416: Error: syntax error. Input text was .LBE54. bfin_test.s:416: Error: The original command was: /home/joel/v850/tools/b-gcc-svn/./gcc/xgcc -B/home/joel/v850/tools/b-gcc-svn/./gcc/ -nostdinc -B/home/joel/v850/tools/b-gcc-svn/bfin-rtems4.11/newlib/ -isystem /home/joel/v850/tools/b-gcc-svn/bfin-rtems4.11/newlib/targ-include -isystem /home/joel/v850/tools/gcc-svn/newlib/libc/include -B/home/joel/v850/install/bfin-rtems4.11/bin/ -B/home/joel/v850/install/bfin-rtems4.11/lib/ -isystem /home/joel/v850/install/bfin-rtems4.11/include -isystem /home/joel/v850/install/bfin-rtems4.11/sys-include-DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\" -DPACKAGE_VERSION=\"1.20.0\" -DPACKAGE_STRING=\"newlib\ 1.20.0\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I. -I../../../../../gcc-svn/newlib/libc/stdio -D_COMPILING_NEWLIB -DMALLOC_PROVIDED -DEXIT_PROVIDED -DSIGNAL_PROVIDED -DREENTRANT_SYSCALLS_PROVIDED -DHAVE_NANOSLEEP -DHAVE_BLKSIZE -DHAVE_FCNTL -DHAVE_ASSERT_FUNC -D_NO_GETLOGIN -D_NO_GETPWENT -D_NO_GETUT -D_NO_GETPASS -D_NO_SIGSET -D_NO_WORDEXP -D_NO_POPEN -Wall -fno-builtin -g -O2 -fshort-enums -DINTEGER_ONLY -c ../../../../../gcc-svn/newlib/libc/stdio/vfprintf.c -E >bfin_test.c
[Bug libstdc++/54075] [4.7.1] unordered_map insert 3x slower than 4.6.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54075
--- Comment #33 from François Dumont 2012-11-03
15:28:30 UTC ---
I fear that this performance issue is a normal drawback of the major
enhancement for PR 41975. Before this evolution the hashtable data model was
like a std::vector. During the insert operation it was easy
to find out if the inserted element was already in the targetted bucket by
simply checking for equality with each element of the bucket forwward_list. The
code was something like:
for (auto it = bucket.begin(); it != bucket.end(); ++it)
if (comp(*it, element))
// The element already exists
return false;
// Ok, no equivalent element
return true;
After the evolution the data model became a combination of a
std::forward_list containing all elements and a
std::vector::iterator> representing buckets. Now to check
if an element is already in a bucket we still need to compare for equality with
each element of the bucket but the element of the bucket are harder to
identified. There is no more bucket end so we must also check that the element
we are about to compare is still in the bucket. The code became something like:
// Pre: bucket not empty.
for (auto it = buckets[n];)
{
if (comp(*it, element))
// The element already exists
return false;
++it;
if (it == end() || bucket(it) != n)
// We are not in bucket n anymore
return false;
}
// Ok, no equivalent element
return true;
The new design helps to iterate through the container because even if it is
almost empty we simply need to iterate within the forward_list. In the previous
implementation we needed to iterate within a bucket forward_list and then jump
above all empty buckets which could be very expensive. Try to run
testsuite/performance/23_containers/insert_erase/41975.cc, you can easily tweak
it to make it run with the tr1 implementation and you will notice the
difference. This test also show the insert overhead even if with a perfect
hasher like the one use in this test the impact is very limited.
To make bucket(it) not too expensive the new implementation caches most of the
time the hash code which explain the additional memory. You can try to ask for
it not to be cache but you might have to qualified your hasher with noexcept,
static assertions will tell you so.
So for the moment I can see a way to restore tr1 insert performance without
impacting erase performance. In my opinion, a Standard implementation needs to
behave correctly in all use cases and not to be perform very well in one use
case but very bad in an other.
[Bug tree-optimization/55187] [4.8 regression] FAIL: gcc.dg/autopar/pr49960.c scan-tree-dump-times parloops "SUCCESS: may be parallelized" 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55187 Andreas Schwab changed: What|Removed |Added Target|m68k-*-*| --- Comment #1 from Andreas Schwab 2012-11-03 15:23:25 UTC --- Also fails on powerpc, likely universal.
[Bug middle-end/53708] [4.8 Regression] Many failures of the objc tests with -O3 -fnext-runtime and -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53708 Peter Bergner changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #16 from Peter Bergner 2012-11-03 14:05:59 UTC --- Backported to 4.7.
[Bug middle-end/53708] [4.8 Regression] Many failures of the objc tests with -O3 -fnext-runtime and -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53708 --- Comment #15 from Peter Bergner 2012-11-03 14:02:20 UTC --- Author: bergner Date: Sat Nov 3 14:02:13 2012 New Revision: 193121 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193121 Log: Backport from mainline 2012-10-31 Jakub Jelinek PR tree-optimization/53708 * tree-vect-data-refs.c (vect_can_force_dr_alignment_p): Preserve user-supplied alignment when used with an explicit section name. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/tree-vect-data-refs.c
[Bug target/54791] AIX-only: Constructors are not called in main program.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54791 --- Comment #7 from David Edelsohn 2012-11-03 13:48:46 UTC --- The New York area has experienced a major natural disaster. I am located near NYC. GCC support is provided by volunteers. Repeatedly resending your message will not elicit a faster response. AIX uses the XCOFF file format, not ELF. The object files do not contain .ctor or .init sections to define constructors. The GCC collect2 wrapper scans object files for constructors and creates a function to call them. If the constructors are inlined, the symbols might not appear when the object files are scanned, preventing them from being included in the list of constructors to call.
[Bug c++/55189] enable -Wreturn-type by default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55189
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-11-03
Summary|g++ compiler does not |enable -Wreturn-type by
|report missing return on|default
|function with return type |
Ever Confirmed|0 |1
--- Comment #3 from Jonathan Wakely 2012-11-03
13:03:14 UTC ---
(In reply to comment #2)
> If this is not bug why shouldn't we make
>
> int n;
> n =;
> printf("%d",n);
>
> to be legal code, compiler should simply assign whatever it wants. Right ?
No, because that's not even legal syntax, so that's a completely different
case.
> -Wreturn-type should be set by default.
OK, so let's change the report to say that then.
In general though, please don't report bugs claiming there are no warnings if
you haven't even tried -Wall, there's a notice when you report a bug asking you
to check that.
Reduced example:
struct A { int i; };
A f()
{
A a = { 0 };
// missing return
}
int main()
{
A a = f();
return a.i;
}
[Bug translation/55191] New: ICE in compute_antic at tree-ssa-pre.c:2511
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55191
Bug #: 55191
Summary: ICE in compute_antic at tree-ssa-pre.c:2511
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: antoine.balest...@gmail.com
Hello !
The following testcase makes GCC 4.8.0 as of 20121103 ICE at -O2 and higher.
$ cat antic.c
int a, b;
void f(void)
{
b = a || b;
for(a = 0; a < 2; a++);
while(1);
}
$ xgcc -O2 -w antic.c
antic.c: In function ‘f’:
antic.c:3:6: internal compiler error: in compute_antic, at tree-ssa-pre.c:2511
void f(void)
^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[Bug tree-optimization/55162] Loop ivopts cuts off top bits of loop counter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55162 --- Comment #4 from Oleg Endo 2012-11-03 12:19:28 UTC --- (In reply to comment #3) I've created a new PR 55190 for this.
[Bug target/55190] New: [SH] ivopts causes loop setup bloat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55190
Bug #: 55190
Summary: [SH] ivopts causes loop setup bloat
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: olege...@gcc.gnu.org
Target: sh*-*-*
The following code:
struct X
{
int a, b, c, d, e;
};
int test (X* x, unsigned int c)
{
int s = 0;
unsigned int i;
for (i = 0; i < c; ++i)
s += x[i].b;
return s;
}
results in:
tst r5,r5
bt/s.L4
mov r5,r1
shll2 r1
add r5,r1
mov.l .L9,r2
shll2 r1
add #-20,r1
shlr2 r1
mul.l r2,r1
mov.l .L10,r2
add #4,r4
mov #0,r0
sts macl,r1
and r2,r1
add #1,r1
.L3:
mov.l @r4,r2
dt r1
add #20,r4
bf/s.L3
add r2,r0
rts
nop
.L4:
rts
mov #0,r0
.L11:
.align 2
.L9:
.long 214748365
.L10:
.long 1073741823
In such cases, the loop counter setup code that seems to be produced by ivopts
can be left out, which would result in something like:
tst r5,r5
bt/s.L15
add #4,r4
mov #0,r0
.L14:
mov.l @r4,r1
dt r5
add #20,r4
bf/s.L14
add r1,r0
rts
nop
.L15:
rts
mov #0,r0
[Bug target/51244] [SH] Inefficient conditional branch and code around T bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244 --- Comment #57 from Oleg Endo 2012-11-03 12:01:05 UTC --- Author: olegendo Date: Sat Nov 3 12:01:01 2012 New Revision: 193119 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193119 Log: PR target/51244 * config/sh/sh.md (*cbranch_t): Allow splitting after reload. Allow going beyond current basic block before reload when looking for the reg set insn. * config/sh/sh.c (sh_find_set_of_reg): Don't stop at labels. PR target/51244 * gcc.target/sh/pr51244-18.c: New. * gcc.target/sh/pr51244-19.c: New. Added: trunk/gcc/testsuite/gcc.target/sh/pr51244-18.c trunk/gcc/testsuite/gcc.target/sh/pr51244-19.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.c trunk/gcc/config/sh/sh.md trunk/gcc/testsuite/ChangeLog
[Bug c++/55189] g++ compiler does not report missing return on function with return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55189
--- Comment #2 from meanone 2012-11-03 11:11:15
UTC ---
(In reply to comment #1)
> (In reply to comment #0)
> > Compiled with MinGW port of g++, compiles without errors or warnings:
>
> It does warn if you ask it to: -Wall
I can understand that this is ok behavior for C, but to have to
EXPLICITLY ASK typesafe language like C++ to inform me if function
WITH RETURN TYPE does not return anything ?
If this is not bug why shouldn't we make
int n;
n =;
printf("%d",n);
to be legal code, compiler should simply assign whatever it wants. Right ?
Could anyone explain what for should missing return on typical C++ function
be useful at all ?
Not to mention probability that it has been forgotten by mistake.
-Wreturn-type should be set by default.
[Bug c++/55183] GCC 4.8 constexpr is too permissive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55183 --- Comment #5 from Stephen 2012-11-03 10:48:02 UTC --- Thanks for the information. The issue is indeed about use of reinterpret_cast in a constexpr method. The consensus, according to bug 55039, is that this should not be supported. There is also a lot of mention of 'the other PR'. Am I missing something, or is GCC being non-strict by still supporting this? Is there a stricter mode where this and other extensions are not available (for writing portable code)?
[Bug c++/55189] g++ compiler does not report missing return on function with return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55189 --- Comment #1 from Marc Glisse 2012-11-03 10:40:22 UTC --- (In reply to comment #0) > Compiled with MinGW port of g++, compiles without errors or warnings: It does warn if you ask it to: -Wall
[Bug c++/55189] New: g++ compiler does not report missing return on function with return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55189
Bug #: 55189
Summary: g++ compiler does not report missing return on
function with return type
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: meanar...@gmail.com
Compiled with MinGW port of g++, compiles without errors or warnings:
g++ bug.cpp -o bug.exe
Minimal sample bug.cpp:
#include
using namespace std;
class Example
{
protected:
int m_x;
public:
Example()
{
m_x = 0;
}
Example( const Example &ref )
{
m_x = ref.m_x;
}
~Example()
{
}
int get()
{
return m_x;
}
void set( int x )
{
m_x = x;
}
Example &operator =( Example ref )
{
m_x = ref.m_x;
return *this;
}
};
Example func( Example p )
{
Example m;
m.set( p.get() );
// ! COMPILER DOES NOT DETECT ABSENCE OF FUNCTION RETURN !
}
int main()
{
Example m;
m.set( 7 );
Example k;
k = func( m );
// ! CONSEQUENTLY RESULT IS RANDOM !
cout << k.get() << endl;
return 0;
}
[Bug tree-optimization/55188] New: [4.8 regression] FAIL: gcc.dg/pr19105.c scan-tree-dump-times reassoc1 "Optimizing range tests v_[0-9]*.D. -.2, 2. and -.3, 4.[\n\r]* into" 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55188 Bug #: 55188 Summary: [4.8 regression] FAIL: gcc.dg/pr19105.c scan-tree-dump-times reassoc1 "Optimizing range tests v_[0-9]*.D. -.2, 2. and -.3, 4.[\n\r]* into" 1 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: sch...@linux-m68k.org CC: ja...@gcc.gnu.org Target: m68k-*-* $ grep Optimizing pr19105.c.081t.reassoc1 Optimizing range tests v_3(D) -[2, 2] and -[3, 3] and -[4, 4]
[Bug tree-optimization/55187] New: [4.8 regression] FAIL: gcc.dg/autopar/pr49960.c scan-tree-dump-times parloops "SUCCESS: may be parallelized" 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55187 Bug #: 55187 Summary: [4.8 regression] FAIL: gcc.dg/autopar/pr49960.c scan-tree-dump-times parloops "SUCCESS: may be parallelized" 0 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: sch...@linux-m68k.org CC: hubi...@gcc.gnu.org Target: m68k-*-* gcc.dg/autopar/pr49960.c fails since r192989.
