Re: Deprecation/removal of nios2 target support

On Thu, Apr 18, 2024 at 10:46 AM Joseph Myers wrote: > On Wed, 17 Apr 2024, Sandra Loosemore wrote: > > > Therefore I'd like to mark Nios II as obsolete in GCC 14 now, and remove > > support from all toolchain components after the release is made. I'm > not sure > > there is an established

Re: Sourceware mitigating and preventing the next xz-backdoor

On Wed, Apr 3, 2024 at 11:03 AM Michael Matz via Gdb wrote: > Hello, > > On Wed, 3 Apr 2024, Martin Uecker wrote: > > > The backdoor was hidden in a complicated autoconf script... > > Which itself had multiple layers and could just as well have been a > complicated cmake function. > > > > (And,

Re: Sourceware mitigating and preventing the next xz-backdoor

On Wed, Apr 3, 2024, 3:09 AM Florian Weimer via Gdb wrote: > * Guinevere Larsen via Overseers: > > > Beyond that, we (GDB) are already experimenting with approved-by, and > > I think glibc was doing the same. > > The glibc project uses Reviewed-by:, but it's completely unrelated to > this.

Re: Patches submission policy change

Another possible issue which may be better now than in years past is that the versions of autoconf/automake required often had to be installed by hand. I think newlib has gotten better but before the rework on its Makefile/configure, I had a special install of autotools which precisely matched

Re: Building Single Tree for a Specific Set of CFLAGS

On Wed, Mar 27, 2024 at 3:53 AM Christophe Lyon via Gcc wrote: > Hi! > > On 3/26/24 22:52, Joel Sherrill via Gcc wrote: > > Hi > > > > For RTEMS, we normally build a multilib'ed gcc+newlib, but I have a case > > where the CPU model is something not covered by

Building Single Tree for a Specific Set of CFLAGS

Hi For RTEMS, we normally build a multilib'ed gcc+newlib, but I have a case where the CPU model is something not covered by our multilibs and not one we are keen to add. I've looked around but not found anything that makes me feel confident. What's the magic for building a gcc+newlib with a

Re: Deprecating nds32-*-linux-* target for GCC 14 (and removing it for GCC 15)

On Mon, Dec 11, 2023 at 5:20 PM Andrew Pinski via Gcc wrote: > nds32 support in Linux was removed last year: > https://www.phoronix.com/news/Andes-Tech-NDS32-Removal > > The support for glibc never made it upstream as far as I can tell either. > > What are others thoughts on this? > Looks like

Re: C89 question: Do we need to accept -Wint-conversion warnings

On Tue, Oct 10, 2023 at 12:09 PM Florian Weimer via Gcc wrote: > * Jakub Jelinek: > > > On Tue, Oct 10, 2023 at 12:30:52PM -0400, Jason Merrill via Gcc wrote: > >> On Tue, Oct 10, 2023 at 7:30 AM Florian Weimer via Gcc > > >> wrote: > >> > >> > Are these code fragments valid C89 code? > >> > >

Re: Inquiry about SME support for gcov modifications

Another related tool is mcdc-checker. This tool analyses code for conditions that require mcdc analysis based on some research that proves it isn't needed if the logic is properly structured. It can suggest alternatives that avoid the need for mcdc analysis. Research papers are linked there also.

Re: gcc tricore porting

On Mon, Jun 19, 2023, 10:36 AM Mikael Pettersson via Gcc wrote: > (Note I'm reading the gcc mailing list via the Web archives, which > doesn't let me > create "proper" replies. Oh well.) > > On Sun Jun 18 09:58:56 GMT 2023, wrote: > > Hi, this is my first time with open source development. I

Re: More C type errors by default for GCC 14

On Wed, May 10, 2023 at 10:14 AM Jakub Jelinek wrote: > On Wed, May 10, 2023 at 10:10:37AM -0500, Joel Sherrill wrote: > > > > What practices might the GCC community recommend to a project > > > > wanting to discover the issues uncovered and slowly address them? I &

Re: More C type errors by default for GCC 14

On Tue, May 9, 2023 at 5:46 PM Jonathan Wakely wrote: > On Tue, 9 May 2023 at 23:38, Joel Sherrill wrote: > > We are currently using gcc 12 and specifying C11. To experiment with > > these stricter warnings and slowly address them, would we need to build > > w

Re: More C type errors by default for GCC 14

> state that explicitly. GCC needs a point of view. > Well said. I know over at RTEMS, we have been using GCC since before EGCS and during that time, we have upgraded our GCC version a lot of times. Often, the upgrade generates more warnings. We accept that as a benefit and cost of having a living project. We also may be on the more precise end of the scale in specifying our GCC arguments. We specify the language version, enable as many warnings as possible, etc. I think it is critical that a project pick their language version and ensure that they are not getting the default which shifts over time. We are currently using gcc 12 and specifying C11. To experiment with these stricter warnings and slowly address them, would we need to build with a newer C version? What practices might the GCC community recommend to a project wanting to discover the issues uncovered and slowly address them? I i am a bit gun shy because I remember the move from GCC 3.3 to 3.4 where the improved strict alias checking gave us a LOT of warnings to deal with and it felt overwhelming. I don't want to do that again. But I believe in letting the compiler get stricter and find things. Defaulting to stricter checking is a good thing. --joel sherrill RTEMS > > Thanks, David >

Re: MicroBlaze symver attribute support

On Mon, Feb 20, 2023 at 7:56 AM Vincent Fazio via Gcc wrote: > Michael, all, > > Regarding: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101766 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102110 > > If I understand correctly, since the GCC MicroBlaze targets generate ELF > images, it would

Re: Handling of main() function for freestanding

Speaking from an RTEMS perspective, many of our examples show an initialisation thread setting up arguments to invoke main() with argc and argv and processing the return code. I would lean to main(int, char**) being known special by gcc. It won't bother the RTEMS embedded environment at all to do

Re: Build of any gcc breaks on my sparc / illumos env

: R_SPARC_DISP32: file > .libs/compatibility-thread-c++0x.o: symbol .gcc_except_table (section): > offset 0x7518dff5 is non-aligned > > > *Sonicle S.r.l. *: http://www.sonicle.com > *Music: *http://www.gabrielebulfon.com > *eXoplanets : *https://gabrielebulfon.bandcamp.com/album/exoplanet

Re: Build of any gcc breaks on my sparc / illumos env

/gabrielebulfon.bandcamp.com/album/exoplanets > > > -- > > > *Da:* Joel Sherrill > *A:* Gabriele Bulfon > *Cc:* GCC > *Data:* 20 giugno 2022 13.04.17 CEST > *Oggetto:* Re: Build of any gcc breaks on my sparc / illumos env > > > > > On Mon,

Re: Build of any gcc breaks on my sparc / illumos env

On Mon, Jun 20, 2022, 5:14 AM Gabriele Bulfon via Gcc wrote: > Hi, > > I'm the maintainer of the XStreamOS/illumos distro, mainly x86 but we also > have a sparc version. > I'm currently trying to upgrade a T4 system running XStreamOS/sparc as of > illumos 2019. > This system contains a gcc 4.7

Re: gnatlink vs. -mthumb -march=armv7-a+simd -mfloat-abi=hard

On Thu, Apr 28, 2022, 3:17 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > Hello, > > I test currently the Ada support for RTEMS in GCC 12. We have a -mthumb > -march=armv7-a+simd -mfloat-abi=hard multilib for which the Ada RTS is > built like this: > > make[4]: Entering

[PATCH] MAINTAINERS: Update email address

netbsd Krister Walfridsson sh-linux-gnu Kaz Kojima -RTEMS PortsJoel Sherrill +RTEMS PortsJoel Sherrill RTEMS PortsRalf Corsepius RTEMS PortsSebastian Huber

Re: [PATCH] config.gcc: Obsolete m32c-rtems target

On Sat, Dec 18, 2021 at 10:13 AM Joel Sherrill wrote: > > > > On Fri, Dec 17, 2021, 9:57 PM Jeff Law wrote: >> >> >> >> On 12/17/2021 9:10 AM, Joel Sherrill wrote: >> > --- >> > gcc/config.gcc | 1 + >> > 1 file changed, 1 inse

Re: [PATCH] config.gcc: Obsolete m32c-rtems target

On Fri, Dec 17, 2021, 9:57 PM Jeff Law wrote: > > > On 12/17/2021 9:10 AM, Joel Sherrill wrote: > > --- > > gcc/config.gcc | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/gcc/config.gcc b/gcc/config.gcc > > index c8824367b13

Re: [PATCH] config.gcc: Obsolete m32c-rtems target

On Fri, Dec 17, 2021 at 12:53 PM Eric Gallager wrote: > > On Fri, Dec 17, 2021 at 11:11 AM Joel Sherrill wrote: > > > > --- > > gcc/config.gcc | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/gcc/config.gcc b/gcc/config.gcc > > ind

[GCC-WWWDocs v1] htdocs/gcc-12/changes.html: Obsolete m32c-*-rtems*

--- htdocs/gcc-12/changes.html | 4 1 file changed, 4 insertions(+) diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html index b1c88670..c69b301e 100644 --- a/htdocs/gcc-12/changes.html +++ b/htdocs/gcc-12/changes.html @@ -66,6 +66,10 @@ a work-in-progress. The

[PATCH] config.gcc: Obsolete m32c-rtems target

--- gcc/config.gcc | 1 + 1 file changed, 1 insertion(+) diff --git a/gcc/config.gcc b/gcc/config.gcc index c8824367b13..fe93a72a16c 100644 --- a/gcc/config.gcc +++ b/gcc/config.gcc @@ -252,6 +252,7 @@ case ${target} in | cr16-*-*\ | hppa[12]*-*-hpux10*

Re: Generating GCC Documentation

Thanks for the quick reply. On Wed, Nov 10, 2021 at 8:20 AM Jonathan Wakely wrote: > > On Wed, 10 Nov 2021 at 14:08, Joel Sherrill wrote: > > > > Hi > > > > It's been a while since I tried this and it appears things have > > changed. I tried to follo

Generating GCC Documentation

Hi It's been a while since I tried this and it appears things have changed. I tried to follow the instructions at: https://gcc.gnu.org/onlinedocs/libstdc++/manual/documentation_hacking.html with gcc 11.2 and had a few questions: + I did a simple configure --prefix=/tmp/gcc-docs the first time

[no subject]

I am pleased to announce that the GCC Steering Committee has appointed Maciej W. Rozycki as maintainer of the Vax backend in GCC. Maciej, please update your listing in the MAINTAINERS file. Good luck! --joel

Re: [PATCH][GCC] arm: Add Cortex-R52+ multilib

On Thu, Sep 30, 2021, 3:37 PM Przemyslaw Wirkus wrote: > > Subject: Re: [PATCH][GCC] arm: Add Cortex-R52+ multilib > > > > I think the RTEMS multilibs are based on the products that RTEMS > supports, > > so this is really the RTEMS maintainers' call. > > > > Joel? > > Ping :) > I'm ok deferring

Re: Proper Place for builtin_define(__ELF__)

On Wed, Jul 21, 2021 at 10:08 PM Jeff Law wrote: > > > > On 7/21/2021 6:31 PM, Michael Eager wrote: > > > > > > On 7/21/21 5:22 PM, Joel Sherrill wrote: > >> > >> > >> On Wed, Jul 21, 2021, 7:12 PM Michael Eager >> <mailto:

Re: Proper Place for builtin_define(__ELF__)

On Wed, Jul 21, 2021, 7:12 PM Michael Eager wrote: > On 7/21/21 2:28 PM, Joel Sherrill wrote: > > Hi > > > > We are in the process of porting RTEMS to the Microblaze and gcc does > > not have __ELF__ as a predefine. In looking around at where to add it, > > it l

Proper Place for builtin_define(__ELF__)

Hi We are in the process of porting RTEMS to the Microblaze and gcc does not have __ELF__ as a predefine. In looking around at where to add it, it looks like there are multiple ways to do it. We see variations on the following patterns: + dbxelf.h + OS specific header in config/ + Arch/OS

Re: GCC documentation: porting to Sphinx

For RTEMS, we switched from texinfo to Sphinx and the dependency on Python3 for Sphinx has caused a bit of hassle. Is this going to be an issue for GCC? Also we rely on TexLive for PDF output and that's a bit of a pain to install. Tex was incorrectly packaged on some RHEL/CentOS versions. This

Re: GCC documentation: porting to Sphinx

For RTEMS, we switched from texinfo to Sphinx and the dependency on Python3 for Sphinx has caused a bit of hassle. Is this going to be an issue for GCC? Also we rely on TexLive for PDF output and that's a bit of a pain to install. Tex was incorrectly packaged on some RHEL/CentOS versions. This

Re: [PATCH] ada/adaint.c (__gnat_copy_attribs): RTEMS should use utime()

L On Thu, Apr 1, 2021, 2:08 PM Bernhard Reutner-Fischer wrote: > On 1 April 2021 21:01:27 CEST, Bernhard Reutner-Fischer < > rep.dot@gmail.com> wrote: > >On 1 April 2021 20:32:34 CEST, Joel Sherrill wrote: > >>Change the preprocessor logic so RTEMS us

[PATCH] ada/adaint.c (__gnat_copy_attribs): RTEMS should use utime()

Change the preprocessor logic so RTEMS uses utime(). gcc/ada/ * adaint.c (__gnat_copy_attribs): RTEMS should use utime(). --- gcc/ada/adaint.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/ada/adaint.c b/gcc/ada/adaint.c index 0a90c92402c..d3b83f61076 100644

Re: Remove RMS from the GCC Steering Committee

On Wed, Mar 31, 2021 at 9:23 AM Paul Koning via Gcc wrote: > I may have lost it in the enormous flood of text, but I want to ask these > general questions. > > 1. Is there a published code of conduct for GCC community members, > possibly different ones depending on which level of the

Re: Reg. Assistance in development of code for OS

On Thu, Mar 4, 2021 at 3:00 AM wrote: > Hello, > > My OS project has a very long history (I started with it in 1988) and it > is running on 1000s of installations. Thus, it's a pretty mature > project. Doing something meaningful on the kernel side requires a lot of > knowledge of how it

Re: nios2 -mcustom-round vs. libatomic

On Fri, Jan 15, 2021 at 4:12 AM Jonathan Wakely via Gcc wrote: > On Fri, 15 Jan 2021, 07:39 Sebastian Huber, < > sebastian.hu...@embedded-brains.de> wrote: > > > On 14/01/2021 15:16, Sebastian Huber wrote: > > > > > Hello, > > > > > > I try to add a nios2 multilib to support the "Nios II

Re: GCC 10 and Coverity Scan

On Wed, Oct 28, 2020 at 11:45 AM wrote: > - Original Message - > > Hi > > > > This isn't the perfect place to ask this but someone here may have > > insight. > > And getting help with Coverity Scan directly isn't easy. I'm hoping > > someone > > here has some insight or can point me to

GCC 10 and Coverity Scan

Hi This isn't the perfect place to ask this but someone here may have insight. And getting help with Coverity Scan directly isn't easy. I'm hoping someone here has some insight or can point me to someone who does. We have been using Coverity Scan a long time with RTEMS. It works fine using gcc

Re: support in C++2x

On Fri, Oct 9, 2020 at 8:49 AM Jonathan Wakely wrote: > On Fri, 9 Oct 2020 at 14:31, Joel Sherrill wrote: > > > > Hi > > > > being deprecated for nearly 20 years of C++ standards has > > always been a bit baffling to me. I'm used to thingis being deprecated &g

support in C++2x

Hi being deprecated for nearly 20 years of C++ standards has always been a bit baffling to me. I'm used to thingis being deprecated and then removed a bit faster than that. It is still deprecated in C++17 but does not appear in C++2x as of draft N4860. GCC 10 still behaves the same and you get

Re: Lowest i386 CPU Model with proper C++ atomics

On Fri, Sep 11, 2020, 5:02 PM Joel Sherrill wrote: > > > On Fri, Sep 11, 2020 at 4:36 PM Janne Blomqvist > wrote: > >> On Fri, Sep 11, 2020 at 6:52 PM Joel Sherrill wrote: >> > >> > Hi >> > >> > Over at RTEMS, we ran into a case where t

Re: Lowest i386 CPU Model with proper C++ atomics

On Fri, Sep 11, 2020 at 4:36 PM Janne Blomqvist wrote: > On Fri, Sep 11, 2020 at 6:52 PM Joel Sherrill wrote: > > > > Hi > > > > Over at RTEMS, we ran into a case where the C++ atomics may not be right > > for one of the lower level x86 models. We will inves

Re: Lowest i386 CPU Model with proper C++ atomics

On Fri, Sep 11, 2020 at 1:40 PM Florian Weimer wrote: > * Joel Sherrill: > > > I don't know that we have a huge issue in making the i486 a minimum. > > I was proposing a Pentium II or P6 as a baseline since that moves you > > up to having a TBR and initial SMP support.

Re: Lowest i386 CPU Model with proper C++ atomics

On Fri, Sep 11, 2020 at 1:07 PM Florian Weimer wrote: > * Joel Sherrill: > > > With that in mind, what's the lowest/oldest i386 CPU model we > > should consider as the new base model? > > The 80486 has a CMPXCHG instruction (4-byte CAS). Starting from CAS, > you can b

Lowest i386 CPU Model with proper C++ atomics

Hi Over at RTEMS, we ran into a case where the C++ atomics may not be right for one of the lower level x86 models. We will investigate whether it can be made right but this has led to the discussion of dropping older models and setting a new minimum model. Right now, our base is a i386 w/FPU. The

Re: TLS Implementation Across Architectures

On Thu, Jun 25, 2020 at 2:54 PM Nathan Sidwell wrote: > On 6/25/20 2:34 PM, Joel Sherrill wrote: > > Hi > > > > RTEMS supports over 15 processor architectures and we would like to > ensure > > that TLS is supported on all rather than just a handful of popular ones

TLS Implementation Across Architectures

Hi RTEMS supports over 15 processor architectures and we would like to ensure that TLS is supported on all rather than just a handful of popular ones (arm, x86, powerpc, sparc, etc). I know of Ulrich Drepper's document ( https://www.akkadia.org/drepper/tls.pdf) but it is a few years old and

Re: Please put vim swap files into gitignore

On Thu, Jun 18, 2020 at 1:34 PM Jonathan Wakely via Gcc wrote: > On Thu, 18 Jun 2020 at 19:22, Thomas Koenig via Gcc > wrote: > > > > Hi, > > > > I just found a few unversioned files called .intrinsic.c.swp and > > similar in my "git status" output. > > > > Could somebody please put .*.swp into

Re: AVR CC0 transition

On Wed, Apr 22, 2020 at 12:53 PM Moritz Strübe wrote: > > Am 22.04.2020 um 18:38 schrieb Jeff Law via Gcc: > > [..] as the > > alternative would be dropping the AVR port. > > Shouldn't that work be sponsored by Microchip (or whoever currently owns > AVR)? Arduino Inc. might also be highly

Re: SH Port Status

On Tue, Apr 21, 2020 at 4:04 AM Richard Biener wrote: > On Mon, Apr 20, 2020 at 11:05 PM Jeff Law via Gcc wrote: > > > > On Mon, 2020-04-20 at 15:29 -0500, Joel Sherrill wrote: > > > > > > > > > On Mon, Apr 20, 2020, 3:13 PM Jeff Law wrote: >

Re: SH Port Status

On Mon, Apr 20, 2020, 3:13 PM Jeff Law wrote: > On Mon, 2020-04-20 at 14:47 -0500, Joel Sherrill wrote: > > Hi > > > > Over at RTEMS, we were discussing ports to deprecate/obsolete > > and the SH seems to be on everyone's candidate list. I can't seem > > to fin

SH Port Status

Hi Over at RTEMS, we were discussing ports to deprecate/obsolete and the SH seems to be on everyone's candidate list. I can't seem to find any gcc test results sh-unknown-elf since 2009 and none for sh-rtems. I know I posted some but when, I can't say. But the new mailing list setup may be

Re: gcc 10 fpcr

Thanks. We will try this. FWIW git blame says this inline asm is 11 years old and the new GCC reported this. :) --joel On Sun, Apr 19, 2020 at 2:55 AM Uros Bizjak wrote: > Hello! > > > Over at RTEMS, we have had a report that this very old code has quit > > compiling: > > > > #ifdef __SSE__ >

