Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

What about removing the _gcov_fork object file from the list of object files in Makefile.in (Named LIBGCOV_INTERFACE last I remember) if the target doesn't support fork? Seems cleaner in my opinion. best regards, Julian

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

* LIU Hao via Gcc: > 在 2023/12/8 21:59, Florian Weimer via Gcc 写道: >>[PATCH] libgcov: Call __builtin_fork instead of fork >> >> > > May I ask why it's not something like this? > > Even though there may be p

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

在 2023/12/8 21:59, Florian Weimer via Gcc 写道: [PATCH] libgcov: Call __builtin_fork instead of fork May I ask why it's not something like this? Even though there may be people who define `fork()` in globa

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

* Mark Wielaard: > BTW. The gcc-fedora-mingw buildbot has been broken because of this > issue for the last week: > > https://builder.sourceware.org/buildbot/#/builders/gcc-fedora-mingw > ../../../gcc/libgcc/libgcov-interface.c: In function '__gcov_fork': > ../../../gcc/libgcc/libgcov-interface.c:1

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

I think the most reasonable thing to do is to remove _gcov_fork from LIBGCOV_INTERFACE in libgcc's Makefile.in when the target is Windows. best regards, Julian

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

licit declaration of function ‘fork’ > [-Wimplicit-function-declaration] > (by default in C99+). > > So, as has been discussed earlier, either we should use __builtin_fork () > rather than fork (), or we need in configure to test for fork prototype and > if missing, prototype

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

need in configure to test for fork prototype and if missing, prototype it ourselves, or ensure _gcov_fork.o is not compiled on targets which don't have fork prototyped. Jakub

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

> On Dez 01 2023, Richard Biener via Gcc wrote: > > > Hmm, so why's it then referenced and not "GCed"? > > This has nothing to do with garbage collection. It's just the way > libgcc avoids having too many source files. It would be exactly the > same if every function were in its own file. THe

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

On Dez 01 2023, Richard Biener via Gcc wrote: > Hmm, so why's it then referenced and not "GCed"? This has nothing to do with garbage collection. It's just the way libgcc avoids having too many source files. It would be exactly the same if every function were in its own file. -- Andreas Schwab

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

在 2023/12/1 17:09, Richard Biener via Gcc 写道: Hmm, so why's it then referenced and not "GCed"? The classical "solution" is to make the reference weak via sth like extern typeof(fork) fork () __attribute__((weak)); There are issues about weak symbols on mingw targets

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

far as I understand it, mingw doesn't have fork and doesn't declare > > >> it in , so it's not clear to me how this has ever worked. I > > >> would expect a linker failure. Maybe that doesn't happen because the > > >> object containing a refere

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

On Fri, 1 Dec 2023, LIU Hao via Gcc wrote: > >> What's the best way to fix this? I expect it's going to impact other > >> targets (perhaps for different functions) because all of > >> libgcov-interface.c is built unconditionally. I don't think we run

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

er worked. I > >> would expect a linker failure. Maybe that doesn't happen because the > >> object containing a reference to fork is only ever pulled in if the > >> application calls the intercepted fork, which doesn't happen on mingw. > >> > >

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

