Re: LSDA unwind information is off by one (in __gcc_personality_v0)
On 10/21/2016 12:08 AM, Eric Botcazou wrote: We don't call _Unwind_GetIPInfo from __gcc_personality_v0 because HAVE_GETIPINFO is not defined. This happens only when using the system unwinder on ia64, if I'm not mistaken. Disassembly shows that the code is not compiled in and not part of libgcc_s.so.1, although _Unwind_GetIPInfo itself has been defined. Then that's the bug, the C++ and Ada personality rountines call it. Thanks, I did not realize we had so many different implementations. Florian
Re: LSDA unwind information is off by one (in __gcc_personality_v0)
On 10/20/2016 10:06 PM, Jim Wilson wrote: But I also see that while HAVE_GETIPINFO appears to be set by configure, it is apparently not being used when building unwind-c.o. I see that HAVE_GETIPINFO is set in the libgcc/auto-target.h file, but this file is not included by unwind-c.c. I only see includes of this in libgcc/config/i386/cpuinfo.c and libgcc/config/sol2/gmon.c. I don't know offhand how auto-target.h is supposed to work, but it appears that it needs to be included in the unwind files built as part of libgcc. This is maybe a bug accidentally caused when libgcc was moved out of the gcc dir and into its own top level dir. I think this warrants a gcc bug report. Well-spotted, thanks. I filed PR78064 and have tested a patch. Florian
GCC 7.0.0 Status Report (2016-10-21)
Status == Trunk which will eventually become GCC 7 is still in Stage 1 but its end is near and we are planning to transition into Stage 3 starting Nov 13th end of day time zone of your choice. This means it is time to get things you want to have in GCC 7 finalized and reviewed. As usual there may be exceptions to late reviewed features but don't count on that. Likewise target specific features can sneak in during Stage 3 if maintainers ok them. Quality Data Priority # Change from last report --- --- P14+ 1 P2 117+ 27 P3 192+ 174 P4 109+ 9 P5 29- 1 --- --- Total P1-P3 313+ 202 Total 451+ 210 Previous Report === https://gcc.gnu.org/ml/gcc/2016-04/msg00106.html
Re: glibc test tst-thread_local1.cc fails to compile with latest GCC
On 19 October 2016 at 18:45, Ellcey, Steve wrote:
> I have built the latest glibc sources with a ToT GCC and am trying to run the
> glibc testsuite now. I ran into a couple of
> new warnings that I fixed (locally) and am now looking at
> nptl/tst-thread_local1.cc which dies with:
>
> tst-thread_local1.cc:172:7: error: ‘thread’ is not a member of ‘std’
>std::thread thr{[func] {func (nullptr);}};
>
> Does anyone know what is going on here? If I compile a small test program:
>
> #include
> int main(int, char **){
> std::thread tt;
> }
>
> With G++ 5.4 (using -std=c++11) this test program compiles. but with ToT GCC,
> it dies with:
>
> g++ -std=c++11 thread.cc -lpthread -o x
> thread.cc: In function ‘int main(int, char**)’:
> thread.cc:5:5: error: ‘thread’ is not a member of ‘std’
> std::thread tt;
> ^~~
> thread.cc:5:5: note: suggested alternative: ‘fread’
> std::thread tt;
> ^~~
> fread
>
>
> Is there some C++ standard change that I am not aware of or some other header
> file I need to include?
No, what probably happened is GCC didn't detect a usable Pthreads
implementation and so doesn't define std::thread. The header
uses this condition around the definition of std::thread:
#if defined(_GLIBCXX_HAS_GTHREADS) && defined(_GLIBCXX_USE_C99_STDINT_TR1)
Re: glibc test tst-thread_local1.cc fails to compile with latest GCC
On Fri, 2016-10-21 at 17:03 +0100, Jonathan Wakely wrote: > > > Is there some C++ standard change that I am not aware of or some > > other header file I need to include? > No, what probably happened is GCC didn't detect a usable Pthreads > implementation and so doesn't define std::thread. The header > uses this condition around the definition of std::thread: > > #if defined(_GLIBCXX_HAS_GTHREADS) && > defined(_GLIBCXX_USE_C99_STDINT_TR1) Yes, I finally realized I had built a GCC with '--enable-threads=no' and was using that GCC to build GLIBC. Once I rebuilt GCC with threads I could build GLIBC and not get this error. Steve Ellcey
I see this maybe related to PR71375 ?
After a build of trunk this morning: f951: internal compiler error: in altivec_init_builtins, at config/rs6000/rs6000.c:17547 0x10da4df3 altivec_init_builtins ../../trunk/gcc/config/rs6000/rs6000.c:17547 0x10da4df3 rs6000_init_builtins ../../trunk/gcc/config/rs6000/rs6000.c:16823 0x102c8797 gfc_init_builtin_functions ../../trunk/gcc/fortran/f95-lang.c:1244 0x102cb5f7 gfc_create_decls ../../trunk/gcc/fortran/f95-lang.c:181 0x102cb5f7 gfc_be_parse_file ../../trunk/gcc/fortran/f95-lang.c:197 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. On Using built-in specs. COLLECT_GCC=gfc COLLECT_LTO_WRAPPER=/home/jerryd/gcc/usr/libexec/gcc/powerpc64le-unknown-linux-gnu/7.0.0/lto-wrapper Target: powerpc64le-unknown-linux-gnu Configured with: ../trunk/configure --prefix=/home/jerryd/gcc/usr --enable-languages=c,c++,fortran --disable-libmudflap --enable-libgomp --disable-bootstrap Thread model: posix gcc version 7.0.0 20161021 (experimental) (GCC) On gcc112 , compile farm, Fedora release 21 (Twenty One) Jerry
Re: I see this maybe related to PR71375 ?
This is PR 78056. - David On Fri, Oct 21, 2016 at 3:41 PM, Jerry DeLisle wrote: > After a build of trunk this morning: > > f951: internal compiler error: in altivec_init_builtins, at > config/rs6000/rs6000.c:17547 > 0x10da4df3 altivec_init_builtins > ../../trunk/gcc/config/rs6000/rs6000.c:17547 > 0x10da4df3 rs6000_init_builtins > ../../trunk/gcc/config/rs6000/rs6000.c:16823 > 0x102c8797 gfc_init_builtin_functions > ../../trunk/gcc/fortran/f95-lang.c:1244 > 0x102cb5f7 gfc_create_decls > ../../trunk/gcc/fortran/f95-lang.c:181 > 0x102cb5f7 gfc_be_parse_file > ../../trunk/gcc/fortran/f95-lang.c:197 > 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. > > On > > Using built-in specs. > COLLECT_GCC=gfc > COLLECT_LTO_WRAPPER=/home/jerryd/gcc/usr/libexec/gcc/powerpc64le-unknown-linux-gnu/7.0.0/lto-wrapper > Target: powerpc64le-unknown-linux-gnu > Configured with: ../trunk/configure --prefix=/home/jerryd/gcc/usr > --enable-languages=c,c++,fortran --disable-libmudflap --enable-libgomp > --disable-bootstrap > Thread model: posix > gcc version 7.0.0 20161021 (experimental) (GCC) > > > On gcc112 , compile farm, Fedora release 21 (Twenty One) > > Jerry >
Copyright assignment
Hello, I would like to contribute GCC and Binutils ports for PRU [1]. I think "assigment for all future changes" is suitable for me. Can I get the copyright assignment forms? Regards, Dimitar [1] https://github.com/dinuxbg/gnupru
Website bị mất đi từ khóa gg...
Chào bạn gcv, mình thấy website của bạn đang bị mất đi khá nhiều từ khóa trên google Đó là vì khách truy cập vào website của bạn nhưng đã thoát khỏi trang web quá nhanh Bạn có thể sử dụng hộp chat của uhchat .net gắn vào trang web để câu giờ cho họ ở lại để chat với bạn thay vì