gcc 10 fpcr

Hi Over at RTEMS, we have had a report that this very old code has quit compiling: #ifdef __SSE__ #define _CPU_Context_restore_fp(fp_context_pp) \ do { \ __asm__ __volatile__( \ "fldcw %0" \

Re: Architecture instruction utilization rates

On Mon, Apr 13, 2020 at 8:34 AM Bryce Cherry via Gcc wrote: > Hello all, > > I'm just curious about this, but what is the percentage of (and what are > the) unused instructions for each supported architecture under GCC? > I would bet that this info doesn't exist. And you would have to clarify

Re: GCC's instrumentation and the target environment

On Mon, Nov 4, 2019 at 7:06 AM wrote: > > From: Martin Liška > > Sent: Monday, November 4, 2019 4:20 AM > > To: taylor, david; gcc@gcc.gnu.org > > Subject: Re: GCC's instrumentation and the target environment > > > On 11/1/19 7:13 PM, David Taylor wrote: > > > Hello. > > Hello. > > > > What I'd

Re: Atomics in C++11

On Fri, Sep 20, 2019, 3:12 PM Nicholas Krause wrote: > > On 9/20/19 4:09 PM, Jason Merrill wrote: > > On Fri, Sep 20, 2019 at 8:32 AM Nicholas Krause > wrote: > >> I was wondering if its possible to use the C11 atomics library for > >> multithreading > >> > >> GCC. Not sure if its a good idea