ence to fork is only ever pulled in if the application calls the intercepted fork, which doesn't happen on mingw. That's correct. No program has been calling `fork()` in any way. What's the best way to fix this? I expect it's going to impact other targets (perhaps for dif

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

only ever pulled in if the >> application calls the intercepted fork, which doesn't happen on mingw. >> >> What's the best way to fix this? I expect it's going to impact other >> targets (perhaps for different functions) because all of >> libgcov-i

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

't happen on mingw. > > What's the best way to fix this? I expect it's going to impact other > targets (perhaps for different functions) because all of > libgcov-interface.c is built unconditionally. I don't think we run > configure for the target, so we can'

Re: libgcov, fork, and mingw (and other targets without the full POSIX set)

taining a reference to fork is only ever pulled in if the > application calls the intercepted fork, which doesn't happen on mingw. > > What's the best way to fix this? I expect it's going to impact other > targets (perhaps for different functions) because all of &

libgcov, fork, and mingw (and other targets without the full POSIX set)

e that doesn't happen because the object containing a reference to fork is only ever pulled in if the application calls the intercepted fork, which doesn't happen on mingw. What's the best way to fix this? I expect it's going to impact other targets (perhaps for diff

Linker removal of trampolines on Microsoft Windows targets

Hi all, Microsoft's Visual C++ compiler has the ability to remove trampolines generated by the linker (which ultimately calls __imp_SymbolName from the DLL import address table) when linking with code that is intended to be loaded from a DLL if link time optimization on their compiler was specifie

Re: Listing deprecated targets in changes.html

On Mon, 13 Sep 2021, Eric Gallager wrote: > Hi, I see that a number of targets are going to be deprecated for GCC 12: > - m32r{,le}-linux: > https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579265.html > - cr16: https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579280.h

Listing deprecated targets in changes.html

Hi, I see that a number of targets are going to be deprecated for GCC 12: - m32r{,le}-linux: https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579265.html - cr16: https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579280.html - m68k-openbsd: https://gcc.gnu.org/pipermail/gcc-patches

Re: TImode for BITS_PER_WORD=32 targets

shifts or rotates for more than double-word types. > (Multiple-word add and subtract appear to work fine, however.) > > What would be the best (least effort) way to implement this? > > I think I need shift, rotate, multiply, divide, and modulus, but there's > probably more. You

TImode for BITS_PER_WORD=32 targets

Hi all, I want amdgcn to be able to support int128 types, partly because they might come up in code offloaded from x86_64 code, and partly because libgomp now requires at least some support (amdgcn builds have been failing since yesterday). But, amdgcn has 32-bit registers, and therefore def

[RFC] Removing __dso_handle definition for targets where DSOs are not used

alize data by default. It is feasible that real applications can be written not requiring global data at all so this isn't just an artificial code size saving. When users of embedded targets approach GCC for the first time for target they don't like to see unnecessary functions and dat

Re: [RFC/RFA] Obsolete Cell Broadband Engine SPU targets

On 4/2/19 10:49 AM, Eric Gallager wrote: > On 4/2/19, Ulrich Weigand wrote: >> Hello, >> >> the spu-elf target in GCC supports generating code for the SPU processors >> of the Cell Broadband Engine; it has been part of upstream GCC since 2008. >> >> However, at this point I believe this target is

Re: [RFC/RFA] Obsolete Cell Broadband Engine SPU targets

PS3 supercomputer cluster... (I'd have to check to > make sure...) GCC has only ever supported Linux targets on Cell/B.E. I understand Sony has removed Linux support for PS3 a long time ago. (And in fact, I believe support for PS3 in general has run out this year.) Of course, there may be som

Re: [RFC/RFA] Obsolete Cell Broadband Engine SPU targets

ort untested/maintained, I'd therefore > propose to declare all SPU targets obsolete in GCC 9 and remove > the code with GCC 10. > > Any objections to this approach? > > Bye, > Ulrich > > > gcc/

Re: [RFC/RFA] Obsolete Cell Broadband Engine SPU targets

ystems I've been > using for this will go away. > > Rather than leave SPU support untested/maintained, I'd therefore > propose to declare all SPU targets obsolete in GCC 9 and remove > the code with GCC 10. > > Any objections to this approach? This is ok with me too.

Re: [RFC/RFA] Obsolete Cell Broadband Engine SPU targets

Thanks, Richi and Jeff! > * config.gcc: Mark spu* targets as deprecated/obsolete. I've now checked this in. I've also checked in the following patch to announce the change in htdocs. Bye, Ulrich Index: htdocs/gcc-9

Re: [RFC/RFA] Obsolete Cell Broadband Engine SPU targets

> using for this will go away. > > Rather than leave SPU support untested/maintained, I'd therefore > propose to declare all SPU targets obsolete in GCC 9 and remove > the code with GCC 10. > > Any objections to this approach? > > Bye, > Ulrich > > >

Re: [RFC/RFA] Obsolete Cell Broadband Engine SPU targets

he systems I've been >using for this will go away. > >Rather than leave SPU support untested/maintained, I'd therefore >propose to declare all SPU targets obsolete in GCC 9 and remove >the code with GCC 10. > >Any objections to this approach? Works for me. Richard.

[RFC/RFA] Obsolete Cell Broadband Engine SPU targets

therefore propose to declare all SPU targets obsolete in GCC 9 and remove the code with GCC 10. Any objections to this approach? Bye, Ulrich gcc/ChangeLog: * config.gcc: Mark spu* targets as deprecated/obsolete. Index: gcc/config.gcc ===

Re: __sync_-builtins cause undefined references on some sparc targets

; struct backtrace_state *state; #ifndef HAVE_SYNC_FUNCTIONS if (threaded) { error_callback (data, "backtrace library does not support threads", 0); return NULL; } #endif So, I doubt this works for RTEMS. I guess libgfortran needs an option to be a bit less verb

Re: __sync_-builtins cause undefined references on some sparc targets

> Is libbacktrace excluded from the build, or is it build but broken? Neither, it's presumably falls back to __atomic. No big deal in any case, since you'll presumably never use libbacktrace in practice. -- Eric Botcazou

RE: __sync_-builtins cause undefined references on some sparc targets

erences on some sparc targets > > > Is there an easy way to remove the libbacktrace dependency? > > Might something like that work?: > > https://patchwork.ozlabs.org/patch/553017/ > > Yes, even better, simply arrange for the __sync and __atomic support tests of > libback

Re: __sync_-builtins cause undefined references on some sparc targets

> Is there an easy way to remove the libbacktrace dependency? > Might something like that work?: https://patchwork.ozlabs.org/patch/553017/ Yes, even better, simply arrange for the __sync and __atomic support tests of libbacktrace to fail on your target, possibly by using the same trick as HPUX.

Re: __sync_-builtins cause undefined references on some sparc targets

On Montag, 27. Februar 2017 22:07:56 CET Eric Botcazou wrote: > > "This __sync_() stuff seems to be used in several places in GCC. So, > > changing libbacktrace is probably not enough. We need a general solution > > for the __sync_() builtins on RTEMS. I don't think GCC can be changed to > > emit _

Re: __sync_-builtins cause undefined references on some sparc targets

> "This __sync_() stuff seems to be used in several places in GCC. So, > changing libbacktrace is probably not enough. We need a general solution > for the __sync_() builtins on RTEMS. I don't think GCC can be changed to > emit __atomic_() calls for the __sync_() builtins (I would still try to > as

__sync_-builtins cause undefined references on some sparc targets

Hello, I compiled the gcc 6.3.0 for the leon2 processor for RTEMS (i.e. sparc-rtems4.12-*). When linking a fortran program for the leon2 processor I get undefined references for `__sync_bool_compare_and_swap_4' (see below). According to the discussion on the rtems mailinglist the __sync_*-operat

Re: Re: Make GCC emit ASM instructions in 'gcc/except.c' for i686 MinGW targets ?

> I'd probably create a new exception handling model and conditionalize > whatever code you need based on that. That would require copy-n-paste of tons of code... All this remains contingent on Microsoft's generosity because they don't provide APIs for SEH on x86, unlike on x64. So I have to reu

Re: Make GCC emit ASM instructions in 'gcc/except.c' for i686 MinGW targets ?

On 10/16/2016 08:58 PM, lhmouse wrote: Hi there, I come up with an idea about implementing stack unwinding for the i686-w64-mingw32 target using native Windows Structured Exception Handling (a.k.a SEH) for efficiency reasons. Unlike DWARF and SEH for x64, SEH for x86 is stack-based and works li

Make GCC emit ASM instructions in 'gcc/except.c' for i686 MinGW targets ?

Hi there, I come up with an idea about implementing stack unwinding for the i686-w64-mingw32 target using native Windows Structured Exception Handling (a.k.a SEH) for efficiency reasons. Unlike DWARF and SEH for x64, SEH for x86 is stack-based and works like the SJLJ exception model: The operatin

Contribute to GCC - the MCF thread model for MinGW targets

Hello GCC developers, I have implemented a gthread library for both the i686 and x86_64 MinGW targets, which supports all c++0x thread features required by . This library is experimental and stil lrequires testing. However Kai suggested I donate it to the FSF so it could be merged into the GCC

Re: Obsoleting Three RTEMS Targets

On 01/04/2016 02:01 PM, Joel Sherrill wrote: Hi It has come time for RTEMS to obsolete three targets: avr-rtems*, h8300-rtems*, and m32r-rtems* in gcc and binutils. They have been removed from the RTEMS master. Since we were dealing with more than one, I thought I would ask for advice on

Obsoleting Three RTEMS Targets

Hi It has come time for RTEMS to obsolete three targets: avr-rtems*, h8300-rtems*, and m32r-rtems* in gcc and binutils. They have been removed from the RTEMS master. Since we were dealing with more than one, I thought I would ask for advice on making sure I executed the process correctly

How to rewrite call targets (OpenACC bind clause)

Hi! I have tried a few things, and got things somewhat working, but I'm not satisfied with my results so far, so I'd like to ask for help. OpenACC specifics are not relevant to my question, which I'm thus formulating in a very generic way. (But find an illustrative example at the end of the emai

Re: Support for targets with widths other than 2^x (Power of 2)

On Thu, Oct 15, 2015 at 02:34:06PM +0200, Ramon Wirsch wrote: > The SpartanMC architecture poses a few additional difficulties as it > is 18 Bits wide. > Our investigations have shown that GCC is on principle capable of that > (it is working right now, although with several limitations). The main >

Support for targets with widths other than 2^x (Power of 2)

Hi, We here at the Computer Systems Group of the Technische Universität Darmstadt, Germany are working on an SoC-Kit called SpartanMC. We are currently using our own port of GCC to compile for it, but would be willing to get our target upstream and maintain it. The SpartanMC architecture poses a

Re: [ping] Re: proper name of i386/x86-64/etc targets

On Tue, Jan 20, 2015 at 11:43 AM, H.J. Lu wrote: > On Tue, Jan 20, 2015 at 11:38 AM, Sandra Loosemore > wrote: >> On 01/20/2015 12:21 PM, H.J. Lu wrote: >>> >>> On Tue, Jan 20, 2015 at 11:16 AM, Sandra Loosemore >>> wrote: Ummm, this seems like an inconsistent position. "32-bit x

Re: [ping] Re: proper name of i386/x86-64/etc targets

On Tue, Jan 20, 2015 at 11:38 AM, Sandra Loosemore wrote: > On 01/20/2015 12:21 PM, H.J. Lu wrote: >> >> On Tue, Jan 20, 2015 at 11:16 AM, Sandra Loosemore >> wrote: >>> >>> >>> Ummm, this seems like an inconsistent position. "32-bit x86" isn't even >>> a >>> new name; it's a restricting adjecti

Re: [ping] Re: proper name of i386/x86-64/etc targets

On 01/20/2015 12:21 PM, H.J. Lu wrote: On Tue, Jan 20, 2015 at 11:16 AM, Sandra Loosemore wrote: Ummm, this seems like an inconsistent position. "32-bit x86" isn't even a new name; it's a restricting adjective "32-bit" on the existing name "x86". But "x86-32" isn't an existing real name for a

Re: [ping] Re: proper name of i386/x86-64/etc targets

On Tue, Jan 20, 2015 at 11:16 AM, Sandra Loosemore wrote: > On 01/20/2015 11:40 AM, H.J. Lu wrote: >> >> On Tue, Jan 20, 2015 at 10:27 AM, Sandra Loosemore >> wrote: >>> >>> Since there seems to be arguments against using both "IA-32" and "i386" >>> for >>> the 32-bit x86 architecture, how about,

Re: [ping] Re: proper name of i386/x86-64/etc targets

On 01/20/2015 11:40 AM, H.J. Lu wrote: On Tue, Jan 20, 2015 at 10:27 AM, Sandra Loosemore wrote: Since there seems to be arguments against using both "IA-32" and "i386" for the 32-bit x86 architecture, how about, uh, "32-bit x86"? With the other names in parentheses where appropriate? I think

Re: [ping] Re: proper name of i386/x86-64/etc targets

On 1/20/2015 1:02 PM, H.J. Lu wrote: > On Tue, Jan 20, 2015 at 10:51 AM, Eric Botcazou wrote: >>> Ping? Any thoughts? >> x86 for the family and x86-32/x86-64 for the 2 architectures? >> > Works for me. > > Sounds good to me. You can always explain the terms and their relationship to others in a

Re: [ping] Re: proper name of i386/x86-64/etc targets

On Tue, Jan 20, 2015 at 10:51 AM, Eric Botcazou wrote: >> Ping? Any thoughts? > > x86 for the family and x86-32/x86-64 for the 2 architectures? > Works for me. -- H.J.

Re: [ping] Re: proper name of i386/x86-64/etc targets

> Ping? Any thoughts? x86 for the family and x86-32/x86-64 for the 2 architectures? -- Eric Botcazou

Re: [ping] Re: proper name of i386/x86-64/etc targets

On Tue, Jan 20, 2015 at 10:27 AM, Sandra Loosemore wrote: > On 01/20/2015 08:11 AM, Michael Matz wrote: >> >> Hi, >> >> On Tue, 20 Jan 2015, Uros Bizjak wrote: >> At least, IA-32 is clear, although IA-64 may be confusing :-). FWIW, i386 is also vendor specific. >>> >>> >>> Wikipedia agr

Re: [ping] Re: proper name of i386/x86-64/etc targets

On 01/20/2015 08:11 AM, Michael Matz wrote: Hi, On Tue, 20 Jan 2015, Uros Bizjak wrote: At least, IA-32 is clear, although IA-64 may be confusing :-). FWIW, i386 is also vendor specific. Wikipedia agrees [1]: I wouldn't use a wikipedia article that only cites sources from after 2008 (and

Re: [ping] Re: proper name of i386/x86-64/etc targets

Hi, On Tue, 20 Jan 2015, Uros Bizjak wrote: > > At least, IA-32 is clear, although IA-64 may be confusing :-). FWIW, > > i386 is also vendor specific. > > Wikipedia agrees [1]: I wouldn't use a wikipedia article that only cites sources from after 2008 (and most of them actually after the aft

Re: [ping] Re: proper name of i386/x86-64/etc targets

On Tue, Jan 20, 2015 at 3:23 PM, H.J. Lu wrote: >>> > ia32 is confusing because ia64 (a well known term) sounds related but >>> > can't be farther away from it, and it's also vendor specific. Our >>> > traditional i386 seems better to me (although it has its own problems, >>> > but I'm not aware

Re: [ping] Re: proper name of i386/x86-64/etc targets

On Tue, Jan 20, 2015 at 6:14 AM, Michael Matz wrote: > Hi, > > On Tue, 20 Jan 2015, H.J. Lu wrote: > >> > ia32 is confusing because ia64 (a well known term) sounds related but >> > can't be farther away from it, and it's also vendor specific. Our >> > traditional i386 seems better to me (although

Re: [ping] Re: proper name of i386/x86-64/etc targets

Hi, On Tue, 20 Jan 2015, H.J. Lu wrote: > > ia32 is confusing because ia64 (a well known term) sounds related but > > can't be farther away from it, and it's also vendor specific. Our > > traditional i386 seems better to me (although it has its own problems, > > but I'm not aware of any bette

Re: [ping] Re: proper name of i386/x86-64/etc targets

On Tue, Jan 20, 2015 at 6:07 AM, Michael Matz wrote: > Hi, > > On Mon, 19 Jan 2015, Sandra Loosemore wrote: > >> > I'd be happy to work on a patch to bring the manual to using a common >> > naming convention, but what should it be? Wikipedia seems to use >> > "x86" (lowercase) to refer to the ent

Re: [ping] Re: proper name of i386/x86-64/etc targets

Hi, On Mon, 19 Jan 2015, Sandra Loosemore wrote: > > I'd be happy to work on a patch to bring the manual to using a common > > naming convention, but what should it be? Wikipedia seems to use > > "x86" (lowercase) to refer to the entire family of architectures > > (including the original 16-b

Re: [ping] Re: proper name of i386/x86-64/etc targets

On Mon, Jan 19, 2015 at 11:31 PM, Uros Bizjak wrote: > On Tue, Jan 20, 2015 at 3:26 AM, Sandra Loosemore > wrote: > >>> I've noticed that the GCC user documentation is quite inconsistent about >>> the name(s) it uses for i386/x86-64/etc targets. invoke.texi has

Re: [ping] Re: proper name of i386/x86-64/etc targets

On Tue, Jan 20, 2015 at 3:26 AM, Sandra Loosemore wrote: >> I've noticed that the GCC user documentation is quite inconsistent about >> the name(s) it uses for i386/x86-64/etc targets. invoke.texi has a >> section for "i386 and x86-64 Options", but in other plac

[ping] Re: proper name of i386/x86-64/etc targets

On 01/01/2015 05:30 PM, Sandra Loosemore wrote: I've noticed that the GCC user documentation is quite inconsistent about the name(s) it uses for i386/x86-64/etc targets. invoke.texi has a section for "i386 and x86-64 Options", but in other places the manual uses x86, X86, i

Re: libstdc++ testsuite make targets check-parallel and check-performance don't work anymore

On 4 November 2014 16:34, Paolo Carlini wrote: > Ah! The testsuite_allocator.h fix of yours is still unapplied, didn't know > that, sorry ;) My bad - I thought I'd committed it! Done now.

Re: libstdc++ testsuite make targets check-parallel and check-performance don't work anymore

On 11/04/2014 04:46 PM, Paolo Carlini wrote: Hi, On 11/04/2014 04:32 PM, Jonathan Wakely wrote: Not a big deal of course, but unfortunately today I'm seeing *two* segfaults for pb_ds: performance/ext/pb_ds/multimap_text_insert_mem_large.cc .../libstdc++-v3/scripts/check_performance: line 41:

Re: libstdc++ testsuite make targets check-parallel and check-performance don't work anymore

Hi, On 11/04/2014 04:32 PM, Jonathan Wakely wrote: Not a big deal of course, but unfortunately today I'm seeing *two* segfaults for pb_ds: performance/ext/pb_ds/multimap_text_insert_mem_large.cc .../libstdc++-v3/scripts/check_performance: line 41: 16173 Segmentation fault ./$EXE_NAME &>tmp

Re: libstdc++ testsuite make targets check-parallel and check-performance don't work anymore

On 4 November 2014 13:13, Paolo Carlini wrote: > Hi again, > > > On 11/04/2014 05:34 AM, Jonathan Wakely wrote: >> >> On 04/11/14 03:41 +, Jonathan Wakely wrote: >>> >>> On 03/11/14 22:07 +, Jonathan Wakely wrote: On 3 November 2014 17:51, Paolo Carlini wrote: > > .

Re: libstdc++ testsuite make targets check-parallel and check-performance don't work anymore

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 11/04/2014 10:55 AM, schrieb Paolo Carlini: > .. thanks a lot Jon! (after all this parallel mode is still useful > for something ;) > > Paolo. Sorry for the terse message. I'm under heavy workload at the moment. But AFAIS now everything looks good

Re: libstdc++ testsuite make targets check-parallel and check-performance don't work anymore

.. and also: performance/ext/pb_ds/priority_queue_text_pop_mem.cc .../libstdc++-v3/scripts/check_performance: line 41: 16905 Segmentation fault ./$EXE_NAME &>tmp.$FILE_NAME Paolo.

Re: libstdc++ testsuite make targets check-parallel and check-performance don't work anymore

Hi again, On 11/04/2014 05:34 AM, Jonathan Wakely wrote: On 04/11/14 03:41 +, Jonathan Wakely wrote: On 03/11/14 22:07 +, Jonathan Wakely wrote: On 3 November 2014 17:51, Paolo Carlini wrote: .. other than the above issue, I see a segmentation fault for: performance/ext/pb_ds/mul

Re: libstdc++ testsuite make targets check-parallel and check-performance don't work anymore

.. thanks a lot Jon! (after all this parallel mode is still useful for something ;) Paolo.

Re: libstdc++ testsuite make targets check-parallel and check-performance don't work anymore

On 04/11/14 03:41 +, Jonathan Wakely wrote: On 03/11/14 22:07 +, Jonathan Wakely wrote: On 3 November 2014 17:51, Paolo Carlini wrote: .. other than the above issue, I see a segmentation fault for: performance/ext/pb_ds/multimap_text_insert_mem_large.cc Fixed like so. commit 75

Re: libstdc++ testsuite make targets check-parallel and check-performance don't work anymore

On 03/11/14 22:07 +, Jonathan Wakely wrote: On 3 November 2014 17:51, Paolo Carlini wrote: .. other than the above issue, I see a segmentation fault for: performance/ext/pb_ds/multimap_text_insert_mem_large.cc and a compile error for: performance/ext/pb_ds/priority_queue_text_pop

Re: libstdc++ testsuite make targets check-parallel and check-performance don't work anymore

On 03/11/14 17:19 +0100, Paolo Carlini wrote: Hi, On 11/03/2014 03:55 PM, Rainer Emrich wrote: Since the recent changes to the testsuites the folowing make targets in the libstdc++ testsuite directory don't work anymore: check-parallel check-performance check-performance-parallel

Re: libstdc++ testsuite make targets check-parallel and check-performance don't work anymore

On 3 November 2014 17:51, Paolo Carlini wrote: > .. other than the above issue, I see a segmentation fault for: > > performance/ext/pb_ds/multimap_text_insert_mem_large.cc > > and a compile error for: > > performance/ext/pb_ds/priority_queue_text_pop_mem.cc > > which boils down to a an err

Re: libstdc++ testsuite make targets check-parallel and check-performance don't work anymore

On 3 November 2014 17:51, Paolo Carlini wrote: > .. other than the above issue, I see a segmentation fault for: > > performance/ext/pb_ds/multimap_text_insert_mem_large.cc > > and a compile error for: > > performance/ext/pb_ds/priority_queue_text_pop_mem.cc > > which boils down to a an err

Re: libstdc++ testsuite make targets check-parallel and check-performance don't work anymore

.. other than the above issue, I see a segmentation fault for: performance/ext/pb_ds/multimap_text_insert_mem_large.cc and a compile error for: performance/ext/pb_ds/priority_queue_text_pop_mem.cc which boils down to a an error at include/bits/stl_deque.h:519 (likely pd_ds is misusing

Re: libstdc++ testsuite make targets check-parallel and check-performance don't work anymore

Hi, On 11/03/2014 03:55 PM, Rainer Emrich wrote: Since the recent changes to the testsuites the folowing make targets in the libstdc++ testsuite directory don't work anymore: check-parallel check-performance check-performance-parallel Any comments? All I can see so far is a non-conformin

libstdc++ testsuite make targets check-parallel and check-performance don't work anymore

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Since the recent changes to the testsuites the folowing make targets in the libstdc++ testsuite directory don't work anymore: check-parallel check-performance check-performance-parallel Any comments? Cheers Rainer -BEGIN PGP SIGN

Re: obsolete targets

On 07/09/14 20:23, Trevor Saunders wrote: Hi, I've noticed that the following targets are built in config-list.mk with --enable-obsolete i686-interix3 - doesn't appear to actually require --enable-obsolete though, should it be marked as obsolete in config.gcc? score-* and picoch

Re: obsolete targets

On 10 Jul 2014, at 04:23, Trevor Saunders wrote: > Hi, > > I've noticed that the following targets are built in config-list.mk with > --enable-obsolete > i686-interix3 - doesn't appear to actually require --enable-obsolete > though, should it be marked as obsolete

obsolete targets

Hi, I've noticed that the following targets are built in config-list.mk with --enable-obsolete i686-interix3 - doesn't appear to actually require --enable-obsolete though, should it be marked as obsolete in config.gcc? score-* and picochip-* since atleast sept 2012, is there a reason th

Re: [RFC]Better support for big-endian targets in GCC vectorizer

On Tue, 27 May 2014, Bin.Cheng wrote: > There are some other similar cases in vectorizer and all of them look > suspicious since intuitively, vectorizer should neither care about > target endianess nor do such shuffle. Anyway, this is how we do > vectorization currently. Agreed. The semantics o

Re: [RFC]Better support for big-endian targets in GCC vectorizer

On Tue, May 27, 2014 at 10:24 AM, Bin.Cheng wrote: > Hi, > > To attract more eyes, I should have used a scarier subject like "GCC's > vectorizer is heading in the wrong direction on big-endian targets". > > The idea came from a simple vectorization case I ran int

[RFC]Better support for big-endian targets in GCC vectorizer

Hi, To attract more eyes, I should have used a scarier subject like "GCC's vectorizer is heading in the wrong direction on big-endian targets". The idea came from a simple vectorization case I ran into and a discussion with Richard. Given simple case like: typedef signed shor

Re: Supported targets

> But that should be generally needed only when linking with -Wl,-z,defs , > without it the linker shouldn't care. Yet using a local libc.so with the missing AS_NEEDED is a (poor) workaround. -- Eric Botcazou

Re: Supported targets

On Tue, May 20, 2014 at 01:14:24PM +0200, Eric Botcazou wrote: > > > Yes, glibc 2.4 is required for GCC 4.9 because of this. > > > > Should that be noted at > > https://gcc.gnu.org/install/specific.html#x-x-linux-gnu ? > > Probably, unless someone knows how to work around it. We traced it to the

Re: Supported targets

> > Yes, glibc 2.4 is required for GCC 4.9 because of this. > > Should that be noted at > https://gcc.gnu.org/install/specific.html#x-x-linux-gnu ? Probably, unless someone knows how to work around it. We traced it to the missing AS_NEEDED in /usr/lib/libc.so: /* GNU ld script Use the share

Re: Supported targets

On 20 May 2014 11:55, Eric Botcazou wrote: >> [snip] >> /development/dev1/brucea/gcc4.7/bin/../lib/gcc/i686-pc-linux-gnu/4.7.0/../.. >> /../../i686-pc-linux-gnu/bin/ld: /home/brucea/gcc4 .9/lib/libmpfr.so: >> undefined reference to symbol '___tls_get_addr@@GLIBC_2.3' >> /development/dev1/brucea/gcc

Re: Supported targets

On 20 May 2014 11:26, Bruce Adams wrote: > > RHEL4 (kernel 2.6.9-55.ELsmp): > > > I was able to compile 4.8.1 successfully when it was released. 4.9.0 fails as > below. > RHEL4 is end of life (but not extended life). > > My feeling is this ought to work and is probably a regression I should report

Re: Supported targets

> [snip] > /development/dev1/brucea/gcc4.7/bin/../lib/gcc/i686-pc-linux-gnu/4.7.0/../.. > /../../i686-pc-linux-gnu/bin/ld: /home/brucea/gcc4 .9/lib/libmpfr.so: > undefined reference to symbol '___tls_get_addr@@GLIBC_2.3' > /development/dev1/brucea/gcc4.7/bin/../lib/gcc/i686-pc-linux-gnu/4.7.0/../.

Supported targets

Hi,    Slightly related to my previous question about the roadmap. I have two quite old targets based on (so far as I know) standard linux distributions. Should they still be supported? RHEL4 (kernel 2.6.9-55.ELsmp): I was able to compile 4.8.1 successfully when it was released. 4.9.0 fails

Re: Improving Asan code on ARM targets

Andrew Pinski wrote: > Yury Gribov wrote: >> Andrew Pinski wrote: >>> Yury Gribov wrote: >>>> I've recently noticed that GCC generates suboptimal code >>>> for Asan on ARM targets. E.g. for a 4-byte memory access check >>> >>> D

Re: Improving Asan code on ARM targets

Andrew wrote: I think it would good to figure out how to improve this code gen with the above patches rather than changing asan. I suspect it might easy to expand them to handle this case too. True, let me take a closer look and get back to you. When will this is expected to land in trunk bt

Re: Improving Asan code on ARM targets

On Tue, Apr 29, 2014 at 7:50 AM, Yury Gribov wrote: > Hi all, > > I've recently noticed that GCC generates suboptimal code for Asan on ARM > targets. E.g. for a 4-byte memory access check > > (shadow_val != 0) & (last_byte >= shadow_val) > > we get the f

Re: Improving Asan code on ARM targets

On Tue, Apr 29, 2014 at 09:50:56AM +0400, Yury Gribov wrote: > I've recently noticed that GCC generates suboptimal code for Asan on > ARM targets. E.g. for a 4-byte memory access check > > (shadow_val != 0) & (last_byte >= shadow_val) I guess the important question i

  1   2   3   4   5   >