[Bug libstdc++/52540] std::use_facet throws bad_cast when compiled with _GLIBCXX_DEBUG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52540 --- Comment #9 from Paolo Carlini 2012-03-11 11:20:40 UTC --- Then this is a very old issue, isn't it? Why nobody noticed it before? To be clear, in debug-mode we don't use extern templates only for basic_string (because _GLIBCXX_EXTERN_TEMPLATE becomes -1 when _GLIBCXX_DEBUG is defined), all the other facilities remain the same still use extern tamplate. This is in order to enable debug-mode checks also at -O0 for basic_string. Now, I don't see why a few less extern template can make a difference on mingw in terms of correctness of use_facet or anything else, but if that's really the case due to fundamental limitations somehwhere, we can trade it for the -O0 basic_string checks on the affected systems, I have no problems with that (note that, AFAICS, the problem will not go away with a new C++11 conforming string class, unless we decide to not export from the .so parts of basic_string)
[Bug driver/52556] New: Ability to change GLIBC_DYNAMIC_LINKER
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52556 Bug #: 52556 Summary: Ability to change GLIBC_DYNAMIC_LINKER Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: driver AssignedTo: unassig...@gcc.gnu.org ReportedBy: christer.solsko...@gmail.com I would love to be able to change GLIBC_DYNAMIC_LINKER to something other than default without changing the source code. This is useful if you want to create a completly standalone toolchain with binutils, gcc and some kind of libc.
[Bug driver/52556] Ability to change GLIBC_DYNAMIC_LINKER
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52556 --- Comment #1 from Christer Solskogen 2012-03-11 12:54:45 UTC --- I see now that the google gcc branch is having this kind of ability. Any plans of integrating them?
[Bug target/51244] SH Target: Inefficient conditional branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244 --- Comment #32 from Oleg Endo 2012-03-11 13:18:12 UTC --- Author: olegendo Date: Sun Mar 11 13:18:08 2012 New Revision: 185192 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185192 Log: PR target/51244 * config/sh/sh.md (movnegt): Expand into respective insns immediately. Use movrt_negc instead of negc pattern for non-SH2A. (*movnegt): Remove. (*movrt_negc, *negnegt, *movtt, *movt_qi): New insns and splits. PR target/51244 * gcc.target/sh/pr51244-1.c: Fix thinkos. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.md trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/sh/pr51244-1.c
[Bug driver/52556] Ability to change GLIBC_DYNAMIC_LINKER
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52556 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek 2012-03-11 14:14:28 UTC --- Just use -Wl,-dynamic-linker=/whatever/ld.so or you could use --with-specs configure option.
[Bug driver/52556] Ability to change GLIBC_DYNAMIC_LINKER
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52556 --- Comment #3 from Christer Solskogen 2012-03-11 15:50:57 UTC --- I could, but is not a sexy(*) as --with-runtime-root-prefix :-) *) http://patchwork.ozlabs.org/patch/80538/
[Bug libfortran/52537] slow trim function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52537 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-03-11 Ever Confirmed|0 |1
[Bug libfortran/52537] slow trim function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52537
--- Comment #3 from Hossein Talebi 2012-03-11
17:27:42 UTC ---
Hello,
Hummm, a self contained example... That will be possible when I go back to the
office. I can also check it myself with a simpler example. For now, maybe you
can figure out something from this subroutine. I can probably write this
subroutine in another way to make it faster. But, the question still is, why
intel does the same thing much faster.
!==
subroutine
femmesh_input_elements(this,funit,nelem,max_connectivity,fname,reflag,element_format)
!attention: here the Proc0 reads and distributes to other
! procs. also, the profiling is done here partially
! for the number of element and so on. The format of saving
! element connectivities is done according to METIS to make
! it easier to distribute the elements.
use strings
!--- INOUT variables--
class(ty_femmesh) :: this
type(ty_element_format) :: element_format
integer,intent(in) :: funit
character(*) :: fname, reflag
integer :: nelem,max_connectivity, linenum
integer :: j,ferror, ios,i
character (len=1200) :: st_input
integer :: maxc,funit2, buf_siz,iprc, ierror
integer, allocatable :: ELEMENTS_buf(:,:)
integer :: I50(0:50)
character(1200) :: pcommand
integer mstatus(MPI_STATUS_SIZE), tag, G_elid, elid, ipr, eltab,nn , pEidf,
pEconnf,pEmatidf
funit2=funit
linenum=0; ferror=0; eltab=0
this%max_connect=element_format%max_connectivity
this%max_Eltab=MIN_TABS+this%max_connect
pEidf=element_format%pEidf
pEconnf=element_format%pEconnf
pEmatidf=element_format%pEmatidf
! distribute the initial mesh to the processors so every processor knows
! what element it will get. The last element gets the remaining of the elements
+ its share
this%numElements= int( nelem / this%femcomm%nprocs)
if (this%femcomm%me == this%femcomm%nprocs-1) then
if (this%femcomm%me == this%femcomm%nprocs-1)
this%numElements=this%numElements+ mod(nelem,this%femcomm%nprocs)
endif
this%femcomm%elemdist(1)=1
!make elemdist and numEl_pp
do i=1, this%femcomm%nprocs
this%femcomm%elemdist(i+1) =this%femcomm%elemdist(i)+ int( nelem /
this%femcomm%nprocs)
this%femcomm%numEl_pp(i)=int( nelem / this%femcomm%nprocs)
enddo
this%femcomm%elemdist(this%femcomm%nprocs+1) =
this%femcomm%elemdist(this%femcomm%nprocs+1)+ mod(nelem,this%femcomm%nprocs)
this%femcomm%numEl_pp(this%femcomm%nprocs) =
this%femcomm%numEl_pp(this%femcomm%nprocs)+ mod(nelem,this%femcomm%nprocs)
!preparing the buffer to send and recieve elements
buf_siz=this%femcomm%numEl_pp(this%femcomm%nprocs) +1
eltab=2+max_connectivity
Call allocate_I2d(this%Elements_input,eltab,buf_siz)
Call allocate_I2d(ELEMENTS_buf,eltab,buf_siz)
Call allocate_I2d(this%Elements, this%max_Eltab ,this%numElements)
Call MPI_BARRIER(this%femcomm%femworld,ierror)
tag = 1; G_elid=0 ;I50=0
if (this%femcomm%me .eq. 0) then
if (trim(element_format%fname) /= '') then
if (element_format%reflag=='txt') then
funit2=openfile_txt(element_format%fname)
else
Call this%error%universe_one('femmesh_input_elements: I am not
able to read this type of element file')
endif
endif
ELEMENTS_buf=0
do ipr=0, this%femcomm%nprocs -1
j=0;
do
read (funit2,"(A200)",iostat=ferror) st_input
if (ferror < 0) then
call this%error%universe_one("femmesh_input_elements:
unexpected end of the file")
endif
call compact(st_input)
if (trim(st_input)=='' .or. st_input(1:1)=='#') then
cycle
endif
j=j+1
linenum=linenum+1
read (st_input,*,IOSTAT=ios) I50(1:50)
I50(0)=1 !set the zero index as 1, which sets all the unset values
1
elid=I50(1)
G_elid=G_elid+1
if (G_elid /=elid) then
print *,st_input
call this%error%universe_one("femmesh_input_elements: Bad
element numbering or number "// &
" of elements or element format")
endif
!ELEMENTS_buf(1:eltab,j)=I50(1:eltab)
ELEMENTS_buf(1,j)=I50(pEidf)
ELEMENTS_buf(2,j)=I50(pEmatidf)
ELEMENTS_buf(3:3+max_connectivity-1
,j)=I50(pEconnf:pEconnf+max_connectivity-1)
I50=0
if (j >= this%femcomm%numEl_pp(ipr+1)) exit
enddo
if (ipr ==0) then
this%Elements_input=ELEMENTS_buf
else
call MPI_SEND(ELEMENTS_buf, eltab*buf_siz, MPI_INTEGER, ipr, tag,
this%femcomm%femworld, ierror)
endif
enddo
else
call MPI_RECV(ELEMENTS_buf, eltab*buf_siz, MP
[Bug go/52557] New: Timex undefined on arm-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52557
Bug #: 52557
Summary: Timex undefined on arm-linux-gnueabi
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
AssignedTo: i...@airs.com
ReportedBy: d...@gcc.gnu.org
libgo r185183 fails to build on arm-linux-gnueabi,
libcalls.go:1662:22: error: use of undefined type 'Timex'
make[6]: *** [syscall/syscall.lo] Error 1
build/arm-linux-gnueabi/libgo/gen-sysinfo.go has:
// type _timex struct { modes uint32; offset int32; freq int32; maxerror int32;
esterror int32; status int32; constant int32; precision int32; tolerance int32;
time _timeval; tick int32; ppsfreq int32; jitter int32; shift int32; stabil
int32; jitcnt int32; calcnt int32; errcnt int32; stbcnt int32; tai int32;
Godump_0 INVALID-bit-field; Godump_1 INVALID-bit-field; Godump_2
INVALID-bit-field; Godump_3 INVALID-bit-field; Godump_4 INVALID-bit-field;
Godump_5 INVALID-bit-field; Godump_6 INVALID-bit-field; Godump_7
INVALID-bit-field; Godump_8 INVALID-bit-field; Godump_9 INVALID-bit-field;
Godump_10 INVALID-bit-field; }
the invalid fields correspond to bits/timex.h in the timex struct:
int tai; /* TAI offset (ro) */
/* ??? */
int :32; int :32; int :32; int :32;
int :32; int :32; int :32; int :32;
int :32; int :32; int :32;
[Bug libstdc++/52540] std::use_facet throws bad_cast when compiled with _GLIBCXX_DEBUG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52540 --- Comment #10 from Kai Tietz 2012-03-11 18:35:59 UTC --- (In reply to comment #9) > Then this is a very old issue, isn't it? Why nobody noticed it before? To be > clear, in debug-mode we don't use extern templates only for basic_string > (because _GLIBCXX_EXTERN_TEMPLATE becomes -1 when _GLIBCXX_DEBUG is defined), > all the other facilities remain the same still use extern tamplate. This is in > order to enable debug-mode checks also at -O0 for basic_string. Now, I don't > see why a few less extern template can make a difference on mingw in terms of > correctness of use_facet or anything else, but if that's really the case due > to > fundamental limitations somehwhere, we can trade it for the -O0 basic_string > checks on the affected systems, I have no problems with that (note that, > AFAICS, the problem will not go away with a new C++11 conforming string class, > unless we decide to not export from the .so parts of basic_string) I tested it by making sure that _GLIBCXX_EXTERN_TEMPLATE is defined to 1 even for _GLIBCXX_DEBUG (and PROFILE) mode. Indeed the test passes now without issue. The underlying issue here seems to be that DLL-code and non-external code aren't sharing all underlying data. For ELF this gets resolved, as ELF doesn't have final link for .so, but for PE it gets finally linked on DLL generation.
[Bug target/52530] [4.8 regression] Many 64-bit execution failures on Solaris 10/11 with Sun as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52530 --- Comment #10 from uros at gcc dot gnu.org 2012-03-11 19:48:02 UTC --- Author: uros Date: Sun Mar 11 19:47:58 2012 New Revision: 185201 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185201 Log: PR target/52530 * gcc.dg/torture/pr52530.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr52530.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/52540] std::use_facet throws bad_cast when compiled with _GLIBCXX_DEBUG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52540 --- Comment #11 from Pawel Sikora 2012-03-11 19:49:41 UTC --- (In reply to comment #9) > Then this is a very old issue, isn't it? Why nobody noticed it before? To be > clear, in debug-mode we don't use extern templates only for basic_string > (because _GLIBCXX_EXTERN_TEMPLATE becomes -1 when _GLIBCXX_DEBUG is defined), > all the other facilities remain the same still use extern tamplate. This is in > order to enable debug-mode checks also at -O0 for basic_string. Now, I don't > see why a few less extern template can make a difference on mingw in terms of > correctness of use_facet or anything else, but if that's really the case due > to > fundamental limitations somehwhere, we can trade it for the -O0 basic_string > checks on the affected systems, I have no problems with that (note that, > AFAICS, the problem will not go away with a new C++11 conforming string class, > unless we decide to not export from the .so parts of basic_string) i'm not sure the problem is in std::string details. in the debug-mode the use_facet is no more extern template and instantiates in client code, especially the static facet's field like std::locale::id. is this 'id' and other static details correctly initialized in (non-extern-template) debug-mode?
[Bug go/52557] Timex undefined on arm-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52557
--- Comment #1 from Matthias Klose 2012-03-11
20:35:42 UTC ---
with the following hack, I'm able to build on arm, and run the tests.
--- libgo/mksysinfo.sh~ 2012-03-11 00:36:59.0 +
+++ libgo/mksysinfo.sh 2012-03-11 19:17:15.0 +
@@ -137,6 +137,9 @@
${CC} -fdump-go-spec=gen-sysinfo.go -std=gnu99 -S -o sysinfo.s sysinfo.c
+# ARM
+sed -i '/type _timex/s/INVALID-bit-field/int32/g;/type _timex/s,^// ,,'
gen-sysinfo.go
+
echo 'package syscall' > ${OUT}
echo 'import "unsafe"' >> ${OUT}
echo 'type _ unsafe.Pointer' >> ${OUT}
$ grep -v ^PASS libgo.sum
Test Run By doko on Sun Mar 11 19:35:35 UTC 2012
Native configuration is arm-unknown-linux-gnueabi
=== libgo tests ===
Schedule of variations:
unix
Running target unix
Running ../../../src/libgo/libgo.exp ...
FAIL: fmt
FAIL: log
FAIL: reflect
FAIL: sync
FAIL: time
FAIL: archive/zip
FAIL: debug/dwarf
FAIL: encoding/gob
FAIL: encoding/json
FAIL: html/template
FAIL: go/printer
FAIL: math/big
FAIL: net/http
FAIL: net/rpc
FAIL: old/regexp
FAIL: old/template
FAIL: text/template
FAIL: text/template/parse
=== libgo Summary ===
# of expected passes105
# of unexpected failures18
[Bug go/52218] [4.7/4.8 Regression] libgo ftbfs on arm-linux-gnueabi (unknown case for SETCONTEXT_CLOBBERS_TLS)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52218 Matthias Klose changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #7 from Matthias Klose 2012-03-11 20:39:20 UTC --- nothing to fix in libgo
[Bug target/52474] Regression: AVR-GCC: arithmetics produce completely wrong result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52474 Georg-Johann Lay changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |WAITING Last reconfirmed||2012-03-11 CC||gjl at gcc dot gnu.org Component|c |target Ever Confirmed|0 |1 Severity|critical|normal --- Comment #2 from Georg-Johann Lay 2012-03-11 22:21:36 UTC --- There is no compileable test case. Please add a test case following the bug reportig instructions in http://gcc.gnu.org/bugs/#need Moreover, notice that avr-gcc 4.5 does not support XMEGA cores. Thus, either work out a test case that can be reproduced on a device that is supported by 4.5, or report the bug to your distributor that added XMEGA support to his private distrubution.
[Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-03-11 CC||gjl at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Georg-Johann Lay 2012-03-11 22:30:17 UTC --- Would you please add a test case following the instructions in http://gcc.gnu.org/bugs/#need BTW, this appreas to be a frame pointer adjustment for a device with 8-bit SP. Allocating 2050 bytes of stack space on a device with 8-bit SP is not going to produce a reasonable executable, anyway.
[Bug c++/51239] ICE with variadic template alias
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51239 Dodji Seketeli changed: What|Removed |Added Status|ASSIGNED|SUSPENDED --- Comment #3 from Dodji Seketeli 2012-03-11 22:32:48 UTC --- There were more patches for this at http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00728.html and http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00729.html. I'd need to address the comments raised by the first patch, at least. But at the same time, it turned out that we are hitting DR 1430 (http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_active.html#1430). So I am suspending this bug for now because depending on the resolution of DR 1430 there, we might have to take a totally different direction.
[Bug fortran/38199] missed optimization: I/O performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199 Steven Bosscher changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #14 from Steven Bosscher 2012-03-11 22:41:25 UTC --- Jerry, are you still working on this?
[Bug middle-end/52450] FAIL: gcc.dg/torture/pr52402.c at -O1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52450 John David Anglin changed: What|Removed |Added Component|target |middle-end --- Comment #6 from John David Anglin 2012-03-11 23:59:26 UTC --- Test is xfailed on trunk. Please note that this is an optimization bug as the test doesn't fail at -O0. While struct T is packed, I don't believe that this implies that its address is misaligned. i is the first field in T. Thus, its address shouldn't be misaligned on a big endian target. It would seem that the problem is the copy at the caller site is being optimized away.
[Bug ada/52110] s-osinte.ads:447:09: "clockid_t" conflicts with declaration at line 194
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52110 --- Comment #7 from John David Anglin 2012-03-12 00:04:35 UTC --- Build is successful with pragma Volatile in lieu of the Atomic. However, test results appear similar: http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg01197.html
[Bug tree-optimization/46728] GCC does not generate fmadd for pow (x, 0.75)+y on powerpc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46728 --- Comment #15 from David Fang 2012-03-12 02:26:40 UTC --- I see this test failing on powerpc-apple-darwin8 (32b G4, ppc7400): http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg01296.html Is this specific to 64b, or should it also work for 32b ppc?
[Bug libitm/52482] libitm INVALID MNEMONIC in .S (powerpc asm)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52482 --- Comment #5 from David Fang 2012-03-12 02:28:49 UTC --- Reran using entire set of odcctools-20090808 (passed through configure), looks like same failures: http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg01296.html
[Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488 --- Comment #2 from Ralf Corsepius 2012-03-12 06:21:42 UTC --- Created attachment 26876 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26876 *.i of the file triggering the ICE This *.i was created from today's (ca. 2012-03-12 05:00 UTC) gcc from gcc-4_7-branch ../gcc-4.7.0-RC-20120302/configure --prefix=/opt/rtems-4.11 --bindir=/opt/rtems-4.11/bin --exec_prefix=/opt/rtems-4.11 --includedir=/opt/rtems-4.11/include --libdir=/opt/rtems-4.11/lib --libexecdir=/opt/rtems-4.11/libexec --mandir=/opt/rtems-4.11/share/man --infodir=/opt/rtems-4.11/share/info --datadir=/opt/rtems-4.11/share --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=avr-rtems4.11 --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --verbose --with-newlib --with-system-zlib --disable-nls --without-included-gettext --disable-win32-registry --enable-version-specific-runtime-libs --enable-threads --disable-lto --disable-plugin --enable-newlib-io-c99-formats --enable-newlib-iconv --enable-languages=c ... make ... /builddir/build/BUILD/rtems-4.11-avr-rtems4.11-gcc-4.7.0/build/./gcc/xgcc -B/builddir/build/BUILD/rtems-4.11-avr-rtems4.11-gcc-4.7.0/build/./gcc/ -nostdinc -B/builddir/build/BUILD/rtems-4.11-avr-rtems4.11-gcc-4.7.0/build/avr-rtems4.11/tiny-stack/newlib/ -isystem /builddir/build/BUILD/rtems-4.11-avr-rtems4.11-gcc-4.7.0/build/avr-rtems4.11/tiny-stack/newlib/targ-include -isystem /builddir/build/BUILD/rtems-4.11-avr-rtems4.11-gcc-4.7.0/gcc-4.7.0-RC-20120302/newlib/libc/include -B/opt/rtems-4.11/avr-rtems4.11/bin/ -B/opt/rtems-4.11/avr-rtems4.11/lib/ -isystem /opt/rtems-4.11/avr-rtems4.11/include -isystem /opt/rtems-4.11/avr-rtems4.11/sys-include -mmcu=at90s2313 -DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\" -DPACKAGE_VERSION=\"1.20.0\" -DPACKAGE_STRING=\"newlib\ 1.20.0\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I. -I../../../../../../gcc-4.7.0-RC-20120302/newlib/libc/posix -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 -fno-builtin -D_GNU_SOURCE -g -O2 -c -o lib_a-glob.o `test -f 'glob.c' || echo '../../../../../../gcc-4.7.0-RC-20120302/newlib/libc/posix/'`glob.c ../../../../../../gcc-4.7.0-RC-20120302/newlib/libc/posix/glob.c: In function 'glob': ../../../../../../gcc-4.7.0-RC-20120302/newlib/libc/posix/glob.c:206:1: error: unrecognizable insn: (insn/f 305 304 306 2 (set (reg:QI 28 r28) (plus:QI (reg:QI 28 r28) (const_int -2050 [0xf7fe]))) ../../../../../../gcc-4.7.0-RC-20120302/newlib/libc/posix/glob.c:160 -1 (expr_list:REG_CFA_ADJUST_CFA (set (reg/f:HI 28 r28) (plus:HI (reg/f:HI 28 r28) (const_int -2050 [0xf7fe]))) (nil))) ../../../../../../gcc-4.7.0-RC-20120302/newlib/libc/posix/glob.c:206:1: internal compiler error: in extract_insn, at recog.c:2123 One-tree-style bootstrap (comprising newlib), using avr-rtems4.11-binutils-2.22, newlib-1.20 + rtems patches (glob.c is part of newlib) on fedora-16-x86_64.
[Bug ada/52110] s-osinte.ads:447:09: "clockid_t" conflicts with declaration at line 194
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52110 --- Comment #8 from Eric Botcazou 2012-03-12 06:46:41 UTC --- > Build is successful with pragma Volatile in lieu of the Atomic. > However, test results appear similar: > http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg01197.html OK, let's use pragma Volatile anyway, it's the closest approximation we have.