Re: C++17 Support and Website

On Wed, Jun 19, 2019 at 2:07 PM Jonathan Wakely wrote: > On Wed, 19 Jun 2019 at 20:05, Joel Sherrill wrote: > > > > Hi > > > > I was double checking the C++17 support in GCC for someone and the text > at > > this URL states > > the suppor

C++17 Support and Website

Hi I was double checking the C++17 support in GCC for someone and the text at this URL states the support is experimental and gives the impression that the support is incomplete. The table of language features now has them all implemented. Is this text still accurate?

Re: [PATCH] Deprecate ia64*-*-*

Ok with me if no one steps up and the downstream projects like Debian gets notice. This is just a reflection of this architecture's status in the world. --joel On Thu, Jun 13, 2019, 4:13 AM Richard Biener wrote: > > ia64 has no maintainer anymore so the following deprecates it > with the goal

Re: Warning for C Parameter Name Mismatch

On Sat, Mar 9, 2019, 11:27 AM Segher Boessenkool wrote: > On Sat, Mar 09, 2019 at 08:30:19AM +, Jonathan Wakely wrote: > > On Sat, 9 Mar 2019, 02:23 Eric Gallager, wrote: > > > How would it handle the case where the parameter name is missing > > > entirely from the prototype? I see a lot of

Warning for C Parameter Name Mismatch

Hi This may be just an ignorant user question on my part. Can gcc report when the parameter name in a C prototype does not match that used in the implementation? int f(int x); int f(int y) {...} We try to fix every warning gcc reports but this is one that gcc doesn't report for us. It could

Re: GCC missing -flto optimizations? SPEC lbm benchmark

On Fri, Feb 15, 2019 at 9:02 AM Ian Lance Taylor wrote: > On Fri, Feb 15, 2019 at 4:46 AM Hi-Angel wrote: > > > > I never could understand, why field reordering was removed from GCC? I > > mean, I know that it's prohibited in C and C++, but, sure, GCC can > > detect whether it possibly can

Re: Cortex M0 Floating Point Library

On Tue, Nov 6, 2018, 10:32 PM Daniel Engel Hi, > > Over the past couple of years, I have hand-assembled a new floating point > library for the ARM Cortex M0 architecture. I know the M0 is not generally > regarded as a number-crunching machine, but I felt it deserved at least > some of the

Re: PowerPC -mspe Removed But Still in Docs

On Tue, Aug 28, 2018, 4:54 PM Segher Boessenkool wrote: > Hi Joel, > > On Tue, Aug 28, 2018 at 04:21:25PM -0500, Joel Sherrill wrote: > > Just wanting to confirm with someone PowerPC knowledgeable that > > the -mspe option was indeed removed on the master and the &g

PowerPC -mspe Removed But Still in Docs

Hi Just wanting to confirm with someone PowerPC knowledgeable that the -mspe option was indeed removed on the master and the documentation needs to be updated to reflect this. Thanks. --joel

Re: [RFC] Adding Python as a possible language and it's usage

On Wed, Jul 18, 2018, 7:15 AM Jonathan Wakely wrote: > On Wed, 18 Jul 2018 at 13:06, Eric S. Raymond wrote: > > > > Jonathan Wakely : > > > On Wed, 18 Jul 2018 at 11:56, David Malcolm wrote: > > > > Python 2.6 onwards is broadly compatible with Python 3.*. and is > about > > > > to be 10 years

Re: How to get GCC on par with ICC?

gt; For sure examples are needed so there are test cases to use for reference. If you want anything improved in any free software project, sponsoring developers is always a good thing. If you sponsor the right developers. :) I'm not discouraging you. I just trying to turn this into something ac

Re: [PATCH] config.gcc (x86_64-*-rtems*): Add rtems.h to tm_file

Thanks for submitting the patch. This patch is OK to merge to the master and all open branches that have this target. A corresponding patch for the RTEMS Source Builder is necessary because a gcc release with this patch won't be available for a while. I am starting a build with this now. If

Re: "file name" vs "filename"

On Sun, Apr 1, 2018, 3:16 PM Gerald Pfeifer wrote: > And now to the most important question of all. ;-) Should we use > "file name" or "filename" when referring to the name of a file? > > Our docs currently are about even and I think it would be good to > settle on one? > >

Re: www.sgi.com/tech/stl/ is gone

On Mar 18, 2018 6:37 PM, "Gerald Pfeifer" wrote: ...redirecting to a dummy page. Unfortunately there are a fair number of references in the libstdc++ docs, see below. I'll take care of anything outside of libstdc++; can you please have a look as far as the libstdc++ docs

Re: Unused GCC builtins

ted at github. Larger projects are often self-hosted. Does this list cover all GNU, Savannah, sourceware.org, Apache, KDE, *BSD, Mozilla, etc projects? You might get lucky and some like RTEMS and FreeBSD (I think) have a github mirror. But github is not the entire universe of free and open sou

Re: Google Summer of Code 2018: Call for mentors and ideas

On 1/17/2018 11:54 AM, Martin Jambor wrote: Hi, following a discussion at IRC about an upcoming deadline to register GCC as an independent organization for Google Summer of Code 2018 (GSoC), I have volunteered to serve as the org-admin for GCC if: - there is not another volunteer (so step

Re: Status of m32c target?

On 1/15/2018 11:31 AM, Segher Boessenkool wrote: On Mon, Jan 15, 2018 at 01:39:43PM +0100, Sebastian Huber wrote: On 13/01/18 00:16, Jeff Law wrote: On 01/12/2018 04:07 PM, Joseph Myers wrote: On Fri, 12 Jan 2018, Jeff Law wrote: I was going to suggest deprecation for gcc-8 given how

Re: Status of m32c target?

On 1/12/2018 5:40 PM, Segher Boessenkool wrote: On Fri, Jan 12, 2018 at 05:29:29PM -0600, Joel Sherrill wrote: What's the list of targets under consideration? Anything that still uses cc0 when the cull is made. Current targets using cc0 are: h8300, v850, cris, pdp11, vax, cr16

Re: Status of m32c target?

On 1/12/2018 5:16 PM, Jeff Law wrote: On 01/12/2018 04:07 PM, Joseph Myers wrote: On Fri, 12 Jan 2018, Jeff Law wrote: I was going to suggest deprecation for gcc-8 given how badly it was broken in gcc-7 and the lack of maintenance on the target. While we're considering deprecations, what

Re: Future of libquadmath and glibc 2.26 (Re: statically compile in libquadmath)

On 8/8/2017 4:17 PM, Joseph Myers wrote: On Tue, 8 Aug 2017, Joel Sherrill wrote: This may be a stupid question but with the focus of this discussionon glibc, what does this all mean for non-glibc targets? Well, Jakub recently updated parts of libquadmath from glibc (only the functions

Re: Future of libquadmath and glibc 2.26 (Re: statically compile in libquadmath)

On 8/8/2017 12:44 PM, Joseph Myers wrote: On Tue, 8 Aug 2017, Janne Blomqvist wrote: On a semi-related note, it seems the recently released glibc 2.26 contains quad math functions. Does that mean we should change to use those in preference to libquadmath when available? I suppose libquadmath

Re: Overwhelmed by GCC frustration

On 7/31/2017 11:12 AM, Oleg Endo wrote: On Mon, 2017-07-31 at 15:25 +0200, Georg-Johann Lay wrote: Around 2010, someone who used a code snipped that I published in a wiki, reported that the code didn't work and hang in an endless loop. Soon I found out that it was due to some GCC problem,

Re: TLS run-time requirements on x86, etc.

On 1/12/2017 11:25 AM, Jakub Jelinek wrote: On Thu, Jan 12, 2017 at 11:22:58AM -0600, Joel Sherrill wrote: I am looking at the RTEMS x86 TLS support. When -fPIC is specified, gcc generates calls to ___tls_get_addr(). But when it is not specified, there are no external calls. To make sure we

Re: Support Library Requirements for GCC 7.1

On 5/3/2017 4:25 AM, Jonathan Wakely wrote: On 3 May 2017 at 06:23, carl hansen wrote: On Tue, May 2, 2017 at 5:02 PM, Paul Smith <p...@mad-scientist.net> wrote: On Tue, 2017-05-02 at 18:17 -0500, Joel Sherrill wrote: With gcc 6.3.0, we have this in our build recipe: %define mpfr_v

Support Library Requirements for GCC 7.1

Hi I am trying to update the gcc version for rtems to 7.1 and running into trouble finding the correct versions of mpc, mpfr, and gmp. We build those as part of building gcc so we have configuration control over the set. With gcc 6.3.0, we have this in our build recipe: %define mpfr_version

Re: PowerPC SPE maintainership (was Re: Obsolete powerpc*-*-*spe*)

On 5/1/2017 10:47 AM, Joel Sherrill wrote: On 5/1/2017 5:48 AM, Joseph Myers wrote: On Sat, 29 Apr 2017, Segher Boessenkool wrote: We also still have to agree on the target triples for the new port. If you have any thoughts on this, I'd love to hear them. It seems fairly obvious

Re: PowerPC SPE maintainership (was Re: Obsolete powerpc*-*-*spe*)

On 5/1/2017 5:48 AM, Joseph Myers wrote: On Sat, 29 Apr 2017, Segher Boessenkool wrote: We also still have to agree on the target triples for the new port. If you have any thoughts on this, I'd love to hear them. It seems fairly obvious that the powerpc-*-eabispe* and powerpc*-*-linux*spe*

Re: Changing base compiler requirement for bootstrapping GNAT

On 1/19/2017 6:33 AM, Jakub Jelinek wrote: On Thu, Jan 19, 2017 at 01:26:32PM +0100, Andreas Schwab wrote: On Jan 19 2017, Tristan Gingold wrote: Is it ok to require gcc 4.9 (3 years old) or later to build GNAT ? The newest Ada compiler available for SLE11 is 4.8.

TLS run-time requirements on x86, etc.

chitecture? I think the MIPS generates an illegal instruction and you end up doing TLS in there. It would be easier if we could configure gcc to make subroutine calls to __tls_get_addr() instead generically? Anything else about TLS and run-time requirements we should know? -- Joel Sher

Re: History of GCC

On October 26, 2016 9:07:16 AM EDT, Ian Lance Taylor wrote: >On Tue, Oct 25, 2016 at 10:53 PM, Will Hawkins >wrote: >> >> My name is Will Hawkins and I am a longtime user of gcc and admirer >of >> the project. I hope that this is the proper forum for the

Re: [PATCH] newlib-stdint.h: Remove 32 bit longs

RTEMS uses the PRI constants and we don't see warnings. Is there a specific test case which would demonstrate this is actually broken. The file newlib-stdint.h will impact more targets than Zephyr and I think they owe a demo case. On August 19, 2016 7:37:22 PM EDT, Andrew Pinski

Re: SafeStack proposal in GCC

On 5/9/2016 3:41 PM, Ian Lance Taylor wrote: On Mon, May 9, 2016 at 1:07 PM, Joel Sherrill <joel.sherr...@oarcorp.com> wrote: One complication on RTEMS which is a single process, multi-threaded RTOS is that we can no longer check the stack bounds. For threads, we know where the stack

Re: SafeStack proposal in GCC

On 5/9/2016 3:03 PM, Michael Matz wrote: Hi, On Mon, 9 May 2016, Rich Felker wrote: The *context APIs are deprecated and I'm not sure they're worth supporting with this. It would be a good excuse to get people to stop using them. How? POSIX decided to remove the facilities without any

Re: SafeStack proposal in GCC

On 5/9/2016 2:45 PM, Ian Lance Taylor wrote: On Mon, May 9, 2016 at 12:41 PM, Joel Sherrill <joel.sherr...@oarcorp.com> wrote: On 5/9/2016 2:25 PM, Ian Lance Taylor wrote: On Fri, May 6, 2016 at 10:42 PM, Rich Felker <dal...@libc.org> wrote: The *context APIs are deprec

Re: SafeStack proposal in GCC

On 5/9/2016 2:25 PM, Ian Lance Taylor wrote: On Fri, May 6, 2016 at 10:42 PM, Rich Felker wrote: The *context APIs are deprecated and I'm not sure they're worth supporting with this. It would be a good excuse to get people to stop using them. The gccgo library uses them,

Re: Please, take '-Wmisleading-indentation' out of -Wall

On May 4, 2016 2:35:38 PM CDT, "Manuel López-Ibáñez" wrote: >On 04/05/16 19:20, David Malcolm wrote: >> On Wed, 2016-05-04@18:15 +0200, Antonio Diaz Diaz wrote: >>> - It can't be portably disabled; older versions of gcc do not >>> accept >>>

Re: GCC 6 symbol poisoning and c++ header usage is fragile

d expect the Cygwin community to feel the same way. Other than inspection, what can be done to find violations? --joel RTEMS Even if I fix libstdc++ to not require _GNU_SOURCE that won't make the problem go away, because a user could still do: #define _POSIX_SOURCE #include and if &qu

moxie-rtems patch for libgcc/config.host

issues. This patch (or some minor variant) needs to be applied to every branch from 4.9 to master. Comments? 2015-04-18 Joel Sherrill <j...@rtems.org> * config.host (moxie-*-rtems*): Merge this stanza with other moxie targets so the same extra_parts are

Re: Undefined C++ Atomic Symbol on sh-rtems

On 4/18/2016 6:11 AM, Oleg Endo wrote: On Sun, 2016-04-17 at 13:33 -0500, Joel Sherrill wrote: Thanks for the quick and thorough reply. This doesn't happen with GCC 4.9 which we are using on our newest release branch. With any luck your work will be in gcc 7 before we make another release

Re: Undefined C++ Atomic Symbol on sh-rtems

On April 16, 2016 7:50:21 PM CDT, Oleg Endo <oleg.e...@t-online.de> wrote: >Hi, > >On Sat, 2016-04-16 at 18:58 -0500, Joel Sherrill wrote: > >> I am hoping the solution to this is obvious to someone >> more familiar with the C++ libraries. Recently the >

  1   2   3   4   5   6   >