Re: strict aliasing warning
Silvius Rus wrote: I wrote some code (not released yet) that improves the accuracy of -Wstrict-aliasing using tree-ssa-alias information. The primary idea was to tell the programmer "go fix the types of variables x and y at lines ..." when -fstrict-aliasing breaks their code. It occurred to me that part of this code could be used as a preconditioner to aggressive optimization that would normally require -fstrict-aliasing, so this more aggressive optimization can then be performed selectively on individual functions even with -fno-strict-aliasing on the command line. I fear a little though that the functions which are provably free of cross-type aliasing might also not benefit much from -fstrict-aliasing, but I have very little experience with C compilers and GCC. Is this something worth pursuing? How reliable is this detection and warning? Is it ready for testers yet? I ask because we have found a case where code in RTEMS breaks when strict-aliasing is enabled. We are having discussions on how to effectively perform an audit on RTEMS for other breakages. Right now, the best idea is Ralf's to diff the assembly generated for each file compiled with and without strict-aliasing. If there is a difference, we will have to review it. This eliminates a lot of the code base but it is still generating a lot of cases to examine by hand. I'm curious if your patch will ease this process. Thank you, Silvius --joel sherrill
Re: strict aliasing warning
Andrew Haley wrote: Joel Sherrill writes: > Silvius Rus wrote: > > > > I wrote some code (not released yet) that improves the accuracy of > > -Wstrict-aliasing using tree-ssa-alias information. The primary idea > > was to tell the programmer "go fix the types of variables x and y at > > lines ..." when -fstrict-aliasing breaks their code. > > > > It occurred to me that part of this code could be used as a > > preconditioner to aggressive optimization that would normally require > > -fstrict-aliasing, so this more aggressive optimization can then be > > performed selectively on individual functions even with > > -fno-strict-aliasing on the command line. I fear a little though that > > the functions which are provably free of cross-type aliasing might > > also not benefit much from -fstrict-aliasing, but I have very little > > experience with C compilers and GCC. Is this something worth pursuing? > > > How reliable is this detection and warning? Is it ready for testers yet? > > I ask because we have found a case where code in RTEMS breaks when > strict-aliasing is enabled. We are having discussions on how to > effectively perform an audit on RTEMS for other breakages. Right > now, the best idea is Ralf's to diff the assembly generated for > each file compiled with and without strict-aliasing. If there is a > difference, we will have to review it. This eliminates a lot of > the code base but it is still generating a lot of cases to examine > by hand. Ewww, that's scary. All it tells you is which code breaks today; even a minor bug fix in gcc might make a difference. Yep. But even scarier was how hard it was for a user to find the breakage. It took hours of run-time in a real embedded systems before it showed up. We have only begin to experiment with -Wstrict-aliasing=2 and I haven't looked yet to see if this particular case is caught by the warning code or not. Personally, I am really hoping that any problems like this were flagged by that warning because... Ralf's initial report says that for x86, he gets about 1/3 of the 900 files he tested are flagged as having different generated code when compiled with and without strict aliasing. This is core operating system, file system, networking type code so no heavy duty math loops. Flagging a file doesn't mean it is broken -- only that the option had an impact and it needs to be looked at more closely. So we have some work ahead of us. At the moment, we decided our only option was to disabled strict-aliasing on the current release branch and try to methodically review the differences Ralf's procedure identifies. Nonetheless, this is a really interesting idea, and I'm sure we'd all be very interested to see the results. I think it will be useful to cross-check it against the warnings. I would hope that addressing all strict aliasing warnings would be enough to eliminate breakages BUT who knows. If someone has ideas on how ot make this review less painful, more accurate or wants to help review assembly code, please speak up. Andrew. --joel
Re: GCC 4.2.0 RC3 Available
The RTEMS community is still building and trying to test RC2. We always build with newlib. Ralf encountered problems on the avr and bfin during the tool build and has filed or updated PRs for those. I am now building the complete RTEMS source tree and tests for every board and multilib. The build is probably about 1/3 of the way through and so far, I have not encountered any problems. I have a lot left to build though and haven't actually run an executable yet. --joel Mark Mitchell wrote: GCC 4.2.0 RC3 is now available from: ftp://gcc.gnu.org/pub/gcc/prerelease-4.2.0-20070501 This build now contains the fixes for the Ada build problem present in RC2. At this point, I have no plans for an RC4. However, I am reviewing the various open issues, and available patches, so I might change my mind about that. Please see: http://gcc.gnu.org/ml/gcc/2007-05/msg00032.html for information about reporting problems. Thanks,
Re: GCC 4.2.0 RC3 Available
Mark Mitchell wrote: Joel Sherrill wrote: Ralf encountered problems on the avr and bfin during the tool build and has filed or updated PRs for those. Understood, and thnanks for testing! I should make clear that I don't see release candidates as opportunities for general testing; they're final release candidates, not alpha releases. The open nature of GCC development means that testing by stakeholders can (and should) be done well before this point. The testing of release candidates should be generally to confirm expected behavior: do the results that you saw the last time you ran tests, against an SVN checkout, match what you see today, with a release tarball? To be honest we did a lot more testing against pre 4.1 SVN code than against pre 4.2. All the talk about 4.2 being in bad shape on primary targets made us leary. Plus we had our own project's fish to fry. :) I don't see any problems at this point though except on the avr and bfin. This is in no way a criticism, or a comment on RETMS testing (about which I know almost nothing), etc.; just a general comment, which your message gave me the excuse to make. :-) No criticism taken. If someone wants to volunteer to help us improve our testing of gcc, we have ideas which would be mutually beneficial to both RTEMS and gcc. If there is bandwidth and a volunteer to help, it would be a good candidate for the Compile Farm. It just takes a lot of build time for us to get a test toolset in place and test it. We build gcc C/C++ RPMs for about 10-12 targets including newlib. That ends up generating 70 libc.a instances once installed. Then we build RTEMS, common add-on packages, and examples for over 100 multilib and board specific configurations. wc reports that source base as about 915K lines of code. It's just a matter of human time and machine time. Both are in short supply. :) --joel Thanks,
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 user vs supervisor instructions. GCC doesn't generate any supervisor instructions. My guess is that on a very simple RISC CPU, the percentage of user mode instructions used is pretty high simply because there are not that many instructions. But the more complicated CISC architectures with lots of instructions are going to be lower because someone would have had to write a pattern specifically to use a special instruction. Maybe someone with broad architecture experience can comment on which simple architecture has the most used. Intuition says a CISC architecture like the x86, m68k, or VAX has the most unused instructions but those have had a lot of work so we might be surprised. Interesting question but it would take a large survey and the number of instructions per cpu model within an architecture will vary. A productive alternative for GCC developers is the question "which instructions on which architectures would it be nice if GCC could take advantage of but currently doesn't?" This one might get an answer. --joel RTEMS
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" \
::"m"((*(fp_context_pp))->fpucw) \
:"fpcr" \
); \
__builtin_ia32_ldmxcsr(_Thread_Executing->fp_context->mxcsr); \
} while (0)
#else
The error is "error: unknown register name 'fpcr' in 'asm'"
This is when compiling for two i386 variants:
CPU_CFLAGS = -mtune=pentium4 -march=pentium4 -msse3
CPU_CFLAGS = -mtune=pentium -march=pentium -msse2
Is there a change we should be aware of in the inline assembly macros? Or
is it possible that __SSE__ and fpcr are not tied together like they were
until recently?
If needed, I can put together a full test case. I was hoping this one was
an obvious explanation before that.
Thanks.
--joel
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__
> > #define _CPU_Context_restore_fp(fp_context_pp) \
> > do { \
> >__asm__ __volatile__( \
> > "fldcw %0" \
> > ::"m"((*(fp_context_pp))->fpucw) \
> > :"fpcr" \
> >); \
> >__builtin_ia32_ldmxcsr(_Thread_Executing->fp_context->mxcsr); \
> > } while (0)
> > #else
> >
> > The error is "error: unknown register name 'fpcr' in 'asm'"
>
> Just remove the fpcr clobber. FP control register was never properly
> handled.
>
> Please also note gcc manual section "6.47.2.1 Volatile", where the
> manual discusses similar case of a system register that controls the
> rounding mode of floating-point operations. You have to add an
> artificial dependency to the asm by referencing a variable in the
> subsequent code, otherwise the compiler may move the access to system
> register across the arithmetic insn.
>
> Uros.
>
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 messing that up. I expected more recent results. (1) Is my search right? Have there been no test results in 10 years? (2) Is the toolchain in jeopardy? (3) I know there was an effort to do an open implementation with j-core.org but there is no News or download item newer than 2016. Is this architecture effectively dead except for legacy hardware out in the field (Sega?) I'm leaning to RTEMS dropping support for the SH after we branch a release and wondering if the GCC community knows anything that I don't. Thanks. --joel RTEMS
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 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 messing that up. I expected more
> > recent results.
> >
> > (1) Is my search right? Have there been no test results in 10 years?
> >
> > (2) Is the toolchain in jeopardy?
> >
> > (3) I know there was an effort to do an open implementation with
> > j-core.org but there is no News or download item newer than 2016.
> > Is this architecture effectively dead except for legacy hardware out
> > in the field (Sega?)
> >
> > I'm leaning to RTEMS dropping support for the SH after we branch
> > a release and wondering if the GCC community knows anything that
> > I don't.
> I'm not aware of the SH toolchain being in any jeopardy.
>
>
> I'm doing weekly bootstrap (yes, really) & regression tests for
> {sh4,sh4eb}-
> linux-gnu and daily builds of {sh3,sh3b}-linux-gnu. See
>
> http://gcc.gnu.org/jenkins
Awesome!
>
>
> The Linux kernel is currently broken, but I suspect it's a transient issue
> as it
> was fine until a week ago -- my tester usually builds the kernel too, but
> that's
> been temporarily disabled for SH targets.
>
Thanks Jeff! Are you using the simulator in gdb? That's what we have a BSP
for?
We build the cross RTEMS tools regularly on Linux, Mac, FreeBSD, Mingw, and
Cygwin. All of our BSPs build including sh1 and the odd sh2e.
Our BSP status for the gdb simulator is unknown. We replaced a lot of
testing infrastructure scripting and the SH hasn't gotten to the top of the
list.
So we both are building a lot and making sure rot hasn't set in. But in
practice, is this worth the trouble anymore?
--joel
> jeff
>
>
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:
> > > > 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 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 messing that up. I expected more
> > > > > recent results.
> > > > >
> > > > > (1) Is my search right? Have there been no test results in 10
> years?
> > > > >
> > > > > (2) Is the toolchain in jeopardy?
> > > > >
> > > > > (3) I know there was an effort to do an open implementation with
> > > > > j-core.org but there is no News or download item newer than 2016.
> > > > > Is this architecture effectively dead except for legacy hardware
> out
> > > > > in the field (Sega?)
> > > > >
> > > > > I'm leaning to RTEMS dropping support for the SH after we branch
> > > > > a release and wondering if the GCC community knows anything that
> > > > > I don't.
> > > > I'm not aware of the SH toolchain being in any jeopardy.
> > > >
> > > >
> > > > I'm doing weekly bootstrap (yes, really) & regression tests for
> {sh4,sh4eb}-
> > > > linux-gnu and daily builds of {sh3,sh3b}-linux-gnu. See
> > > >
> > > > http://gcc.gnu.org/jenkins
> > >
> > > Awesome!
> > > >
> > > > The Linux kernel is currently broken, but I suspect it's a transient
> issue as
> > > > it
> > > > was fine until a week ago -- my tester usually builds the kernel
> too, but
> > > > that's
> > > > been temporarily disabled for SH targets.
> > >
> > > Thanks Jeff! Are you using the simulator in gdb? That's what we have a
> BSP for?
> > I'm using qemu -- it's user mode emulation is strong enough that I can
> create a
> > little sh4 native root filesystem and bootstrap GCC within it.
> >
> >
> > >
> > > We build the cross RTEMS tools regularly on Linux, Mac, FreeBSD,
> Mingw, and
> > > Cygwin. All of our BSPs build including sh1 and the odd sh2e.
> > >
> > > Our BSP status for the gdb simulator is unknown. We replaced a lot of
> testing
> > > infrastructure scripting and the SH hasn't gotten to the top of the
> list.
> > ACK. In general, if there's a qemu solution, that's my preference these
> days.
> > For the *-elf targets I usually have to fall back to the old gdb-sim
> bits.
> >
> > >
> > > So we both are building a lot and making sure rot hasn't set in. But in
> > > practice, is this worth the trouble anymore?
> > I'm not sure about that ;-) I haven't seen anyone suggest removal of
> the port or
> > anything like that. The port doesn't use CC0, so there's essentially
> zero chance
> > it'll be deprecated for gcc-11. I believe the port is not using LRA, so
> if/when
> > we move on deprecating reload, SH might be at some degree of risk.
>
> There's two listed maintainers as well (albeit at their anonymous
> gcc.gnu.org domain).
>
Thanks to everyone. This has been an interesting discussion. I am
concluding that
the SH look pretty healthy especially considering it is a secondary port
without
hardware in production
+ Linux
- kernel.org git still has the architecture with multiple boards
- Debian SuperH mailing list has some recent (light) activity
+ RTEMS
- Tools and all BSPs regularly built for SH1 - SH4 (gcc 9 and 10)
- We have no hardware to test on. Rely on gdb sim. Haven't tested
recently
+ GCC Testing
- SH Linux User space is regularly tested on Qemu
- I did not find recent sh-elf test reports
- I did build sh-elf from master of gcc, binutils, newlib and can report
it works well enough to run hello world.
+ GCC Maintainer activity
- maintainer Oleg Endo last committed an SH patch in October 2019
- maintainer Alexandre Oliva last committed an SH patch in Dec 2017
+ GCC Port activity
- Handful of patches since 1 Oct 2019. Most are actually to fix bugs
that are SH specific and have ticket numbers.
Overall, I've seen ports in a lot worse shape. :)
Thanks to everyone for the help. I don't know whether RTEMS will keep
the SH port after our release but the tools shape won't be a factor.
--joel
RTEMS
>
> Richard.
>
> > jeff
> > >
> >
>
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 interested in continued > AVR-support. > One would like to think that. They haven't released an updated GNU toolchain since 2016 per this website: https://www.microchip.com/mplab/avr-support/avr-and-arm-toolchains-c-compilers Has there been a company sponsored community visible maintainer since Eric Weddington left the company in the 2013 time frame? I'm happy to be wrong on any of that. :) --joel RTEMS > > Cheers > Morty > > -- > Redheads Ltd. Softwaredienstleistungen > Schillerstr. 14 > 90409 Nürnberg > > Telefon: +49 (0)911 180778-50 > E-Mail: moritz.stru...@redheads.de | Web: www.redheads.de > > Geschäftsführer: Andreas Hanke > Sitz der Gesellschaft: Lauf > Amtsgericht Nürnberg HRB 22681 > Ust-ID: DE 249436843 > >
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 .gitignore? I'm sure this > > would save at least 10 reverts :-) > > You can just add it to .git/info/exclude in your own clone. > Or have a personal ~/.gitignore_global for all projects. Here is mine. $ cat ~/.gitignore_global *.o *.swp *~ *.gcno changes-xxx cscope.out Here is the section in ~/.gitconfig to enable it and a couple of other handy things. [core] excludesfile = /home/joel/.gitignore_global whitespace = trailing-space,space-before-tab pager = less -R Git is magic and full of options! --joel RTEMS
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 covers only a subset of architectures. Is TLS supported on all architectures in GCC? Is there some documentation on how it is implemented on architectures not in Ulrich's paper? Or some guidance on how to extract this information from the GCC source? Thanks. --joel
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 > > (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 > > covers only a subset of architectures. > > > > Is TLS supported on all architectures in GCC? > > > > Is there some documentation on how it is implemented on architectures not > > in Ulrich's paper? Or some guidance on how to extract this information > from > > the GCC source? > > The ARM (32) abi has some extensions to that, which originally came from > Alex Oliva and then I implemented (The GNU2 TLS stuff). I think the > smarts is in the linker for that though. > > IMHO bfd might be a better source of information than gcc. > BFD would know the section and attribute part but isn't gcc responsible for generating the code to dereference into it? It could be a specific base register or an invalid instruction fault (MIPS) or something else. I'm wondering how one knows what that magic to look up the base is for a specific architecture. Or if there is an easy way for a target to change say the MIPS bad instruction to a subroutine call? It would seem that GCC would have an architecture independent base lookup alternative. --joel --joel > > natan > -- > Nathan Sidwell >
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 best rationale we have for selecting a new floor is GCC atomics support. With that in mind, what's the lowest/oldest i386 CPU model we should consider as the new base model? Thanks. --joel
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 build the rest. There might be some caveats about the memory > model implementation (it may not be as strongly ordered as the current > i386 implementation, I haven't checked). > I guess that sets a baseline there if that's what would be used in gcc's exception processing. > > The i386 does not have CAS, which is probably the problem you are > referring to. But on non-device memory, you can certainyl fake it if > you are able to disable interrupts. > 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. But I think there are still embedded x86 clones that I am not sure meet the P6 minimum. --joel
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. > > Sorry, what's a TBR? > Time Base Register. GCC wouldn't use. It is a cycle counter register and lets one avoid use of the old i8254 derived counter/timer for high resolution times. > > > But I think there are still embedded x86 clones that I am not sure > > meet the P6 minimum. > > Some AMD Geode variants do not have CMOV and have been produced until > fairly recently (if they aren't in production still). That means that > they do not meet the Pentium Pro baseline. > I guess we need to experiment with i486 for uniprocessor and maybe PII for SMP ones. --joel
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 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 > > best rationale we have for selecting a new floor is GCC atomics support. > > > > With that in mind, what's the lowest/oldest i386 CPU model we > > should consider as the new base model? > > We sort-of discussed this issue back when the Linux kernel dropped > support for i386. See thread starting at > https://gcc.gnu.org/legacy-ml/gcc/2012-12/msg00079.html (a thread > where you participated as well) > Wow time flies! That was eight years ago and Dr Dewar was still alive. :( I guess the embedded x86 side has started to hit the wall also. Looks like we should move to at least the i486 has a baseline. Thanks. --joel > > > > -- > Janne Blomqvist >
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 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 >> > best rationale we have for selecting a new floor is GCC atomics support. >> > >> > With that in mind, what's the lowest/oldest i386 CPU model we >> > should consider as the new base model? >> >> We sort-of discussed this issue back when the Linux kernel dropped >> support for i386. See thread starting at >> https://gcc.gnu.org/legacy-ml/gcc/2012-12/msg00079.html (a thread >> where you participated as well) >> > > Wow time flies! That was eight years ago and Dr Dewar was still alive. :( > > I guess the embedded x86 side has started to hit the wall also. Looks > like we should move to at least the i486 has a baseline. > I think I tripped across a mistake in i386/t-rtems. It is old enough that it was written to use -mcpu but currently uses -mtune. Shouldn't that -march? As written, I think it is getting default model code tuned for a higher model when we want code compatible with the higher model like other multilibs. Thoughts? Thanks --joel > Thanks. > > --joel > >> >> >> >> -- >> Janne Blomqvist >> >
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 a deprecated warning when you use --std=c++2x. Am I reading the draft N4860 correctly and it is finally being removed? The warning is generic for using it and it seems as though more direct guidance could be given if it has been removed. /home/joel/rtems-work/tools/6/lib/gcc/i386-rtems6/10.2.1/include/c++/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated. [-Wcpp] I'm far from complaining about it being removed. I just want to make sure I am interpreting the draft C++ standard correctly and see if there is a desired to slightly improve GCC's warning to give more specific advice. Thanks. --joel RTEMS
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 > 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 a deprecated > warning > > when you use --std=c++2x. > > > > Am I reading the draft N4860 correctly and it is finally being removed? > > No, it's still there in the same place, Annex D. See D.12 > [depr.strstreambuf]. > Apparently the PDF file is huge and was taking forever to load and that's why my search for "strstr" didn't turn up anything. I'm asking because this came up in a discussion of whether the FACE Technical Standard for avionics should consider forbidding its use as deprecated. It sounds like we are years away from it disappearing and avionics applications do not use the latest C++ versions anyway. In your opinion, would using this be a risk for use in a long-lived application? > > The warning is generic for using it and it seems as though more direct > > guidance could be given if it has been removed. > > It hasn't been. It won't be removed until a suitable replacement is > added to the library, and even then implementations won't be required > to remove it. We still make std::auto_ptr available despite it being > removed in C++17 (after deprecation in C++11). > It is a hard edge to walk when you have to obsolete something. Over at RTEMS, we have had a great port of FreeBSD services including IPV4, IPV6, Wifi, USB, SDMMC, etc. for at least five years. But getting rid of the 20+ year old IPV4 only FreeBSD stack is going to be a pain for users who will have to port drivers to the new stack. Killing old features isn't easy. We all want to minimize impact on users. > > > /home/joel/rtems-work/tools/6/lib/gcc/i386-rtems6/10.2.1/include/c++/backward/backward_warning.h:32:2: > > warning: #warning This file includes at least one deprecated or > antiquated > > header which may be removed without further notice at a future date. > Please > > use a non-deprecated interface with equivalent functionality instead. > For a > > listing of replacement headers and interfaces, consult the file > > backward_warning.h. To disable this warning use -Wno-deprecated. [-Wcpp] > > > > I'm far from complaining about it being removed. I just want to make > sure I > > am interpreting the draft C++ standard correctly and see if there is a > > desired to slightly improve GCC's warning to give more specific advice. > > The libstdc++ list would be a better place to discuss that kind of thing. > If it hasn't been removed, then this is more than acceptable. If it is ever is removed, then a more precise message may be useful. Thank you for the quick response. --joel
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 7.5.0 but Coverity appears to have a problem with gcc 10. This is what --version reports for both toolchains: $ ~/rtems-work/tools/5/bin/sparc-rtems5-gcc --version sparc-rtems5-gcc (GCC) 7.5.0 20191114 (RTEMS 5, RSB 5 (cbae90a5817a), Newlib 7947581) $ sparc-rtems6-gcc --version sparc-rtems6-gcc (GCC) 10.2.1 20201028 (RTEMS 6, RSB 4c5af1f7c1553e53739ca4e9892de26924ec2b3f, Newlib fcaaf40) I am a bit suspicious that Coverity isn't handling the transition from 1 to 2 digits in the major number. All I am changing is the name of the target in the script that does the analysis build. This is the output from Coverity: /home/joel/coverity/cov-analysis-linux64-2019.03/bin/cov-emit --dir=/home/joel/rtems-work/b-coverity-sparc-rtems6/cov-int --ignore_path=/tmp/cov-joel/d83f12de08465ee5db7c3d5793b61b7f/cov-configure --ignore_path=/tmp/cov-joel/d83f12de08465ee5db7c3d5793b61b7f/cov-joel/4c6332bd8a8cc093158cd207a79a6edf --pre_preinclude /home/joel/coverity/cov-analysis-linux64-2019.03/config/gcc-config-0/coverity-macro-compat.h --pre_preinclude /home/joel/coverity/cov-analysis-linux64-2019.03/config/gcc-config-0/coverity-compiler-compat.h --add_type_modifier=__coverity___fpreg --add_type_modifier=__coverity_decimal --add_type_modifier=__coverity_float --add_type_modifier=__coverity_floatx --no_predefined_feature_test_macros --no_stdarg_builtin --no_predefined_cplusplus -w --no_predefines --comp_ver 0.2.1 --char_bit_size=8 --restrict --gnu_carriage_return_line_terminator --no_multiline_string --no_trigraphs --ignore_calling_convention --c11 --no_enable_80bit_float --no_enable_128bit_float --allow__bool --macro_stack_pragmas --inline_keyword --has_include_macro --has_include_next_macro --has_cpp_attribute_macro --no_predefines --c --no_builtin_emulation --ppp_translator "replace%#\s*ident\s*([^;]*);%#ident $1" --gcc --gnu_version 201 -I. -I/home/joel/rtems-work/b-coverity-sparc-rtems6/sparc-rtems6/c/leon3/include -I/home/joel/rtems-work/rtems/cpukit/include -I/home/joel/rtems-work/rtems/cpukit/score/cpu/sparc/include --sys_include /home/joel/rtems-work/tools/6/lib/gcc/sparc-rtems6/10.2.1/include --sys_include /home/joel/rtems-work/tools/6/lib/gcc/sparc-rtems6/10.2.1/include-fixed --sys_include /home/joel/rtems-work/tools/6/lib/gcc/sparc-rtems6/10.2.1/../../../../sparc-rtems6/include -DHAVE_CONFIG_H -D__OPTIMIZE__ --type_sizes=dex8Pfil4s2 --type_alignments=dex8Pfil4s2 --size_t_type=j --wchar_t_type=l --ptrdiff_t_type=i ../../../../../rtems/cpukit/zlib/zutil.c Command-line error #1359: invalid GNU version number: 201 [ERROR] 1 catastrophic error detected in this compilation. Compilation terminated. WARNING: cov-emit returned with code 2 Any insight or pointers to someone who might be of help is appreciated. --joel
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 someone who does. > > > > We have been using Coverity Scan a long time with RTEMS. It works > > fine > > using gcc 7.5.0 but Coverity appears to have a problem with gcc 10. > > This is > > what --version reports for both toolchains: > > > > $ ~/rtems-work/tools/5/bin/sparc-rtems5-gcc --version > > sparc-rtems5-gcc (GCC) 7.5.0 20191114 (RTEMS 5, RSB 5 (cbae90a5817a), > > Newlib 7947581) > > > > $ sparc-rtems6-gcc --version > > sparc-rtems6-gcc (GCC) 10.2.1 20201028 (RTEMS 6, RSB > > 4c5af1f7c1553e53739ca4e9892de26924ec2b3f, Newlib fcaaf40) > > Hi > > Putting aside politics (I used to work for Synopsys and now work > for a competitor, but not at all in the domain of static > analysis), I'll take a stab. > :) Thanks for the quick reply Paul. > > When you switched compilers, did you re-run cov-configure? > Yes. The script I use runs it every time. cov-configure -co sparc-rtems6-gcc -- -mcpu=leon3 I decided to try a Coverity run with gcc 10, 9, 8, and 7. We use gcc 7 on the release branch where Coverity works. This took a bit of time as I had to build toolchains for each of those versions. Without changing my script that runs Coverity and removing and reinstalling Coverity between runs, it works with gcc 7, 8, and 9, but not 10. If I don't uninstall and reinstall Coverity when changing GCC versions, it tends to fail. I assume there is some file left over with GCC version info that it reuses incorrectly. With gcc 10, Coverity reports this: Command-line error #1359: invalid GNU version number: 201 [ERROR] 1 catastrophic error detected in this compilation. Compilation terminated. WARNING: cov-emit returned with code 2 We are in the process of switching from an autoconf based build system to waf so I went ahead and tried the even newer waf build system. I only checked the waf build system with gcc 8 but it worked. That leads me to the conclusion that Coverity Scan is broken for GCC versions with two digit major numbers. Since the binary Coverity provides is from 2019 and GCC 10 was released in May 2020, it looks likely they didn't test against a GCC snapshot. Not sure how to make sure that information gets to the right persons to address it though. If anyone has a contact other than posting on stackoverflow, please pass it along. If anyone has any other insight, I'm happy to experiment but I think this is a Coverity issue which will eventually impact all GCC users as GCC 10 is adopted more broadly in distributions. Thanks. --joel > > A+ > Paul >
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 Floating Point > > > Hardware 2 Component": > > > > > > > > > https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_nios2_custom_instruction.pdf > > > > > > > > > If I add all custom instructions supported by the component, then I > > > get an error in libatomic since -Werror is used: > > > > > > cc1: error: switch '-mcustom-fmins' has no effect unless > > > '-ffinite-math-only' is specified [-Werror] > > > cc1: error: switch '-mcustom-fmaxs' has no effect unless > > > '-ffinite-math-only' is specified [-Werror] > > > cc1: error: switch '-mcustom-round' has no effect unless > > > '-fno-math-errno' is specified [-Werror] > > > > > > I am not sure how to fix this. > > Is a compiler warning the right diagnostic for an inconsistent use of > > compiler options? This warning is not related to code processed by GCC. > > > > But the options are part of the input provided by the user. I think a > warning is appropriate (and I'm not sure what other sensible options there > are anyway). > I've seen similar warnings on other architectures and sometimes the linker will give you an error for incompatible code. But I don't know if this incompatibility is something the linker will care about. The message is just saying it is being ignored like C++ options used when compiling C or vice-versa. Have you mapped these odd combinations to multilibs? Personally, I'd be happy for this to be an error and not a warning if they can't be in effect at the same time. The user needs to go back and think more about what they are doing. But it isn't a huge deal. In this case, I think it means your "enable all" may actually be two near complete subsets. One which is all with the no effect options dropped and another which includes the no effect options and drops the conflicting ones. But I have no idea what actually makes sense for someone to configure and deploy on this CPU. I'm just looking at the options like a truth table. --joel --joel
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 operates, and I'm afraid there is no more > documentation than what is on my homepage (http://www.rdos.net/rdos), > and you would need to read the source code for the rest. Also, most of > the kernel code is in x86 assembler using segmentation. Still, I could > of course give you advice on things. Note that this is not an academic > project, rather started as a hobby project and now is part of commercial > software. It's not Posix or Unix-like, nor Windows-like, rather was > designed from scratch. > > The only project idea I currently have is to move the file system > drivers to a new operational model which I discussed here: > https://forum.osdev.org/viewtopic.php?f=15&t=40928 This is the wrong forum for this but I don't want to discourage anyone from contributing to a FLOSS project. :) RTEMS.org is a real-time OS of similar age as RDOS. Our origin is also 1988. We support almost 20 target architectures and ~200 BSPs. RTEMS is a single address space, multi-threaded RTOS and has a significant amount of POSIX support. We have multiple filesystems, networking, SMP, etc. We have regularly participated in Google Summer of Code and keep an active list of open projects and smaller tasks. We keep these as tickets and this page provides a list of them. We are also open to other ideas: https://devel.rtems.org/wiki/Developer/OpenProjects Like RDOS, it is harder to find work on the core itself but there are lots of other areas to contribute. In fairness, there are lots of free OS projects out there, each with a different mission and targeted set of users. Find one that interests you. Those that have participated in student programs like GSoC are going to tend to have open projects pages. --joel RTEMS > > Regards, > Leif Ekblad > > --- > > > On 2021-03-04 07:02, Suhan Gautam via Gcc wrote: > > Dear Sir, > > I am persuing B. Tech. in Computer Science from a reputed College in > > Delhi > > NCR. I have domain knowledge of software languages like Java, Python, > > PHP, > > C ++, C. In addition I Am adept in DBase related softwares like Oracle. > > I > > would request your kind self to provide me an opportunity to iro coding > > in > > OS softwares. This will definitely help me in developing my skills in > > this > > niche field. > > > > Thanking you, > > > > With best regards, > > > > Suhan Gautam. >
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 organization you're > in? > As a GNU project, this should apply.: https://www.gnu.org/philosophy/kind-communication.en.html > 2. Is there a formal process for receiving claims of infraction of this > code, and for adjudicating such claims? > I admit to not looking for one but does any FLOSS organization have this? --joel > > paul > >
Re: Code size issues on FP-emulation on libgcc compared to LLVM's compiler_rt
On 6/30/2015 1:42 PM, H.J. Lu wrote: On Tue, Jun 30, 2015 at 10:44 AM, Joseph Myers wrote: On Tue, 30 Jun 2015, Zinovy Nis wrote: It works properly but I noticed that code the size for many arithmetic functions is much more larger than for soft-fp emulation provided by LLVM's compiler_rt library. Code size is discussed in the paper about soft-fp in the 2006 Summit proceedings. In general, soft-fp is optimized for speed (having completely separate "if" cases for addition and subtraction, both of which appear in both __addsf3 and __subsf3, for example) and for generality (it's used in the Linux kernel for floating-point emulation, where you want to follow the same choice of NaN etc. as a particular processor even where IEEE semantics don't specify a particular choice, and it has optional support for floating-point exceptions and rounding modes - note that __float128 support in libgcc uses the hardware exceptions and rounding modes when available), not for size (and generality takes precedence over speed where they conflict, hence being a bit slower than ieeelib even after the 2006 optimization work). soft-fp is expected to be used on 32-bit and 64-bit systems for which a few kB code size is insignificant. Size is very important for IA MCU. Would it be acceptable to update soft-fp to optimize for size with #ifdef __OPTIMIZE_SIZE__ #else #endif I don't dispute that optimizing for size would probably be wise on any x86 CPU that needs soft-float. They are all relatively slow. But posted measurements of size and speed impact of doing this would be appreciated. Unless I slept through it getting removed, the rtems targets never dropped the lower end i386 to keep legacy hardware supported. -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985
ctype_members.cc Comparison Always True
Hi Just noticed this building the head for arm-rtems4.11. Should the first comparison be eliminated and, maybe, a comment added? ctype_members.cc:216:14: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits] if (__wc >= 0 && __wc < 128 && _M_narrow_ok) ^ ctype_members.cc: In member function 'virtual const wchar_t* std::ctype::do_narrow(const wchar_t*, const wchar_t*, char, char*) const': ctype_members.cc:230:14: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits] if (*__lo >= 0 && *__lo < 128) --joel
emutls.c: warnings on master
Hi I saw these warnings in the build of some RTEMS targets on the gcc head. /home/joel/test-gcc/gcc/libgcc/emutls.c:159:7: warning: implicit declaration of function 'calloc' [-Wimplicit-function-declaration] /home/joel/test-gcc/gcc/libgcc/emutls.c:159:13: warning: incompatible implicit declaration of built-in function 'calloc' /home/joel/test-gcc/gcc/libgcc/emutls.c:171:7: warning: implicit declaration of function 'realloc' [-Wimplicit-function-declaration] /home/joel/test-gcc/gcc/libgcc/emutls.c:171:13: warning: incompatible implicit declaration of built-in function 'realloc' What magic is needed so emutls.c includes ? --joel
Re: Should we remove remnants of UWIN support in gcc/config.* files?
On August 20, 2015 5:22:47 PM EDT, Joseph Myers wrote: >On Thu, 20 Aug 2015, FX wrote: > >> > Well, they aren't *targets*, but *host* and *build* systems. >> >> Yes, but do we maintain a list of support host or build systems, that > >> would be different from our list of supported targets? > >I don't think there's such a list. For any such system that's not a >supported target to work in practice, it would need a reasonably modern > >C++ compiler, which probably rules out a lot of systems that have been >obsoleted as targets. Wouldn't a list be able to be compiled from major branch release announcements? There should be a deprecated and removed note in two release branch descriptions. Even if we screwed up and forgot to list it on both, if it likely to be in one of them. --joel
Re: 33 unknowns left
On August 26, 2015 8:28:40 PM CDT, Jeff Law wrote: >On 08/26/2015 06:02 PM, Peter Bergner wrote: >> On Wed, 2015-08-26 at 13:44 -0700, Ian Lance Taylor wrote: >>> On Wed, Aug 26, 2015 at 12:31 PM, Eric S. Raymond >wrote: click = click >>> >>> You've got me on that one. Any hints? >> >> Just purely looking at the name, did Cliff Click ever >> contribute to gcc in the past? >I don't think so. It was my first thought when I say click@. Didn't Amazon get a patent on the one click@? Seriously the email review has been a walk down memory lane. :) >jeff --joel
Re: Repository for the conversion machinery
On 8/27/2015 11:03 AM, Eric S. Raymond wrote: Paulo Matos : I noticed I am not on the list (check commit r225509, user pmatos) either. And thanks for your help on this transition. I've added you to the map. I will pile on. I may be in the history under at least three email addresses. j...@oarcorp.com joel.sherr...@oarcorp.com j...@gcc.gnu.org If it isn't too much trouble, just map me to the j...@gcc.gnu.org and I will try to be better about using that in ChangeLog entries in the future. --joel sherrill
Re: gnat 4.9.2 on arm with rtems
Hi I am on travel this week but I thought we had this problem solved. I poked on a build server I used but can't find the change and it doesn't look to be committed. The issue was that the contents of read_attr_t has changed and the Ada definition of the same structure needs to be updated. This is defined in pthread.h in newlib or an installed tools. The Ada version is in gcc/ada/s-osinte-rtems.ads. Currently the Ada version is smaller than the C version and it is just luck that something important isn't overwritten and we get a simple crash. The other pthread_*_attr_t structures should be double checked as well. --joel sherrill On 10/25/2015 12:59 PM, Arnaud Charlet wrote: I would like to know from where Complete_Master is called to break there and find out why it uses the wrong id. Why don't you simply put a breakpoint on Complete_Master? That's how I found out about the wrong/weird Self_Id. Then you should also get a backtrace which will give you extra info. You can also build hello.adb with the -gnatD switch to debug at the code expansion level where you'll see the call to Complete_Master. Thank you, that option helps a lot. Will check out the generated code tomorrow. Glad to hear it. Arno
Re: gnat 4.9.2 on arm with rtems
On 10/26/2015 3:02 PM, Jan Sommer wrote: Am Monday 26 October 2015, 08:26:57 schrieb Joel Sherrill: Hi I am on travel this week but I thought we had this problem solved. I poked on a build server I used but can't find the change and it doesn't look to be committed. Yes, it was me back then too ;-) I have been occupied the last months. The issue was that the contents of read_attr_t has changed and the Ada definition of the same structure needs to be updated. This is defined in pthread.h in newlib or an installed tools. The Ada version is in gcc/ada/s-osinte-rtems.ads. Currently the Ada version is smaller than the C version and it is just luck that something important isn't overwritten and we get a simple crash. The other pthread_*_attr_t structures should be double checked as well. Yes, I already have that change locally in newlib, it solves the stack corruption issue, but the program still fails to run properly. With the gnatD-option Arnaud suggested I figured the following today: Just double checking the language. The change I suggested was in the gcc/ada directory to an RTEMS specific OS interface file to change the Ada definition of pthread_attr_t to match the definition of the one in newlib. Complete_Master is called from finalizer of the procedure Hello. At the start it calls STPO.Self to get the id of the current task. It should be the id of the Ada-main task, but it's the id of the subordinate hello_task. Then, of course, Complete_Master does not work properly. rtems STPO.Self essentially calls rtems_task_self(). So either this function returns wrong ids or the context switch is not handled properly. The gnat-rts uses the posix-API, but rtems_task_self is from the classic API. Could it produce problems if one mixes them? There shouldn't be anything in the RTEMS GNAT target code to call rtems_task_self(). There is a call to something like gnat_task_self() and you need --enable-ada (and --disable-tests) on the RTEMS configure command like to enable that library. This method returns the value Ada.Self() expects. FWIW this implementation is find for uniprocessors but not SMP. It should be changed to a POSIX key or thread local storage so it is SMP safe. For testing I added a 2nd task to the example and printed the result of STPO.Self at several places of the program. Depending on the order of declaration of the tasks I got different results, but never the right ones. Tomorrow I will take a rtems-posix-example and see if I get proper ids if I call rtems_task_self from within the posix-threads. pthread_self() and rtems_task_self() should return exactly the same value when in the same task. If they do not, something is horribly broken. @Arnaud: I saw quite a lot of #pragma Debug-lines in the rts-code. Is there a simple way of activating them without having to recompile gnat? Best regards, Jan --joel sherrill On 10/25/2015 12:59 PM, Arnaud Charlet wrote: I would like to know from where Complete_Master is called to break there and find out why it uses the wrong id. Why don't you simply put a breakpoint on Complete_Master? That's how I found out about the wrong/weird Self_Id. Then you should also get a backtrace which will give you extra info. You can also build hello.adb with the -gnatD switch to debug at the code expansion level where you'll see the call to Complete_Master. Thank you, that option helps a lot. Will check out the generated code tomorrow. Glad to hear it. Arno -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985
Re: gnat 4.9.2 on arm with rtems
On October 26, 2015 5:02:07 PM EDT, Jan Sommer wrote: >Am Monday 26 October 2015, 15:09:34 schrieb Joel Sherrill: >> >> On 10/26/2015 3:02 PM, Jan Sommer wrote: >> > Am Monday 26 October 2015, 08:26:57 schrieb Joel Sherrill: >> >> Hi >> >> >> >> I am on travel this week but I thought we had this problem >> >> solved. I poked on a build server I used but can't find >> >> the change and it doesn't look to be committed. >> >> >> > >> > Yes, it was me back then too ;-) >> > I have been occupied the last months. >> > >> >> The issue was that the contents of read_attr_t has changed >> >> and the Ada definition of the same structure needs to be >> >> updated. This is defined in pthread.h in newlib or an >> >> installed tools. The Ada version is in >> >> gcc/ada/s-osinte-rtems.ads. >> >> >> >> Currently the Ada version is smaller than the C version >> >> and it is just luck that something important isn't >> >> overwritten and we get a simple crash. >> >> >> >> The other pthread_*_attr_t structures should be double >> >> checked as well. >> >> >> > >> > Yes, I already have that change locally in newlib, it solves the >stack corruption issue, but the program still fails to run properly. >> > With the gnatD-option Arnaud suggested I figured the following >today: >> >> Just double checking the language. The change I suggested was >> in the gcc/ada directory to an RTEMS specific OS interface file >> to change the Ada definition of pthread_attr_t to match the >> definition of the one in newlib. >> > >Exactly, I have changes in gcc-4.9.2/gcc/ada/s-osinte-rtems.ads and I >have one small change in >newlib-2.2.0.20150423/newlib/libc/sys/rtems/sys/cpuset.h . >I can send the patches to you tomorrow if you want. > > >> > Complete_Master is called from finalizer of the procedure Hello. At >the start it calls STPO.Self to get the id of the current task. It >should be the id of the Ada-main task, but it's the id of the >subordinate hello_task. >> > Then, of course, Complete_Master does not work properly. rtems >STPO.Self essentially calls rtems_task_self(). So either this function >returns wrong ids or the context switch is not handled properly. >> > The gnat-rts uses the posix-API, but rtems_task_self is from the >classic API. Could it produce problems if one mixes them? >> >> There shouldn't be anything in the RTEMS GNAT target code to call >> rtems_task_self(). There is a call to something like gnat_task_self() >> and you need --enable-ada (and --disable-tests) on the RTEMS >> configure command like to enable that library. This method returns >> the value Ada.Self() expects. >> > >My bad. It's rtems_ada_self(), you are right. The problem is still, >that it returns the address to the wrong ATCB. I will try to find out >more tomorrow. There is a comparable set method. If it isn't being called or isn't setting the value correctly, the get can't work. The method is simple. There is a special ada_self field in the RTEMS TCB which is just storing the value so it is cheap to access. >> FWIW this implementation is find for uniprocessors but not SMP. >> It should be changed to a POSIX key or thread local storage so >> it is SMP safe. >> > >I only use the RaspberryPi1., so there shouldn't be any SMP-problems. > >> > For testing I added a 2nd task to the example and printed the >result of STPO.Self at several places of the program. Depending on the >order of declaration of the tasks I got different results, but never >the right ones. >> > Tomorrow I will take a rtems-posix-example and see if I get proper >ids if I call rtems_task_self from within the posix-threads. >> >> pthread_self() and rtems_task_self() should return exactly the same >> value when in the same task. If they do not, something is horribly >> broken. >> >> > @Arnaud: I saw quite a lot of #pragma Debug-lines in the rts-code. >Is there a simple way of activating them without having to recompile >gnat? >> > >> > Best regards, >> > >> > Jan >> > >> >> --joel sherrill >> >> >> >> On 10/25/2015 12:59 PM, Arnaud Charlet wrote: >> >>>>>> I would like to know from where Complete_Master is called to >break there >> >>>>>> and >> >>>>>> find out why it uses the wrong id. >> >>>>> >> >>>>> Why don't you simply put a breakpoint on Complete_Master? >> >>>> >> >>>> That's how I found out about the wrong/weird Self_Id. >> >>> >> >>> Then you should also get a backtrace which will give you extra >info. >> >>> >> >>>>> You can also build hello.adb with the -gnatD switch to debug at >the code >> >>>>> expansion level where you'll see the call to Complete_Master. >> >>>>> >> >>>> >> >>>> Thank you, that option helps a lot. Will check out the generated >code >> >>>> tomorrow. >> >>> >> >>> Glad to hear it. >> >>> >> >>> Arno >> >>> >> > >> >> --joel
Re: gnat 4.9.2 on arm with rtems
On 10/29/2015 5:46 AM, Sebastian Huber wrote: On 28/10/15 15:22, Jan Sommer wrote: I got it working. The Set function was always overwriting the address of the previous ATCB, so STPO.Self was always returning the ATCB of the task created last. It turns out that I was building rtems without the --enable-ada option. The option is not mentioned in configure --help and gnat still builds fine. Would it be possible to not have the symbol rtems_task_self if the --enable-ada switch is off? Then linking gnat should fail with an undefined reference. I don't know too much of the rtems internals, but maybe it is as easy as adding ifdefs around the SCORE_EXTERN void *rtems_ada_self in score/threadimpl.h? Since you work on this area, this task variable should go way, since its broken on SMP systems. I would replace it o with functions, e.g. rtems_ada_get_self() and rtems_ada_set_self(), or o POSIX keys, or o thread-local storage. POSIX keys and thread-local storage would make the --enable-ada option superfluous. Thread-local storage is more efficient. It is well supported on ARM, PowerPC and SPARC on RTEMS. This is the best long term solution and shouldn't add any overhead. Ada is not supported by all gcc target architectures and I think ARM, PowerPC, SPARC, and x86 are likely the only architectures anyone will care to use it on. If that statement is wrong, then they can fix TLS on the next architecture. FWIW this has a ticket for RTEMS: https://devel.rtems.org/ticket/2289 Since this is a change against gcc 4.9 and other branches, it should also have a gcc PR. Both PRs should reference each other. Having an RTEMS PR makes it appropriate to add to the RTEMS 4.11 branch as well. This shouldn't have a negative impact. The configure magic will likely be the hardest thing to review since we probably can drop a configure option (--enable-ada) and tune --enable-ada-tests or whatever that is. It also may make sense to force --enable-ada-tests to only build on architectures with real TLS and Ada support. @Joel: What shall I do about the changes I made to gcc/ada/s-osinte-rtems.ads and newlib/libc/sys/rtems/sys/cpuset.h ? Just send the patches to you or should I push them to the respective lists with you CC? Please send them as patches to the corresponding lists and CC de...@rtems.org. --joel
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. --joel
Committing via git
Hi Is there something special needed to commit via git? I got an odd error pushing some minor RTEMS patches and wondered what the proper procedure was. I am using the same commands and process I use with newlib so was wondering. The website has svn instructions so maybe I am just confused after being up too long. --joel
Re: Committing via git
On 2/26/2016 11:50 AM, Jonathan Wakely wrote: On 26 February 2016 at 17:25, Joel Sherrill wrote: Hi Is there something special needed to commit via git? I got an odd error pushing some minor RTEMS patches and wondered what the proper procedure was. I am using the same commands and process I use with newlib so was wondering. The website has svn instructions so maybe I am just confused after being up too long. GCC sources are still subversion. The trunk (aka master) and gcc-*-branch branches in Git are read-only, you can only push to personal branches. Well that would certainly explain why a git push to master didn't work. :) Sorry for the stupidity. Thanks. --joel
Re: [WWWDocs] Deprecate support for non-thumb ARM devices
On February 28, 2016 3:20:24 PM CST, Gerald Pfeifer wrote: >On Wed, 24 Feb 2016, Richard Earnshaw (lists) wrote: >> I propose to commit this patch later this week. > >+ Support for revisions of the ARM architecture prior to ARMv4t >has >+ been deprecated and will be removed in a future GCC release. >+ This affects ARM6, ARM7 (but not ARM7TDMI), ARM8, StrongARM, >and >+ Faraday fa526 and fa626 devices, which do not have support for >+ the Thumb execution state. > >I am wondering whether this may be confusing for those not >intricately familiar with the older history of ARM platforms. > >ARMv8 is pretty new, googling for it has > http://www.arm.com/products/processors/armv8-architecture.php >as first hit, for example, and the only difference versus ARM8 >is that little lower-case "v". I assume this means a number of values for the various -mXXX arguments will be removed. Would it be more helpful to list those values? I have to agree with Gerald. I think this will obsolete a few older RTEMS BSPs but based on that wording, I don't know which. >Gerald --joel
Re: [WWWDocs] Deprecate support for non-thumb ARM devices
On 2/29/2016 5:37 AM, Kyrill Tkachov wrote: On 28/02/16 21:34, Joel Sherrill wrote: On February 28, 2016 3:20:24 PM CST, Gerald Pfeifer wrote: On Wed, 24 Feb 2016, Richard Earnshaw (lists) wrote: I propose to commit this patch later this week. + Support for revisions of the ARM architecture prior to ARMv4t has + been deprecated and will be removed in a future GCC release. + This affects ARM6, ARM7 (but not ARM7TDMI), ARM8, StrongARM, and + Faraday fa526 and fa626 devices, which do not have support for + the Thumb execution state. I am wondering whether this may be confusing for those not intricately familiar with the older history of ARM platforms. ARMv8 is pretty new, googling for it has http://www.arm.com/products/processors/armv8-architecture.php as first hit, for example, and the only difference versus ARM8 is that little lower-case "v". I assume this means a number of values for the various -mXXX arguments will be removed. Would it be more helpful to list those values? I have to agree with Gerald. I think this will obsolete a few older RTEMS BSPs but based on that wording, I don't know which. ARM8 is a processor, whereas ARMv8-A is an architecture. I think Richard's link earlier in the thread: https://community.arm.com/groups/processors/blog/2011/11/02/arm-fundamentals-introduction-to-understanding-arm-processors gives a good explanation of the naming schemes. The -mcpu/-mtune arguments that would be deprecated can be found by looking at the file config/arm/arm-cores.def and finding all the ARM_CORE entries that have '4' or lower in their 4th field These would be: That you referred to code to know the impact seems to confirm my concern that this is not something most users would realize. arm2,arm250,arm3,arm6,arm60,arm600,arm610,arm620,arm7,arm7d,arm7di,arm70,arm700,arm700i,arm710, arm720,arm710c,arm7100,arm7500,arm7500fe,arm7m,arm7dm,arm7dmi,arm8,arm810,strongarm,strongarm110, strongarm1100,strongarm1110,fa526,fa626. The arguments to -march that would be deprecated are: armv2,armv2a,armv3,armv3m,armv4. I personally think that list is a bit too long for changes.html. It didn't seem that long and makes a nice checklist. FWIW I am one of the original RTEMS developers, 25+ years of embedded work, gcc, etc. and I couldn't have have evaluated the impact of the original statement easily. Those with more knowledge ARM GCC specifics (like you) gave a precise detailed answer with what sounds like just a few minutes. Do you think it would add more clarity for people who are not familiar with the situation? Absolutely. That's an authoritative list. From that list, anyone can grep their build system to see which boards and configurations would be impacted. And honestly, when I saw the initial statement, I was concerned about how many older ARM RTEMS BSPs would be obsoleted. But seeing the specific list, I don't think we have any that are impacted. The extra information just makes it very precise and clear what's going away. FWIW I am on a standards group and one of the things I repeatedly say is that if we leave room for someone to ask a question, then they have a chance to get an answer we didn't intend. So try to avoid letting someone with less knowledge ask the question. :) --joel Thanks, Kyrill Gerald --joel
Re: GCC GSOC 2016
I may have missed this comment but GCC wouldn't need to apply as it's own GSoC project. The GNU Project applied as an umbrella organization and was accepted. Any GCC activities would be under that. I don't know who the organization administrator is for the GNU Project but the loop needs to be closed so GCC is included. FWIW the RTEMS community had been interested in improvements to coverage reporting but we don't have the expertise to do it without someone knowledgeable from GCC. We do have requirements. --joel On March 3, 2016 4:32:00 AM CST, "Manuel López-Ibáñez" wrote: >On 01/03/16 19:38, Ayush Goel wrote: >> Hey, > >Hi, > >Things related to development of GCC are best discussed in gcc@ (not >many gcc >developers actually read gcc-help). I'm moving this discussion here. > >> I am interested in contributing to gcc for the gsoc 2016. > >Unfortunately, it seems GCC did not apply to participate in GSoC 2016 >and the >deadline passed already: >https://summerofcode.withgoogle.com/organizations/?sp-search=GCC > >It also seems we did not apply last year either (at least >https://gcc.gnu.org/wiki/SummerOfCode does not show any accepted >projects for >2015). > >I think some of us would be interested in mentoring students if they >match >their preferred project [*] (thus, it is better to propose several >projects and >see if a mentor is interested than to try to find a mentor for your >preferred >project). > >However, applying to GSoC requires some paperwork and commitment >besides >mentoring, and GCC is lacking developers and existing developers have >no free >time to dedicate to this. > >> One of the projects listed a few years back, “Converting different >program representations level of GCC back to the source code” seems >really interesting to me, and I’d like to discuss the possible ways >this could be done. Who should I get into touch with? >> >> I’ve been doing research in extracting call graphs from binaries and >analysing them and therefore have gathered sufficient information about >Intermediate representations, compiler optimisations. And so feel I >might be a good match for the project > >My advice to you or any other prospective GSoC student would be: > >a) Start publicly working on GCC now: >https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps > >b) Get familiar with GCC devs on your area of interest. > >c) Convince them that a project of yours would be so useful and >interesting >that they better spent the time/effort to get GCC in the next GSoC. > >d) Once GCC is accepted by GSoC, we get so very few applications that >anyone >with a reasonable project (specially if they already have a willing >mentor) is >almost guaranteed to be accepted. > >I understand that the above is not ideal, much less useful for this >year, but I >don't have anything better to offer, sorry. You could also apply to >LLVM. They >are participating in GSoC this year: >https://summerofcode.withgoogle.com/organizations/?sp-search=LLVM > > >Good luck, > >Manuel. > >[*] Projects I would be willing to mentor: > >* Replace libiberty with gnulib. See >http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00362.html >* Anything here: https://gcc.gnu.org/wiki/Better_Diagnostics >* Kill TREE_LIST (https://gcc.gnu.org/wiki/Speedup_areas#Trees) >* Kill TREE_VECTOR >* Kill %qE (not pretty-printing of expressions) >* Kill implicit input_location >* Revive the gdb compile project >(https://sourceware.org/gdb/wiki/GCCCompileAndExecute), which seems >dead. --joel
Undefined C++ Atomic Symbol on sh-rtems
Hi I am hoping the solution to this is obvious to someone more familiar with the C++ libraries. Recently the sh4 BSP for RTEMS began to have undefined symbols like this when linking a C++ test: /data/home/joel/rtems-4.11-work/tools/4.12/bin/../lib/gcc/sh-rtems4.12/6.0.0/ml/m4/libstdc++.a(cxx11-shim_facets.o): In function `ZNKSt6locale5facet11_M_sso_shimEPKNS_2idE': /data/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/sh-rtems4.12-gcc-6-20160327-newlib-2.4.0-x86_64-linux-gnu-1/build/sh-rtems4.12/ml/m4/libstdc++-v3/include/bits/locale_facets_nonio.h:1065: undefined reference to `__gnu_cxx::__atomic_add(int volatile*, int)' Is this present for sh-elf? Or is there some magic bit missing in the RTEMS configuration stanzas? Thanks in advance. -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35806 Support Available(256) 722-9985
Re: Undefined C++ Atomic Symbol on sh-rtems
On April 16, 2016 7:50:21 PM CDT, Oleg Endo 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 >> sh4 BSP for RTEMS began to have undefined symbols >> like this when linking a C++ test: >> >> /data/home/joel/rtems-4.11-work/tools/4.12/bin/../lib/gcc/sh >> -rtems4.12/6.0.0/ml/m4/libstdc++.a(cxx11-shim_facets.o): In function >> `ZNKSt6locale5facet11_M_sso_shimEPKNS_2idE': >> /data/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/sh >> -rtems4.12-gcc-6-20160327-newlib-2.4.0-x86_64-linux-gnu-1/build/sh >> -rtems4.12/ml/m4/libstdc++ >> -v3/include/bits/locale_facets_nonio.h:1065: undefined reference to >> `__gnu_cxx::__atomic_add(int volatile*, int)' >> >> Is this present for sh-elf? Or is there some magic >> bit missing in the RTEMS configuration stanzas? > >The reason for the above error is that _GLIBCXX_ATOMIC_BUILTINS is not >set because the atomic model is not set during configure time. > Normally libstdc++ would use the atomic builtin functions to do its >stuff, but if they are not enabled during configure, >_GLIBCXX_ATOMIC_BUILTINS will not be set. > >On SH there are different "atomic models" to choose from, see also the >-matomic-model= SH target option. Unfortunately, we don't have a way >to set the default mode during GCC configure phase. I'm planning to >add this facility to GCC 7, but it should be straight forward to port >it back if needed. > >For sh4-linux and sh*-linux we currently have some hardcoded atomic >model default settings in gcc/config/sh/linux.h. The same could be >done for rtems I guess, but I'd rather go with the configure option >above. 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 branch. Is there a ticket for your plan I should add myself to to track this? --joel >Cheers, >Oleg --joel
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 branch.
Since I stated that, we decided to use the 6.1 branch for a while.
So I decided to look at config/sh/linux.h and see what it was doing.
Copying if on the 6.1 branch seemed liked an option. But it only
appears to address SH3 and SH1 for atomics. What about an implicit
atomic for SH2 or SH4?
/* Set default atomic model if it hasn't been specified. */ \
if (global_options_set.x_sh_atomic_model_str == 0)\
{ \
if (TARGET_SH3) \
sh_atomic_model_str = "soft-gusa"; \
else if (TARGET_SH1) \
sh_atomic_model_str = "soft-imask"; \
}
That's probably because of this commit:
https://gcc.gnu.org/viewcvs?rev=220094&root=gcc&view=rev
Possibly. This BSP is compiled with -m4 -ml
Is there a ticket for your plan I should add myself to to track this?
No, for that particular issue there's no ticket. I can put you in CC
when I send around/commit the patch, if that helps.
Please do. I may just leave this as a breakage and let you fix it.
AFAIK no one is really complaining that it is is broken on our
development master.
Cheers,
Oleg
\
--joel
Re: GCC 6 symbol poisoning and c++ header usage is fragile
On 4/21/2016 8:20 AM, Jonathan Wakely wrote: On 21 April 2016 at 13:33, Szabolcs Nagy wrote: On 21/04/16 12:52, Jonathan Wakely wrote: On 21 April 2016 at 12:11, Szabolcs Nagy wrote: the root cause is c++: c++ headers include random libc headers with _GNU_SOURCE ftm so all sorts of unexpected symbols are defined/declared. Yes, I'd really like to be able to stop defining _GNU_SOURCE unconditionally. It needs some libstdc++ and glibc changes for that to happen, I'll be looking at it for gcc 7. since it's unlikely the c++ standard gets fixed (to properly specify the namespace rules) Fixed how? What's wrong with the rules? (I'd like to understand what's wrong here before I try to change anything, and I don't understand the comment above). posix has "namespace rules" specifying what symbols are reserved for the implementation when certain headers are included. (it's not entirely trivial, i have a collected list http://port70.net/~nsz/c/posix/reserved.txt http://port70.net/~nsz/c/posix/README.txt i use for testing musl headers, glibc also does such namespace checks.) e.g. the declared function names in a header are reserved to be defined as macros. c++ does not specify how its headers interact with posix headers except for a few c standard headers where it requires no macro definition for functions (and imposes some other requirements on the libc like being valid c++ syntax, using extern "C" where appropriate etc). so from a libc implementor's point of view, including libc headers into c++ code is undefined behaivour (neither posix nor c++ specifies what should happen). without a specification libc headers just piling #ifdef __cplusplus hacks when ppl run into problems. e.g. c++ code uses ::pthread_equal(a,b), but musl used a macro for pthread_equal (the only sensible implementation is (a)==(b), this has to be suppressed for c++, which now uses an extern call to do the same), i'm also pretty sure a large number of c++ code would break if unistd.h defined "read", "write", "link" etc as macros, since these are often used as method names in c++, but this would be a conforming libc implementation. Gotcha, I understand what you mean now, thanks. Those rules belong in a POSIX binding for C++, not in the C++ standard, but unfortunately the group working on that has been inactive for some time. (In the absence of an official binding, I think a reasonable rule that would work for most sane C++ programs would be to say any name in ALL_CAPS and any name using the ^_[_[:upper:]].* reserved namespace can be a macro, but other names such as "read", "write", and "link" must not be defined as macros by libc headers. Maybe it would be good to come up with a set of rules for glibc and musl to agree on, if no official POSIX C++ binding is going to happen.) newlib should also be on this list. I know the RTEMS community cares about being proper per POSIX and I would 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 "read" is a macro that will break the declaration of std::istream::read. -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35806 Support Available(256) 722-9985
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 >>> '-Wno-misleading-indentation'. (At least 4.1.2 does not accept >>> it). >> >> FWIW "-Wall -Wno-misleading-indentation" works for me with gcc 4.8.3 > >It should work since GCC 4.4 (7 years old). See >https://gcc.gnu.org/wiki/FAQ#wnowarning > >>> - -Wempty-body is much simpler to test for, and in general less >>> questionable than -Wmisleading-indentation, yet it is not >>> enabled by >>> -Wall. >>> > >Many useful warnings are outside -Wall/-Wextra because there were bugs >when >initially implemented, users complained, they were moved out and then >either >the bugs were forgotten or they got fixed but nobody bothered to move >them >again within -Wall/-Wextra. See https://gcc.gnu.org/PR52961 > >Nowadays it is extremely easy to disable a warning that annoys you (the >name is >written in the message and you can use #pragmas very selectively), but >still >quite hard to discover which warning you need to enable that could have >found a >certain bug. It is also much harder to find regressions in warnings not >enabled >by -Wall -Wextra because they are not tested as much. > >I really commend David for being brave and putting the warning in >-Wall. The >easy way out would have been to say: "I know how to enable it, so let's >hide it >so that users do not complain to me about bugs that I don't suffer". We >(myself >included) have done this plenty of times in the past and the result is >always >the same: bugs don't get fixed, regressions appear, and users complain >about >missing warnings that are actually already implemented. I personally was dreading seeing how many warnings we would see in RTEMS when this first option first appeared. But we only saw a few warnings and a false positive. One of the warnings was definitely code that was unclear what the author's intent was. Others were worth addressing. The false positive was reported and fixed promptly. David has done well on this one. I am a strong believer that code is written once, read many times, and debugged by unfortunate souls. It needs to be clear and unambiguous. This warning is helpful for that. --Joel RTEMS >>> I think that keeping separated categories of warnings (instead of >>> warning about everything by default) is a valuable feature. Maybe >>> both >>> -Wempty-body and -Wmisleading-indentation (and any future similar >>> options) could be put in a new category (-Wcoding-style or >>> -Wstatic-analysis, for example). > >I agree that GCC warnings could be better categorized, but your >proposed >categories are not clearly defined. A better classification would look >at the >possibilities of false positives, how easy is to silence it, whether it >is >"undefined/unspecified at runtime", "undefined/unspecif under some >conditions >but not others", "atypical code that is often/sometimes a bug", >"typical code >that is often/sometimes a bug", etc. Of course, this would be a lot of >work >that no one wants to do ;-) > >Cheers, > > Manuel. --joel
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, because there is no working alternative. FWIW when this transition occurred, that's when the RTEMS port broke. We don't have these methods. It would be an interesting exercise to see if they could be implemented in terms of our internal thread context management APIs but no one has ever looked into it deeply. In general coroutine support requires the ability to designate some area of memory as stack space. Ian --joel
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 wrote: 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, because there is no working alternative. FWIW when this transition occurred, that's when the RTEMS port broke. We don't have these methods. Yes, that was unfortunate, but it was a significant increase in efficiency. It would be an interesting exercise to see if they could be implemented in terms of our internal thread context management APIs but no one has ever looked into it deeply. They are short functions, and easy to implement. They don't need to use any thread context management, they just manipulate registers. The catch is that, because they manipulate registers, they are inherently machine-specific. I suppose we could reuse implementations from *BSD for a subset of targets. Those would likely be the targets folks care about anyway. Hmm... would those make sense to add to newlib? I am thinking they are similar to setjmp/longjmp and shouldn't need supervisor mode access. Ian
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 adequate
replacement (thread aren't).
Threads work just as well as the ucontext api for coroutines. Due to the
requirement to save/restore signal masks, the latter requires a syscall,
making it no faster than a voluntary context switch via futex syscall.
Uhm, no. If you disregard efficiency, sure, POSIX threads are sometimes a
replacement on some platforms. They still have completely different
activation models (being synchronous with *context, for which you need
even further slow synchronization in a threading model).
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 memory is and the range for each thread. For ucontext_t,
it seems this knowledge is unknown to the RTOS.
Thus it would become the responsibility of the run-time using ucontext_t
to put in fence patterns and check those.
Most of the other hacks people used the ucontext API for were complete
hacks with undefined behavior, anyway.
Sure, that doesn't imply the facility should be removed. I can misuse all
kinds of stuff.
BTW it's not even possible to implement makecontext on most targets due
to the wacky variadic calling convention it uses -- in most ABIs,
there's simply no way to shift the variadic args into the right slots
for calling the start function for the new context without knowing their
types, and the implementation has no way to know the types. So it's
really an unusably broken API.
Of course. But _that_ implies that a workable replacement should have
been put in place, not the unrealistic stance POSIX took with the removal:
makecontext2(ucontext_t *ucp, void (*func)(void*), void* cookie);
Done. I never understood why they left in the hugely
unuseful {sig,}{set,long}jmp() but removed the actually useful *context()
(amended somehow like above).
Ciao,
Michael.
--joel
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 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 memory is and the range for each thread. For ucontext_t, it seems this knowledge is unknown to the RTOS. Thus it would become the responsibility of the run-time using ucontext_t to put in fence patterns and check those. On RTEMS and similar systems, you could write makecontext to register the stack (whose start and length are known to the function) with the RTOS. Ahh... slow today. swapcontext() would have to work with the stack checker. Interesting.. the stack usage reporting would have to be taught about the ucontext_t's in the system and report those as well. Am I missing something or is there no way to know when a context goes out of existence in the API? Ian --joel
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 question I >> am going to ask. If it isn't, please accept my apology and ignore me. >> >> I am a real geek and I love the history behind open source projects. >> I've found several good resources about the history of "famous" open >> source projects and organizations (including, but definitely not >> limited to, the very interesting Free as in Freedom 2.0). >> >> Unfortunately there does not appear to be a good history of the >> awesome and fundamental GCC project. I know that there is a page on >> the wiki (https://gcc.gnu.org/wiki/History) but that is really the >> best that I can find. >> >> Am I missing something? Are there good anecdotes about the history of >> the development of GCC that you think I might find interesting? Any >> pointers would be really great! >> >> Thanks for taking the time to read my questions. Thanks in advance >for >> any information that you have to offer. I really appreciate >everyone's >> effort to make such a great compiler suite. It's only with such a >> great compiler that all our other open source projects are able to >> succeed! > >There is some history and links at >https://en.wikipedia.org/wiki/GNU_Compiler_Collection . > >In my opinion, the history of GCC is not really one of drama or even >anecdotes, except for the EGCS split. I am not even sure that is interesting except as an example of an experiment to change the development model that worked. But that should all be covered somewhere online. --joel >There are plenty of people who >work on GCC out of personal interest, but for decades now the majority >of work on GCC has been by people paid to work on it. I expect that >the result is less interesting as history and more interesting as >software. > >Ian --joel
multiple rtems targets __dso_handle not found
Hi The cut and paste is from an sh-rtems C++ application link failure. But the failure is happening on some h8300, m68k, powerpc, and sh BSPs. Each BSP has its own linker script so if there is a mistake in that due to age, then we could be missing some newer magic. This is all with gcc 4.8.2 and binutils 2.24? What are we missing that would have introduced this? sh-rtems4.11-g++ -B../../../../../gensh1/lib/ -specs bsp_specs -qrtems -m1 -O2 -g -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs-m1 -o cdtest.exe init.o main.o main.o: In function `_static_initialization_and_destruction_0': /users/joel/rtems-4.11-work/rtems-testing/rtems/build-sh-gensh1-rtems/sh-rtems4.11/c/gensh1/testsuites/samples/cdtest/../../../../../../../rtems/c/src/../../testsuites/samples/cdtest/main.cc:141: undefined reference to `__dso_handle' /users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2/libstdc++.a(eh_globals.o): In function `_static_initialization_and_destruction_0': /users/joel/rtems-4.11-work/rtems-source-builder/rtems/build/sh-rtems4.11-gcc-4.8.2-newlib-cvs-head-1/build/sh-rtems4.11/libstdc++-v3/libsupc++/../../../../gcc-4.8.2/libstdc++-v3/libsupc++/eh_globals.cc:109: undefined reference to `__dso_handle' /users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2/../../../../sh-rtems4.11/bin/ld: cdtest.exe: hidden symbol `___dso_handle' isn't defined /users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2/../../../../sh-rtems4.11/bin/ld: final link failed: Bad value Thanks. -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985
sh-*-* Fails to Compile on FreeBSD
Hi
gcc-4.8.2 targeting sh-*-* fails to compile on
FreeBSD 10 which is using clang. I am hoping someone
has some ideas about these.
In file included from ../../gcc-4.8.2/gcc/config/sh/sh.c:63:
In file included from /usr/include/c++/v1/sstream:174:
In file included from /usr/include/c++/v1/ostream:131:
In file included from /usr/include/c++/v1/ios:216:
In file included from /usr/include/c++/v1/__locale:15:
In file included from /usr/include/c++/v1/string:438:
In file included from /usr/include/c++/v1/cwchar:107:
In file included from /usr/include/c++/v1/cwctype:54:
/usr/include/c++/v1/cctype:51:72: error: use of undeclared identifier
'do_not_use_isalnum_with_safe_ctype'
inline _LIBCPP_INLINE_VISIBILITY int __libcpp_isalnum(int __c) {return
isalnum(__c);}
sh.c line 63 is this:
#include
#include
#include
It is the only file in gcc/config/* to include sstream. Has some
update sweep for C++ transition missed this file?
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
Re: sh-*-* Fails to Compile on FreeBSD
On 5/1/2014 3:29 PM, Oleg Endo wrote:
> On 01 May 2014, at 22:08, Joel Sherrill wrote:
>
>> Hi
>>
>> gcc-4.8.2 targeting sh-*-* fails to compile on
>> FreeBSD 10 which is using clang. I am hoping someone
>> has some ideas about these.
> Yes, I've noticed and mentioned this already a while ago:
> http://gcc.gnu.org/ml/gcc/2013-12/msg00036.html
>
>
>> In file included from ../../gcc-4.8.2/gcc/config/sh/sh.c:63:
>> In file included from /usr/include/c++/v1/sstream:174:
>> In file included from /usr/include/c++/v1/ostream:131:
>> In file included from /usr/include/c++/v1/ios:216:
>> In file included from /usr/include/c++/v1/__locale:15:
>> In file included from /usr/include/c++/v1/string:438:
>> In file included from /usr/include/c++/v1/cwchar:107:
>> In file included from /usr/include/c++/v1/cwctype:54:
>> /usr/include/c++/v1/cctype:51:72: error: use of undeclared identifier
>> 'do_not_use_isalnum_with_safe_ctype'
>> inline _LIBCPP_INLINE_VISIBILITY int __libcpp_isalnum(int __c) {return
>> isalnum(__c);}
>>
>> sh.c line 63 is this:
>>
>> #include
>> #include
>> #include
>>
>> It is the only file in gcc/config/* to include sstream. Has some
>> update sweep for C++ transition missed this file?
> Could you please try moving the std includes above any other (gcc) includes
> and see if it fixes the issue? AFAIR it did it for me.
This seems to fix it. I am not sure why sh.c is the only file in
gcc/config which includes sstream though. Is this a violation
of some new rule?
Is there a PR for this?
If not, I probably should file one and get the patch pushed
into 4.8 as well as 4.9 and the head if they need it.
Thanks.
>
> Cheers,
> Oleg
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
SH -ml not turning into -EL to ld
_rel-cache_aligned_malloc.o /users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2/../../../../sh-rtems4.11/bin/ld: ../shared/src/cache_rel-cache_manager.o: compiled for a little endian system and target is big endian /users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2/../../../../sh-rtems4.11/bin/ld: ../shared/src/cache_rel-cache_manager.o: uses instructions which are incompatible with instructions used in previous modules /users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2/../../../../sh-rtems4.11/bin/ld: failed to merge target specific data of file ../shared/src/cache_rel-cache_manager.o collect2: error: ld returned 1 exit status [joel@rtbf64a sh]$ /users/joel/rtems-4.11-work/tools/libexec/gcc/sh-rtems4.11/4.8.2/collect2 -dc -dp -N -o cache.rel -r -L/users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2/ml/m2e -L/users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2/../../../../sh-rtems4.11/lib/ml/m2e -L../../../../.././simsh2e/lib -L/users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2 -L/users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2/../../../../sh-rtems4.11/lib ../shared/src/cache_rel-cache_aligned_malloc.o ../shared/src/cache_rel-cache_manager.o -EL -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985
Re: SH -ml not turning into -EL to ld
Following up to myself... I don't know exactly how to fix
this but I think I have pulled the right thread.
gcc/config/sh/superh.h defined SUBTARGET_LINK_SPEC which
appears to have the right arguments.
sh-rtems4.11-gcc -dumpspecs shows that *link ends with
"%(subtarget_link_spec} which seems correct. But that is
defined to nothing when I think it should be
"%{ml:-EL}%{mb|!ml:-EB}"
configure.gcc shows that sh-superh-elf includes these which
are not in the sh-rtems*) target:
tm_file="${tm_file} sh/superh.h"
extra_options="${extra_options} sh/superh.opt" ;;
Do we need to add those? Anything else we might be missing?
On 5/5/2014 11:37 AM, Joel Sherrill wrote:
> Hi
>
> We have a few build failures on the RTEMS target where it appears
> that the -ml argument to make a relocatable is not turned into a
> -EL argument to ld by gcc 4.8.2.
>
> This is the output of invoking gcc with "-v". Below that I invoked
> the same LD command with -EL on the command line and it
> worked.
>
> Any ideas or suggestions?
>
> $ sh-rtems4.11-gcc --pipe -B../../../../.././lib/
> -B../../../../.././simsh2e/lib/ -specs bsp_specs -qrtems -m2e -ml -O2
> -g -Wall -Wmissing-prototypes -Wimplicit-function-declaration
> -Wstrict-prototypes -Wnested-externs -qnolinkcmds -nostdlib -r -o
> cache.rel ../shared/src/cache_rel-cache_aligned_malloc.o
> ../shared/src/cache_rel-cache_manager.o -v
> Using built-in specs.
> Reading specs from ../../../../.././simsh2e/lib/bsp_specs
> rename spec endfile to old_endfile
> rename spec startfile to old_startfile
> rename spec link to old_link
> COLLECT_GCC=sh-rtems4.11-gcc
> COLLECT_LTO_WRAPPER=/users/joel/rtems-4.11-work/tools/libexec/gcc/sh-rtems4.11/4.8.2/lto-wrapper
> Target: sh-rtems4.11
> Configured with: ../gcc-4.8.2/configure
> --prefix=/users/joel/rtems-4.11-work/tools
> --bindir=/users/joel/rtems-4.11-work/tools/bin
> --exec_prefix=/users/joel/rtems-4.11-work/tools
> --includedir=/users/joel/rtems-4.11-work/tools/include
> --libdir=/users/joel/rtems-4.11-work/tools/lib
> --libexecdir=/users/joel/rtems-4.11-work/tools/libexec
> --mandir=/users/joel/rtems-4.11-work/tools/share/man
> --infodir=/users/joel/rtems-4.11-work/tools/share/info
> --datadir=/users/joel/rtems-4.11-work/tools/share
> --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=sh-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 --disable-lto
> --enable-newlib-io-c99-formats --enable-newlib-iconv
> --enable-newlib-iconv-encodings=big5,cp775,cp850,cp852,cp855,cp866,euc_jp,euc_kr,euc_tw,iso_8859_1,iso_8859_10,iso_8859_11,iso_8859_13,iso_8859_14,iso_8859_15,iso_8859_2,iso_8859_3,iso_8859_4,iso_8859_5,iso_8859_6,iso_8859_7,iso_8859_8,iso_8859_9,iso_ir_111,koi8_r,koi8_ru,koi8_u,koi8_uni,ucs_2,ucs_2_internal,ucs_2be,ucs_2le,ucs_4,ucs_4_internal,ucs_4be,ucs_4le,us_ascii,utf_16,utf_16be,utf_16le,utf_8,win_1250,win_1251,win_1252,win_1253,win_1254,win_1255,win_1256,win_1257,win_1258
> --enable-threads --disable-plugin --enable-languages=c,c++
> Thread model: rtems
> gcc version 4.8.2 20131016 (RTEMS
> 4.11-RSB-6fe63b3f553bb3157c7b8256917152ca36450fd4-1,gcc-4.8.2/newlib-2.1.0)
> (GCC)
> COMPILER_PATH=../../../../.././simsh2e/lib/:/users/joel/rtems-4.11-work/tools/libexec/gcc/sh-rtems4.11/4.8.2/:/users/joel/rtems-4.11-work/tools/libexec/gcc/sh-rtems4.11/4.8.2/:/users/joel/rtems-4.11-work/tools/libexec/gcc/sh-rtems4.11/:/users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2/:/users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/:/users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2/../../../../sh-rtems4.11/bin/
> LIBRARY_PATH=/users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2/ml/m2e/:/users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2/../../../../sh-rtems4.11/lib/ml/m2e/:../../../../.././simsh2e/lib/:/users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2/:/users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2/../../../../sh-rtems4.11/lib/
> COLLECT_GCC_OPTIONS='-pipe' '-B' '../../../../.././lib/' '-B'
> '../../../../.././simsh2e/lib/' '-specs=bsp_specs' '-qrtems' '-m2e'
> '-ml' '-O2' '-g' '-Wall' '-Wmissing-prototypes'
> '-Wimplicit-function-declaration' '-Wstrict-prototypes'
> '-Wnested-externs' '-qnolinkcmds' '-nostdlib' '-r' '-o' 'cache.rel' '-v'
> /users/joel/rtems-4.11-work/tools/libexec/gcc/sh-rtems4.11/4.8.2/collect2
> -dc -dp -N -o c
gnat_rm.texi and makeinfo 5.1
Hi I am trying to build a native GNAT from the head on Fedora 20. It has makeinfo 5.1 which is causing gnat_rm.texi a lot of problems. This is just the beginning of almost 200 error messages. ../../gcc/gcc/ada/gnat_rm.texi:4107: warning: @itemize has text but no @item ../../gcc/gcc/ada/gnat_rm.texi:12057: @item outside of table or list ../../gcc/gcc/ada/gnat_rm.texi:12068: @item outside of table or list ../../gcc/gcc/ada/gnat_rm.texi:12080: @item outside of table or list ../../gcc/gcc/ada/gnat_rm.texi:12091: @item outside of table or list ../../gcc/gcc/ada/gnat_rm.texi:12101: @item outside of table or list ../../gcc/gcc/ada/gnat_rm.texi:12112: @item outside of table or list ../../gcc/gcc/ada/gnat_rm.texi:12121: @item outside of table or list cc'ing Eric B since I remember him mentioning that they autogenerated texinfo from Sphinx and I am wondering if this is manual or autogenerated. Other than fixing the manual or downgrading makeinfo, any suggestions or comments? -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985
i386.md missing a mode
Hi On the head, I see this: ../../gcc/gcc/config/i386/i386.md:11448: warning: source missing a mode? ../../gcc/gcc/config/i386/i386.md:11460: warning: source missing a mode? / Since it is in the middle of a big log and doesn't include the word warning in the message, I wondered if someone was aware of it. -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985
Ada and CFLAGS_FOR_TARGET
Hi I was updating the RTEMS scripts to build GNAT and it appears that passing CFLAGS_FOR_TARGET in to add a -I option to the build no longer works. We were using it so the Ada build could find the networking .h files. What's the current way of doing this? Thanks. -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985
Re: Offload Library
On 6/20/2014 1:46 PM, David Edelsohn wrote: > On Fri, May 16, 2014 at 7:47 AM, Kirill Yukhin > wrote: >> Dear steering committee, >> >> To support the offloading features for Intel's Xeon Phi cards >> we need to add a foreign library (liboffload) into the gcc repository. >> README with build instructions is attached. >> >> I am also copy-pasting the header comment from one of the liboffload files. >> The header shown below will be in all the source files in liboffload. >> >> Sources can be downloaded from [1]. >> >> Additionally to that sources we going to add few headers (released under GPL >> v2.1 license) >> and couple of new sources (license in the bottom of the message). >> >> Does this look OK? > The GCC SC has decided to allow this library in the GCC sources. > > If the library is not going to be expanded to support all GPUs and > offload targets, the library name should be more specific to Intel. That matches what I understood and should have said Yes to. > Thanks, David -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985
Re: GCC 4.9.1 Status Report (2014-07-10)
On 7/10/2014 5:14 PM, pins...@gmail.com wrote: > >> On Jul 10, 2014, at 3:13 PM, Ian Lance Taylor wrote: >> >>> On Thu, Jul 10, 2014 at 11:40 AM, Franzi Edo. wrote: >>> >>> As for the version 4.9.0, on OSX stil remain a problem. >>> I cannot build an ARM a cross compiler! >>> Here is the message (same as for the 4.9.0) >>> >>> ... >>> .../Packages/gcc-4.9.1/gcc/config/arm/neon.md:3486:10917: fatal error: >>> bracket nesting level exceeded maximum of 256 >>> .../Packages/gcc-4.9.1/gcc/config/arm/neon.md:3486:10917: note: use >>> -fbracket-depth=N to increase maximum nesting level >>> 32 warnings and 1 error generated. >>> make[1]: *** [insn-attrtab.o] Error 1 >> You did not include enough context to be sure, but I don't think that >> error message is coming from GCC. At least, I don't see that error >> message in the GCC sources. >> >> I think that error message is coming from the host compiler you are >> using, in which case, based on the error message, the solution would >> seem to be >>make CFLAGS="-g -O2 -fbracket-depth=512" > Also i thought we did not support cross building with anything besides gcc. The RTEMS community sees this when using clang/llvm on FreeBSD. Franzi.. did the suggestion from Chris Johns to increase the limit to 1024, not work? https://gcc.gnu.org/ml/gcc/2014-05/msg00018.html This ended up being reported at http://llvm.org/bugs/show_bug.cgi?id=19650 --joel > Thanks, > Andrew > >> Ian -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985
m32c-*-* Build Issue (Multilib?)
Hi m32c-rtems4.11 doesn't build in 4.9.x. I looked at m32c-rtems4.11 and m32c-elf on the head and both fail in the same way. I can't see any recent changes to the m32c which would have caused this so I am reaching out. binutils is the head and newlib is close to their head. Both builds fail with: make[4]: Entering directory `/users/joel/test-gcc/b-m32c-elfgcc/m32c-elf/m32cm/libgcc' make[4]: *** No rule to make target `all'. Stop. At the point of the failure, the m32c-elf directory has these: $ find m32c-elf/ -type d m32c-elf/ m32c-elf/libgcc m32c-elf/libgcc/confhUyTPp m32c-elf/m32cm m32c-elf/m32cm/libgcc I think that looks odd. Normally the top directory is named for libraries not multilib variants. Any ideas? -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985
Re: m32c-*-* Build Issue (Multilib?)
On 7/17/2014 3:08 PM, DJ Delorie wrote:
> I just tried a 4.9.1 build and got this error:
Same error in m32c-elf/m32cm/libgcc/config.log for a build of the
head. I apparently just saw the symptoms and missed this.
I have a gcc 4.8.2 RTEMS toolset installed so that provides some
window.
What's the next step?
> configure:4222: checking whether to use setjmp/longjmp exceptions
> configure:: /greed/dj/gnu/gcc/m32c-elf/gcc-4_9-branch/./gcc/xgcc
> -B/greed/dj/gnu/gcc/m32c-elf/gcc-4_9-branch/./gcc/
> -B/greed/dj/m32c/install/m32c-elf/bin/ -B/greed/dj/m32c/install/m32c-elf/lib/
> -isystem /greed/dj/m32c/install/m32c-elf/include -isystem
> /greed/dj/m32c/install/m32c-elf/sys-include -mcpu=m32cm -c --save-temps
> -fexceptions conftest.c >&5
> conftest.c: In function 'foo':
> conftest.c:19:1: error: insn does not satisfy its constraints:
> }
> ^
> (insn 52 38 23 (set (reg:SI 2 r1 [29])
> (reg:SI 4 a0)) 99 {movsi_24}
> (nil))
>
> conftest.c:19:1: internal compiler error: in final_scan_insn, at final.c:2891
> 0x7a56a8 _fatal_insn(char const*, rtx_def const*, char const*, int, char
> const*)
> /greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/rtl-error.c:109
> 0x7a56cf _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
> /greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/rtl-error.c:120
> 0x6256c9 final_scan_insn(rtx_def*, _IO_FILE*, int, int, int*)
> /greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/final.c:2891
> 0x6258ef final(rtx_def*, _IO_FILE*, int)
> /greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/final.c:2023
> 0x626035 rest_of_handle_final
> /greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/final.c:4427
> 0x626035 execute
> /greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/final.c:4502
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
Re: m32c-*-* Build Issue (Multilib?)
I also missed something Chris was reporting.
We see other failures in the log because newlib/targ-include
isn't created. The rtems build include path includes that and
needs it but it isn't created before libgcc is built. That isn't a
problem on other targets. I don't see anything odd in the top
configurery magic for m32c which could cause this but I could
easily be missing something.
On 7/17/2014 3:17 PM, Joel Sherrill wrote:
> On 7/17/2014 3:08 PM, DJ Delorie wrote:
>> I just tried a 4.9.1 build and got this error:
> Same error in m32c-elf/m32cm/libgcc/config.log for a build of the
> head. I apparently just saw the symptoms and missed this.
>
> I have a gcc 4.8.2 RTEMS toolset installed so that provides some
> window.
>
> What's the next step?
>> configure:4222: checking whether to use setjmp/longjmp exceptions
>> configure:: /greed/dj/gnu/gcc/m32c-elf/gcc-4_9-branch/./gcc/xgcc
>> -B/greed/dj/gnu/gcc/m32c-elf/gcc-4_9-branch/./gcc/
>> -B/greed/dj/m32c/install/m32c-elf/bin/
>> -B/greed/dj/m32c/install/m32c-elf/lib/ -isystem
>> /greed/dj/m32c/install/m32c-elf/include -isystem
>> /greed/dj/m32c/install/m32c-elf/sys-include -mcpu=m32cm -c --save-temps
>> -fexceptions conftest.c >&5
>> conftest.c: In function 'foo':
>> conftest.c:19:1: error: insn does not satisfy its constraints:
>> }
>> ^
>> (insn 52 38 23 (set (reg:SI 2 r1 [29])
>> (reg:SI 4 a0)) 99 {movsi_24}
>> (nil))
>>
>> conftest.c:19:1: internal compiler error: in final_scan_insn, at final.c:2891
>> 0x7a56a8 _fatal_insn(char const*, rtx_def const*, char const*, int, char
>> const*)
>> /greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/rtl-error.c:109
>> 0x7a56cf _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
>> /greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/rtl-error.c:120
>> 0x6256c9 final_scan_insn(rtx_def*, _IO_FILE*, int, int, int*)
>> /greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/final.c:2891
>> 0x6258ef final(rtx_def*, _IO_FILE*, int)
>> /greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/final.c:2023
>> 0x626035 rest_of_handle_final
>> /greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/final.c:4427
>> 0x626035 execute
>> /greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/final.c:4502
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
-mkernel argument documentation question
Hi -mkernel is documented as: Enable kernel development mode. The '-mkernel' option sets '-static', '-fno-common', '-fno-cxa-atexit', '-fno-exceptions', '-fno-non-call-exceptions', '-fapple-kext', '-fno-weak' and '-fno-rtti' where applicable. This mode also sets '-mno-altivec', '-msoft-float', '-fno-builtin' and '-mlong-branch' for PowerPC targets. Unfortunately, -fapple-kext does not appear anywhere in the manual. It is listed in darwin.opt with this: fapple-kext Target Report C++ Var(flag_apple_kext) Generate code for darwin loadable kernel extensions Who is comfortable fixing that? -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985
Re: GCC ARM: aligned access
On August 31, 2014 8:19:49 AM CDT, Peng Fan wrote:
>Hi,
>
>I am writing some code and found that system crashed. I found it was
>unaligned access which causes `data abort` exception. I write a piece
>of code and objdump
>it. I am not sure this is right or not.
>
>command:
>arm-poky-linux-gnueabi-gcc -marm -mno-thumb-interwork -mabi=aapcs-linux
>-mword-relocations -march=armv7-a -mno-unaligned-access
>-ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float
>-pipe -O2 -c 2.c -o 2.o
>
>arch is armv7-a and used '-mno-unaligned access'
>
>c code:
>typedef unsigned char u8;
>
>int func(u8 *data)
>
>{
>
>return *(unsigned int *)data;
>
>}
>
>The objdumped asm code is:
>
>Disassembly of section .text.func:
>
>
> :
>
>0: e590 ldr r0, [r0]
>
> 4: e12fff1e bx lr
>
>from the asm code, we can see that 'ldr r0, [r0]' corresponding to
>'*(unsigned int*)data'. is this correct?
>we can not guarantee that pointer data is 4bytes aligned. If pointer
>data is not 4bytes aligned, and aligned
>access check is enabled by setting a hardware bit in arm coprocessor,
>then `data abort` may occur.
>
>
I think this is totally expected. You were passed a u8 pointer which is aligned
for that type (no restrictions likely). You cast it to a type with stricter
alignment requirements. The code is just flawed. Some CPUs handle unaligned
accesses but not your ARM.
If you turn on Wall, do you get a warning?
>Regards,
>Peng.
Re: Account creation disabled on GCC Bugzilla
On September 1, 2014 6:10:40 AM CDT, Jakub Jelinek wrote: >On Mon, Sep 01, 2014 at 12:35:57PM +0200, Frédéric Buclin wrote: >> I again disabled account creation on GCC Bugzilla due to spammers >being >> still very active. 117 user accounts have been created since >yesterday. >> 102 have been identified as spammers and have been disabled. For the >> remaining 15 accounts, I have no evidence that they are spammers. At >> least one of these 15 accounts is valid, so I don't want to blindly >> disable them all, see https://pastebin.mozilla.org/6263691 for the >list >> of still enabled accounts. >> >> 311 bugs have been created on GCC Bugzilla since yesterday. Only 2 >are >> valid bugs. The remaining 309 ones are all spam and have been moved >into >> the 'spam' component and marked as INVALID. > >Thanks. Would e.g. captcha on account creation help? Based on my experience with a musician fan site, the answer is no. We have a very stupid and obvious question that google does not give an answer for. That slows them down enormously. Also there are some sites which list known spam my accounts. My wife uses a couple of them. I think one is stopforumspam.com. you may be able to automate checking for the account there. These are manually reported account by forum admins. --joel > Jakub
Re: stack_pointer_delta related ICE in libgcc on 4.9.1
On 9/3/2014 1:24 PM, Jeff Law wrote: > On 09/03/14 09:56, Bernhard Reutner-Fischer wrote: >> Trying to bootstrap m68k i hit an assert in emit_library_call_value_1 >> that wants to assure that the stack is aligned properly. >> >> PUSH_ROUNDING(GET_MODE_SIZE(QImode)) for m5206 is currently 1 so >> the testcase below has stack_pointer_delta = 1 + 1 + 4 >> but emit_library_call_value_1() has this: >> >>/* Stack must be properly aligned now. */ >>gcc_assert (!(stack_pointer_delta >> & (PREFERRED_STACK_BOUNDARY / BITS_PER_UNIT - 1))); >> >> where 6 & 3 != 0 and ICEs >> >> I am not familier with m68k so i would be glad for any help! >> >> Should the arg be partial? Doesn't look like, no. > No. m68k doesn't pass args in registers. > >> Does m68k use stack save area? From the looks it doesn't. > No. m68k does not pass args in registers, I believe that's a > requirement for needing a stack save area. > >> Is the alignment_pad for QImode arg wrong? > Possibly. Clearly if the stack is to be aligned to larger than a byte > and PUSH_ROUNDING has no adjustment for QImode, then padding is needed > somewhere. And both the caller and callee need to agree on the padding. FWIW For stack alignment RTEMS does not distinguish between any m68k or Coldfire variant. The note says that what comes from the allocator is sufficiently aligned. And that's on a 4-byte boundary. My recollection is that was selected in the m68020 days to avoid the penalty of unaligned accesses -- not to avoid faults. I don't recall if Coldfires fault or handle the unaligned accesses but either way, there is a penalty incurred and you want to avoid it. >> Should PUSH_ROUNDING be changed back to the !CF variant? > Possibly. It's unfortunate the CF chips do something different than > other m68k variants here. If that gives you 4-byte stack alignment, then yes. I think the same stack alignment rules should apply. > The change in behaviour would seem to imply > it's impossible to mix traditional m68k code with CF code, though > perhaps nobody cares about that. I would bet that myself also. I know we don't care. But we provide source and our users compile it themselves with the best options. :) > >> Or is the alignment assert too strict? > I don't think so. > >> Perhaps m5206 is not TARGET_CAS and should not compile this linux-atomic >> in the first place? > No, I don't think so. Coldfire does not have the CAS instruction per http://www.freescale.com/files/dsp/doc/ref_manual/CFPRM.pdf > You might ping Jim Wilson or Richard Sandiford who have both done > coldfire work in the past. I really don't have any experience with the > coldfire bits. > >> (is emit_library_call_value_1 missing a do_pending_stack_adjust() before >> NO_DEFER_POP ? Does not seem relevant for this case though) > Unsure. I haven't done significant work on the m68k in decades, so the > rules around defer_pop have long since been dropped from my memory. If > you can describe why you think it might be missing it'd be helpful for > evaluation. > > My recommendation would be to file a bug report with the reproducer. > m68k isn't nearly as important today as it has been in the past, so > getting developer time to hash through how all this should work for the > coldfire may be difficult. > > jeff > -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985
printf format warning when sizeof(float) == sizeof(double)
Hi
We have a few RTEMS BSPs which use CPUs where float, double,
and long double are the same. This triggers the printf format
warning because promoting float to double results in float.
At least that's what I think is happening. This happens on at
least the h8sx and sh2e.
$ h8300-rtems4.11-gcc -c -Os -Wall -msx warnf.c
warnf.c: In function 'f':
warnf.c:5:3: warning: format '%f' expects argument of type 'double', but
argument 2 has type 'float' [-Wformat=]
printf( "%f", X );
^
warnf.c:5:3: warning: format '%f' expects argument of type 'double', but
argument 2 has type 'float' [-Wformat=]
The code is:
#include
void f(float X)
{
printf( "%f", X );
}
Any ideas? Should I raise a PR?
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
Re: printf format warning when sizeof(float) == sizeof(double)
On September 10, 2014 3:40:05 PM CDT, "Joseph S. Myers" wrote: >On Wed, 10 Sep 2014, Joel Sherrill wrote: > >> Hi >> >> We have a few RTEMS BSPs which use CPUs where float, double, >> and long double are the same. This triggers the printf format >> warning because promoting float to double results in float. > >That was PR c/35649, which should be fixed in 4.9. Thanks for the quick reply. The targets in question were using 4.8. I will check this on the head once my build completes. --joel
m32c libgcc SJLJ detection in libgcc
Hi It looks like the check for SJLJ use by a target starting at line 211 in libgcc/configure.ac does not take into account whether the build included a language that needs this. For RTEMS, we build m32c with only C and this check not being guarded results in needing to provide --disable-sjlj-exceptions on the configure line. Before we didn't have to do this. FWIW I think this same issue is tripped by the h8300. -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985
libgcc - SJLJ probe failing on head on h8300 & m32c
Hi h8300-rtems and m32c-rtems both fail in libgcc during the configure probes of make. configure: WARNING: decimal float is not supported for this target, ignored checking whether fixed-point is supported... no checking whether to use setjmp/longjmp exceptions... unknown configure: error: unable to detect exception model make[1]: *** [configure-target-libgcc] Error 1 Any suggestions? -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985
Re: libgcc - SJLJ probe failing on head on h8300 & m32c
On 11/5/2014 11:10 AM, DJ Delorie wrote: > Last time you mentioned this, I asked what the contents of that > config.log were... I thought I posted it. Anyway, here is the m32c-rtems and h8300-rtems libgcc config.logs. It looks more obvious now. Both targets have an ICE compiling the autoconf probe code. m32c when -mcpu=m32cm and h8300 when -ms. I suppose I need to file these as target specific regressions since 4.9. Thanks for prodding my rusty memory. -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985
mt_allocator.cc assumes sizeof(size_t) == sizeof(void *)
Hi
On m32c-rtems, we have a build error in C++ because size_t
is 16-bits and pointers are 24 bits. m32c-elf probably does not
enable __GTHREAD support like rtems does. Since this is code
shared across targets, what is the best way to fix this?
My first inclination would be to use uintptr_t for the variable
_M_id but I don't know what other impacts that would have
or where else this needs to be fixed.
../../../../../../gcc/libstdc++-v3/src/c++98/mt_allocator.cc: In
function 'void {anonymous}::_M_destroy_thread_key(void*)':
../../../../../../gcc/libstdc++-v3/src/c++98/mt_allocator.cc:77:51:
error: cast from 'void*' to 'size_t {aka unsigned int}' loses precision
[-fpermissive]
size_t _M_id = reinterpret_cast(__id);
^
../../../../../../gcc/libstdc++-v3/src/c++98/mt_allocator.cc: In member
function 'std::size_t __gnu_cxx::__pool::_M_get_thread_id()':
../../../../../../gcc/libstdc++-v3/src/c++98/mt_allocator.cc:630:25:
error: cast from 'void*' to 'std::size_t {aka unsigned int}' loses
precision [-fpermissive]
size_t _M_id = (size_t)v;
^
../../../../../../gcc/libstdc++-v3/src/c++98/mt_allocator.cc:643:52:
warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
__gthread_setspecific(freelist._M_key, (void*)_M_id);
^
Thanks.
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
Re: mt_allocator.cc assumes sizeof(size_t) == sizeof(void *)
Attached is a patch which changes size_t to uintptr_t.
It is enough to let the build continue. But I would appreciate
feedback given the code.
--joel
On 11/7/2014 9:07 AM, Joel Sherrill wrote:
> Hi
>
> On m32c-rtems, we have a build error in C++ because size_t
> is 16-bits and pointers are 24 bits. m32c-elf probably does not
> enable __GTHREAD support like rtems does. Since this is code
> shared across targets, what is the best way to fix this?
>
> My first inclination would be to use uintptr_t for the variable
> _M_id but I don't know what other impacts that would have
> or where else this needs to be fixed.
>
> ../../../../../../gcc/libstdc++-v3/src/c++98/mt_allocator.cc: In
> function 'void {anonymous}::_M_destroy_thread_key(void*)':
> ../../../../../../gcc/libstdc++-v3/src/c++98/mt_allocator.cc:77:51:
> error: cast from 'void*' to 'size_t {aka unsigned int}' loses precision
> [-fpermissive]
>size_t _M_id = reinterpret_cast(__id);
>^
> ../../../../../../gcc/libstdc++-v3/src/c++98/mt_allocator.cc: In member
> function 'std::size_t __gnu_cxx::__pool::_M_get_thread_id()':
> ../../../../../../gcc/libstdc++-v3/src/c++98/mt_allocator.cc:630:25:
> error: cast from 'void*' to 'std::size_t {aka unsigned int}' loses
> precision [-fpermissive]
> size_t _M_id = (size_t)v;
> ^
> ../../../../../../gcc/libstdc++-v3/src/c++98/mt_allocator.cc:643:52:
> warning: cast to pointer from integer of different size
> [-Wint-to-pointer-cast]
> __gthread_setspecific(freelist._M_key, (void*)_M_id);
> ^
> Thanks.
>
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
diff --git a/gcc/expr.c b/gcc/expr.c
index 203e28f..b25396d 100644
--- a/gcc/expr.c
+++ b/gcc/expr.c
@@ -715,12 +715,14 @@ convert_modes (machine_mode mode, machine_mode oldmode,
rtx x, int unsignedp)
if (mode == oldmode)
return x;
- if (CONST_SCALAR_INT_P (x) && GET_MODE_CLASS (mode) == MODE_INT)
+ if (CONST_SCALAR_INT_P (x) && (GET_MODE_CLASS (mode) == MODE_INT
+|| GET_MODE_CLASS (mode) == MODE_PARTIAL_INT))
{
/* If the caller did not tell us the old mode, then there is not
much to do with respect to canonicalization. We have to
assume that all the bits are significant. */
- if (GET_MODE_CLASS (oldmode) != MODE_INT)
+ if (GET_MODE_CLASS (oldmode) != MODE_INT
+ && GET_MODE_CLASS (oldmode) != MODE_PARTIAL_INT)
oldmode = MAX_MODE_INT;
wide_int w = wide_int::from (std::make_pair (x, oldmode),
GET_MODE_PRECISION (mode),
diff --git a/libstdc++-v3/src/c++98/mt_allocator.cc
b/libstdc++-v3/src/c++98/mt_allocator.cc
index 38e17df..828ca82 100644
--- a/libstdc++-v3/src/c++98/mt_allocator.cc
+++ b/libstdc++-v3/src/c++98/mt_allocator.cc
@@ -74,7 +74,7 @@ namespace
__freelist& freelist = get_freelist();
{
__gnu_cxx::__scoped_lock sentry(get_freelist_mutex());
- size_t _M_id = reinterpret_cast(__id);
+ uintptr_t _M_id = reinterpret_cast(__id);
typedef __gnu_cxx::__pool::_Thread_record _Thread_record;
_Thread_record* __tr = &freelist._M_thread_freelist_array[_M_id - 1];
@@ -627,7 +627,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
__freelist& freelist = get_freelist();
void* v = __gthread_getspecific(freelist._M_key);
- size_t _M_id = (size_t)v;
+ uintptr_t _M_id = (uintptr_t)v;
if (_M_id == 0)
{
{
Re: mt_allocator.cc assumes sizeof(size_t) == sizeof(void *)
On 11/7/2014 9:25 AM, Paolo Carlini wrote: > Hi, > > On 11/07/2014 04:07 PM, Joel Sherrill wrote: >> Hi >> >> On m32c-rtems, we have a build error in C++ because size_t >> is 16-bits and pointers are 24 bits. m32c-elf probably does not >> enable __GTHREAD support like rtems does. Since this is code >> shared across targets, what is the best way to fix this? > I don't know the exact opinion of the other library maintainers, but > personally I consider mt_allocator an old experiment, which, definitely, > to make any sense today would need profound changes. In particular, I > don't think we can hope to get something useful from it when size_t is > 16 bits and, more importantly, pointers are 24 bits. Thus, my > recommendation would be just arranging for its code not to break > bootstrap, nothing more than that. OK. I am building now with the size_t changed to uintptr_t. I tried to get the type definition by including but it didn't compile. Using , the bootstrap is moving along. I will post a patch once the bootstrap is finished. Thanks for the quick feedback. > Paolo. > -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985
Re: mt_allocator.cc assumes sizeof(size_t) == sizeof(void *)
On November 8, 2014 9:00:02 AM CST, Jonathan Wakely wrote: >On 7 November 2014 16:56, Joel Sherrill wrote: >> >> On 11/7/2014 9:25 AM, Paolo Carlini wrote: >>> Hi, >>> >>> On 11/07/2014 04:07 PM, Joel Sherrill wrote: >>>> Hi >>>> >>>> On m32c-rtems, we have a build error in C++ because size_t >>>> is 16-bits and pointers are 24 bits. m32c-elf probably does not >>>> enable __GTHREAD support like rtems does. Since this is code >>>> shared across targets, what is the best way to fix this? >>> I don't know the exact opinion of the other library maintainers, but >>> personally I consider mt_allocator an old experiment, which, >definitely, >>> to make any sense today would need profound changes. In particular, >I >>> don't think we can hope to get something useful from it when size_t >is >>> 16 bits and, more importantly, pointers are 24 bits. Thus, my >>> recommendation would be just arranging for its code not to break >>> bootstrap, nothing more than that. > >Agreed. > >> OK. I am building now with the size_t changed to uintptr_t. I tried >to get >> the type definition by including but it didn't compile. > >Did you try std::uintptr_t? Yes. The only surprise was needing to include stdint.h instead of cstdint to get uintptr_t. It built m32c-rtems and then I left a native Linux bootstrap and make check running. I will post the test results and patch Monday. Hopefully that is an OK solution. --joel
Re: mt_allocator.cc assumes sizeof(size_t) == sizeof(void *)
On November 8, 2014 9:00:02 AM CST, Jonathan Wakely wrote: >On 7 November 2014 16:56, Joel Sherrill wrote: >> >> On 11/7/2014 9:25 AM, Paolo Carlini wrote: >>> Hi, >>> >>> On 11/07/2014 04:07 PM, Joel Sherrill wrote: >>>> Hi >>>> >>>> On m32c-rtems, we have a build error in C++ because size_t >>>> is 16-bits and pointers are 24 bits. m32c-elf probably does not >>>> enable __GTHREAD support like rtems does. Since this is code >>>> shared across targets, what is the best way to fix this? >>> I don't know the exact opinion of the other library maintainers, but >>> personally I consider mt_allocator an old experiment, which, >definitely, >>> to make any sense today would need profound changes. In particular, >I >>> don't think we can hope to get something useful from it when size_t >is >>> 16 bits and, more importantly, pointers are 24 bits. Thus, my >>> recommendation would be just arranging for its code not to break >>> bootstrap, nothing more than that. > >Agreed. > >> OK. I am building now with the size_t changed to uintptr_t. I tried >to get >> the type definition by including but it didn't compile. > >Did you try std::uintptr_t? Doh!! You meant putting std:: in front and using cstdint. No. I will try that. Sorry for missing the point.
Re: mt_allocator.cc assumes sizeof(size_t) == sizeof(void *)
On November 8, 2014 9:04:14 AM CST, Joel Sherrill wrote: > > >On November 8, 2014 9:00:02 AM CST, Jonathan Wakely > wrote: >>On 7 November 2014 16:56, Joel Sherrill wrote: >>> >>> On 11/7/2014 9:25 AM, Paolo Carlini wrote: >>>> Hi, >>>> >>>> On 11/07/2014 04:07 PM, Joel Sherrill wrote: >>>>> Hi >>>>> >>>>> On m32c-rtems, we have a build error in C++ because size_t >>>>> is 16-bits and pointers are 24 bits. m32c-elf probably does not >>>>> enable __GTHREAD support like rtems does. Since this is code >>>>> shared across targets, what is the best way to fix this? >>>> I don't know the exact opinion of the other library maintainers, >but >>>> personally I consider mt_allocator an old experiment, which, >>definitely, >>>> to make any sense today would need profound changes. In particular, >>I >>>> don't think we can hope to get something useful from it when size_t >>is >>>> 16 bits and, more importantly, pointers are 24 bits. Thus, my >>>> recommendation would be just arranging for its code not to break >>>> bootstrap, nothing more than that. >> >>Agreed. >> >>> OK. I am building now with the size_t changed to uintptr_t. I tried >>to get >>> the type definition by including but it didn't compile. >> >>Did you try std::uintptr_t? > >Doh!! You meant putting std:: in front and using cstdint. No. I will >try that. This didn't compile. Ended with an error about requiring C++11 in a header file. This code is in a c++98 subdirectory so it dues make sense. I can't cut and paste it at home. >Sorry for missing the point.
arm/thumb broken on head
Hi With gcc, newlib, and binutils head, arm-rtems and arm-eabi both die building libgcc2.c for the Thumb. I don't know if this is a recent gcc change or binutils having added some new error checking. Anyone got any ideas? /users/joel/test-gcc/b-arm-eabi-gcc/./gcc/xgcc -B/users/joel/test-gcc/b-arm-eabi-gcc/./gcc/ -nostdinc -B/users/joel/test-gcc/b-arm-eabi-gcc/arm-eabi/newlib/ -isystem /users/joel/test-gcc/b-arm-eabi-gcc/arm-eabi/newlib/targ-include -isystem /users/joel/test-gcc/gcc/newlib/libc/include -B/users/joel/test-gcc/b-arm-eabi-gcc/arm-eabi/libgloss/arm -L/users/joel/test-gcc/b-arm-eabi-gcc/arm-eabi/libgloss/libnosys -L/users/joel/test-gcc/gcc/libgloss/arm -B/users/joel/test-gcc/install-head/arm-eabi/bin/ -B/users/joel/test-gcc/install-head/arm-eabi/lib/ -isystem /users/joel/test-gcc/install-head/arm-eabi/include -isystem /users/joel/test-gcc/install-head/arm-eabi/sys-include-g -O2 -mthumb -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fno-inline -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -fno-inline -I. -I. -I../../.././gcc -I../../../../gcc/libgcc -I../../../../gcc/libgcc/. -I../../../../gcc/libgcc/../gcc -I../../../../gcc/libgcc/../include -DHAVE_CC_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c ../../../../gcc/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS /tmp/cc9EfnXy.s: Assembler messages: /tmp/cc9EfnXy.s:69: Error: MOV Rd, Rs with two low registers is not permitted on this architecture -- `mov r6,r7' -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985
Re: mt_allocator.cc assumes sizeof(size_t) == sizeof(void *)
On 11/10/2014 10:32 AM, Joseph Myers wrote: > On Sat, 8 Nov 2014, Paolo Carlini wrote: > >> Good. Sorry, if I missed some relatively recent development: is now GCC >> installing its own stdint.h on *all* the supported targets, thus we can >> safely > No; I sent a list of targets missing the information in > <https://gcc.gnu.org/ml/gcc-patches/2013-06/msg00248.html> (possibly out > of date now, but the goal there of unifying uint32_type_node and > c_uint32_type_node etc. still applies). > I just submitted a patch using stdint.h and uintptr_t to gcc-patches. I think this fixes the code in a standard way. I don't know what to do about the list of targets you cited which don't support that. > We are, it appears, still missing stdint.h type information in GCC for > NetBSD, VxWorks, Symbian, LynxOS, QNX, Interix, TPF. Maybe we need to > issue a last call to maintainers caring about those targets to fill in > this information, and failing that deprecate them. -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985
Re: mt_allocator.cc assumes sizeof(size_t) == sizeof(void *)
On 11/10/2014 10:59 AM, Joseph Myers wrote: > On Mon, 10 Nov 2014, Joel Sherrill wrote: > >> On 11/10/2014 10:32 AM, Joseph Myers wrote: >>> On Sat, 8 Nov 2014, Paolo Carlini wrote: >>> >>>> Good. Sorry, if I missed some relatively recent development: is now GCC >>>> installing its own stdint.h on *all* the supported targets, thus we can >>>> safely >>> No; I sent a list of targets missing the information in >>> <https://gcc.gnu.org/ml/gcc-patches/2013-06/msg00248.html> (possibly out >>> of date now, but the goal there of unifying uint32_type_node and >>> c_uint32_type_node etc. still applies). >>> >> I just submitted a patch using stdint.h and uintptr_t to gcc-patches. >> I think this fixes the code in a standard way. I don't know what to >> do about the list of targets you cited which don't support that. > Well, some of them may in fact have their own stdint.h provided by the OS, > or not use libstdc++, but if they use libstdc++ and don't have stdint.h, > the correct fix is for the OS maintainer to add the necessary GCC support > for providing stdint.h. > I will leave it for you all to decide to push my patch or switch to something like Paolo's trick. -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985
Re: arm/thumb broken on head
> Fix is committed to trunk at
> https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=217341.
>
> BR,
> Terry
>
That got past libgcc2 but now it fails building newlib for arm-eabi.
This is just a build of gcc with newlib and libgloss symlinked into
the source. You should be able to duplicate this. But if you need a
preprocessed file, I will send one.
/users/joel/test-gcc/b-arm-eabi-gcc/./gcc/xgcc
-B/users/joel/test-gcc/b-arm-eabi-gcc/./gcc/ -nostdinc
-B/users/joel/test-gcc/b-arm-eabi-gcc/arm-eabi/thumb/newlib/ -isystem
/users/joel/test-gcc/b-arm-eabi-gcc/arm-eabi/thumb/newlib/targ-include
-isystem /users/joel/test-gcc/gcc/newlib/libc/include
-B/users/joel/test-gcc/b-arm-eabi-gcc/arm-eabi/thumb/libgloss/arm
-L/users/joel/test-gcc/b-arm-eabi-gcc/arm-eabi/thumb/libgloss/libnosys
-L/users/joel/test-gcc/gcc/libgloss/arm
-B/users/joel/test-gcc/install-head/arm-eabi/bin/
-B/users/joel/test-gcc/install-head/arm-eabi/lib/ -isystem
/users/joel/test-gcc/install-head/arm-eabi/include -isystem
/users/joel/test-gcc/install-head/arm-eabi/sys-include -mthumb
-DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
-DPACKAGE_VERSION=\"2.1.0\" -DPACKAGE_STRING=\"newlib\ 2.1.0\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I.
-I../../../../../../gcc/newlib/libc/stdlib -DARM_RDI_MONITOR
-fno-builtin -g -O2 -mthumb -c -o lib_a-ecvtbuf.o `test -f
'ecvtbuf.c' || echo '../../../../../../gcc/newlib/libc/stdlib/'`ecvtbuf.c
In file included from
../../../../../../gcc/newlib/libc/stdlib/ecvtbuf.c:70:0:
/users/joel/test-gcc/gcc/newlib/libc/include/stdlib.h: In function
'fcvtbuf':
/users/joel/test-gcc/gcc/newlib/libc/include/stdlib.h:175:8: error:
non-trivial conversion at assignment
char * _EXFUN(fcvtbuf,(double, int, int*, int*, char *));
^
sizetype
int
_64 = _37;
/users/joel/test-gcc/gcc/newlib/libc/include/stdlib.h:175:8: internal
compiler error: verify_gimple failed
0x9602d1 verify_gimple_in_cfg(function*, bool)
../../gcc/gcc/tree-cfg.c:5039
0x86fd06 execute_function_todo
../../gcc/gcc/passes.c:1868
0x870733 execute_todo
../../gcc/gcc/passes.c:1925
Please submit a full bug report,
with preprocessed source if appropriate.
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
Re: arm/thumb broken on head
On 11/11/2014 9:27 AM, Ramana Radhakrishnan wrote: > On Tue, Nov 11, 2014 at 3:16 PM, Joel Sherrill > wrote: >>> Fix is committed to trunk at >>> https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=217341. >>> >>> BR, >>> Terry >>> >> That got past libgcc2 but now it fails building newlib for arm-eabi. >> This is just a build of gcc with newlib and libgloss symlinked into >> the source. You should be able to duplicate this. But if you need a >> preprocessed file, I will send one. >> >> /users/joel/test-gcc/b-arm-eabi-gcc/./gcc/xgcc >> -B/users/joel/test-gcc/b-arm-eabi-gcc/./gcc/ -nostdinc >> -B/users/joel/test-gcc/b-arm-eabi-gcc/arm-eabi/thumb/newlib/ -isystem >> /users/joel/test-gcc/b-arm-eabi-gcc/arm-eabi/thumb/newlib/targ-include >> -isystem /users/joel/test-gcc/gcc/newlib/libc/include >> -B/users/joel/test-gcc/b-arm-eabi-gcc/arm-eabi/thumb/libgloss/arm >> -L/users/joel/test-gcc/b-arm-eabi-gcc/arm-eabi/thumb/libgloss/libnosys >> -L/users/joel/test-gcc/gcc/libgloss/arm >> -B/users/joel/test-gcc/install-head/arm-eabi/bin/ >> -B/users/joel/test-gcc/install-head/arm-eabi/lib/ -isystem >> /users/joel/test-gcc/install-head/arm-eabi/include -isystem >> /users/joel/test-gcc/install-head/arm-eabi/sys-include -mthumb >> -DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\" >> -DPACKAGE_VERSION=\"2.1.0\" -DPACKAGE_STRING=\"newlib\ 2.1.0\" >> -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I. >> -I../../../../../../gcc/newlib/libc/stdlib -DARM_RDI_MONITOR >> -fno-builtin -g -O2 -mthumb -c -o lib_a-ecvtbuf.o `test -f >> 'ecvtbuf.c' || echo '../../../../../../gcc/newlib/libc/stdlib/'`ecvtbuf.c >> In file included from >> ../../../../../../gcc/newlib/libc/stdlib/ecvtbuf.c:70:0: >> /users/joel/test-gcc/gcc/newlib/libc/include/stdlib.h: In function >> 'fcvtbuf': >> /users/joel/test-gcc/gcc/newlib/libc/include/stdlib.h:175:8: error: >> non-trivial conversion at assignment >> char * _EXFUN(fcvtbuf,(double, int, int*, int*, char *)); >> ^ >> sizetype >> int >> _64 = _37; >> /users/joel/test-gcc/gcc/newlib/libc/include/stdlib.h:175:8: internal >> compiler error: verify_gimple failed >> 0x9602d1 verify_gimple_in_cfg(function*, bool) >> ../../gcc/gcc/tree-cfg.c:5039 >> 0x86fd06 execute_function_todo >> ../../gcc/gcc/passes.c:1868 >> 0x870733 execute_todo >> ../../gcc/gcc/passes.c:1925 >> Please submit a full bug report, >> with preprocessed source if appropriate. > That certainly looks like a different issue to the one with Terry's > patch. It does look like something else is broken in one of the tree > passes, maybe worth a bugzilla with pre-processed source and configury > options. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63817 I think that has enough detail. If not, just ask. > > Ramana > >> -- >> Joel Sherrill, Ph.D. Director of Research & Development >> joel.sherr...@oarcorp.comOn-Line Applications Research >> Ask me about RTEMS: a free RTOS Huntsville AL 35805 >> Support Available(256) 722-9985 >> -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985
RE: Localized write permission for OS maintainers
On December 18, 2014 4:14:54 AM CST, Matthew Fortune wrote: >> Does this cover OS specific areas in the gcc/config.gcc file? For >> example: >> >> https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01214.html > >I can’t answer authoritatively but I would expect it does include >OS specific areas of config files. However, as an arch port maintainer >I would be wary of an OS maintainer tweaking something that is >arch specific OS config. Hope that makes sense. That's how it has worked for me in practice. But the RTEMS specific configurery is usually very similar to another CPU-elf and I generally ask for reviews to make sure it is the right thing to do. This also covers RTEMS specific runtime port files. >Thanks, >Matthew --joel (from a mobile device, forgive brevity and typos)
Sebastian Huber appointed RTEMS Co-Maintainer
Hi I am pleased to announce that the steering committee has appointed Sebastian Huber as co-maintainer of the RTEMS target in GCC. This is a reflection of the work has done and community involvement Sebastian has already had. We are looking forward to more of this in the future. Please adjust the MAINTAINERS file accordingly, and Happy Hacking! -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Who owns top level configure.ac?
Hi While looking for something else, I spotted this spelling error in configure.ac: "I suspect your system does not have 32-bit developement " Since this is in the top level directory, I wanted to make sure changing this didn't have to be coordinated with any other projects. If not, then I will prepare patches to fix the spelling. :) -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985
Re: Support for architectures without hardware interlocks
On 1/8/2015 9:01 AM, Eric Botcazou wrote: >> I've worked on a gcc target that was porting an architecture without >> hardware interlock support. Basically, you need to emit nop operations >> to avoid possible hw conflicts. At the moment, this was done by >> patching the gcc scheduler to do so, Another issue to keep is to check >> for hardware conflicts across basic-block boundaries. And not the >> last, is to prohibit/avoid any instruction stream modification after >> scheduler (e.g., peephole optimizations etc.). > That's an overly complex approach, this usually can be done in a simpler way > with a machine-specific pass that runs at the end of the RTL pipeline. > Isn't this similar to needing to fill a delay slot after a branch instruction? My recollection is that some SPARC and MIPS have to deal with that. -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985
Re: GCC 5 Status Report (2015-01-08), Stage 4 to start soon
Piling on here. For RTEMS, we have 5 targets with GCC PRs reported. Ignoring the avr and m32c, we have arm, m68k and nios2 all with regressions since 4.9. I think these PRs are important enough that they should get consideration: + arm: ICE GCC PR64460 segfault for -O2 and xscale + m68k: GCC PR64461 invalid code for all Coldfires + nios2: GCC PR64377 GCC doesn't build. Target independent change broke this target's option processing. The m68k and the nios2 PRs have been git bisected, are narrowed down to the source, and have meaningful comments. I have not been able to get a really useful git bisect on the arm yet (results I have are posted) but no one has even commented. For completeness, the avr and m32c PRs are: + avr: ICE GCC PR63752 + m32c: ICE GCC PR64546 Thanks. --joel On 1/9/2015 5:12 AM, Christian Bruel wrote: > Hi Ramana, > > any chance to get the attribute target support for ARM review in time > for stage 4 ? > > Many thanks > > Christian > > On 01/08/2015 11:32 AM, Jakub Jelinek wrote: >> The trunk is still in Stage 3 now, which means it is open for general >> bugfixing, but will enter Stage 4 on Friday, 16th, end of day (timezone >> of your preference). Once that happens, only wrong-code fixes, regression >> bugfixes and documentation fixes will be allowed, as is normal for >> our release branches too. >> >> There are still a few patches that have been posted during Stage 1, >> please get them committed into trunk before Stage 4 starts. >> >> Still misleading quality data below - some P3 bugs have not been >> re-prioritized. >> >> Quality Data >> >> >> Priority # Change from last report >> --- --- >> P1 39+ 24 >> P2 98+ 15 >> P3 48- 84 >> --- --- >> Total 185- 45 >> >> >> Previous Report >> === >> >> https://gcc.gnu.org/ml/gcc/2014-11/msg00249.html >> -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985
ARM not building on head?
Hi Does anyone else see this? There is a semi-colon at the end of gcc/config/arm/arm.h:771 which I don't think should be there. g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I/users/joel/test-gcc/gcc/gcc -I/users/joel/test-gcc/gcc/gcc/. -I/users/joel/test-gcc/gcc/gcc/../include -I/users/joel/test-gcc/gcc/gcc/../libcpp/include -I/users/joel/test-gcc/gcc/gcc/../libdecnumber -I/users/joel/test-gcc/gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/users/joel/test-gcc/gcc/gcc/../libbacktrace -o arm.o -MT arm.o -MMD -MP -MF ./.deps/arm.TPo /users/joel/test-gcc/gcc/gcc/config/arm/arm.c In file included from ./tm.h:26:0, from /users/joel/test-gcc/gcc/gcc/config/arm/arm.c:27: /users/joel/test-gcc/gcc/gcc/config/arm/arm.c: In function ‘void arm_init_libfuncs()’: /users/joel/test-gcc/gcc/gcc/config/arm/arm.h:771:51: error: expected ‘)’ before ‘;’ token #define MAX_SYNC_LIBFUNC_SIZE (2 * UNITS_PER_WORD); ^ /users/joel/test-gcc/gcc/gcc/config/arm/arm.c:2163:25: note: in expansion of macro ‘MAX_SYNC_LIBFUNC_SIZE’ init_sync_libfuncs (MAX_SYNC_LIBFUNC_SIZE); ^ /users/joel/test-gcc/gcc/gcc/config/arm/arm.c:2163:46: error: expected primary-expression before ‘)’ token init_sync_libfuncs (MAX_SYNC_LIBFUNC_SIZE); ^ make[2]: *** [arm.o] Error 1 make[2]: Leaving directory `/home2/joel/build/b-arm-gcc/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/home2/joel/build/b-arm-gcc' make: *** [all] Error 2 -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985
Re: ARM not building on head?
On January 9, 2015 4:00:38 PM CST, Jan-Benedict Glaw wrote: >On Fri, 2015-01-09 15:05:52 -0600, Joel Sherrill > wrote: >> Hi >> >> Does anyone else see this? There is a semi-colon at the end of >> gcc/config/arm/arm.h:771 which I don't think should be there. >> >> g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE >-fno-exceptions >> -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing >> -Wwrite-strings -Wcast-qual -Wmissing-format-attribute >> -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros >> -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. >> -I/users/joel/test-gcc/gcc/gcc -I/users/joel/test-gcc/gcc/gcc/. >> -I/users/joel/test-gcc/gcc/gcc/../include >> -I/users/joel/test-gcc/gcc/gcc/../libcpp/include >> -I/users/joel/test-gcc/gcc/gcc/../libdecnumber >> -I/users/joel/test-gcc/gcc/gcc/../libdecnumber/dpd -I../libdecnumber >> -I/users/joel/test-gcc/gcc/gcc/../libbacktrace -o arm.o -MT arm.o >-MMD >> -MP -MF ./.deps/arm.TPo /users/joel/test-gcc/gcc/gcc/config/arm/arm.c >> In file included from ./tm.h:26:0, >> from >/users/joel/test-gcc/gcc/gcc/config/arm/arm.c:27: >> /users/joel/test-gcc/gcc/gcc/config/arm/arm.c: In function ‘void >> arm_init_libfuncs()’: >> /users/joel/test-gcc/gcc/gcc/config/arm/arm.h:771:51: error: expected >> ‘)’ before ‘;’ token >> #define MAX_SYNC_LIBFUNC_SIZE (2 * UNITS_PER_WORD); >>^ >> /users/joel/test-gcc/gcc/gcc/config/arm/arm.c:2163:25: note: in >> expansion of macro ‘MAX_SYNC_LIBFUNC_SIZE’ >> init_sync_libfuncs (MAX_SYNC_LIBFUNC_SIZE); >> ^ >> /users/joel/test-gcc/gcc/gcc/config/arm/arm.c:2163:46: error: >expected >> primary-expression before ‘)’ token >> init_sync_libfuncs (MAX_SYNC_LIBFUNC_SIZE); >> ^ >> make[2]: *** [arm.o] Error 1 >> make[2]: Leaving directory `/home2/joel/build/b-arm-gcc/gcc' >> make[1]: *** [all-gcc] Error 2 >> make[1]: Leaving directory `/home2/joel/build/b-arm-gcc' >> make: *** [all] Error 2 > >Sure, my build robot found it as well; it's probably just a typo. Easy >to fix. It was easy to and lets the build get to an ICE. I will retest Monday and hope someone fixes it. I am sure someone will want it fixed. :) >MfG, JBG --joel
RTEMS FORTRAN Pattern Failures
Hi RTEMS has pretty good FORTRAN test results on SPARC and PowerPC but a number fail in pattern matching. It appears to be a CR/LF issue. I have attached the output of f77-edit-x-out (out.txt) and the associated fragment (run.txt) from the test run log which shows the pattern not matching. Based on breaking at the device driver, there is definitely a \r and \n at the end of each line printed and it is intentional from RTEMS' perspective. Is there some magic testsuite setting to tell DejaGNU about this? Some other suggestion to make the output pattern matching work. Tobias and I have taken a couple of swings at this in the past but never gotten a solution. I am hoping we are luckier this time. :) Thanks. -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 1 2 3 1 2 3 *** EXIT code 0 Executing on host: /home2/joel/build/b-sparc-fortran/gcc/testsuite/gfortran/../../gfortran -B/home2/joel/build/b-sparc-fortran/gcc/testsuite/gfortran/../../ -B/home2/joel/build/b-sparc-fortran/sparc-rtems4.11/./libgfortran/ /users/joel/test-gcc/gcc-4.9-branch/gcc/testsuite/gfortran.dg/g77/f77-edit-x-out.f gfortran_tg.o -fno-diagnostics-show-caret -fdiagnostics-color=never -Os -pedantic-errors -B/users/joel/test-gcc/install-4.9-branch/sparc-rtems4.11/sis/lib/ -specs bsp_specs -qrtems -mcpu=cypress /home2/joel/build/b-sparc-fortran/rtems_gcc_main.o -B/home2/joel/build/b-sparc-fortran/sparc-rtems4.11/./libgfortran/.libs -L/home2/joel/build/b-sparc-fortran/sparc-rtems4.11/./libgfortran/.libs -Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -lm -o ./f77-edit-x-out.exe(timeout = 300) spawn -ignore SIGHUP /home2/joel/build/b-sparc-fortran/gcc/testsuite/gfortran/../../gfortran -B/home2/joel/build/b-sparc-fortran/gcc/testsuite/gfortran/../../ -B/home2/joel/build/b-sparc-fortran/sparc-rtems4.11/./libgfortran/ /users/joel/test-gcc/gcc-4.9-branch/gcc/testsuite/gfortran.dg/g77/f77-edit-x-out.f gfortran_tg.o -fno-diagnostics-show-caret -fdiagnostics-color=never -Os -pedantic-errors -B/users/joel/test-gcc/install-4.9-branch/sparc-rtems4.11/sis/lib/ -specs bsp_specs -qrtems -mcpu=cypress /home2/joel/build/b-sparc-fortran/rtems_gcc_main.o -B/home2/joel/build/b-sparc-fortran/sparc-rtems4.11/./libgfortran/.libs -L/home2/joel/build/b-sparc-fortran/sparc-rtems4.11/./libgfortran/.libs -Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -lm -o ./f77-edit-x-out.exe PASS: gfortran.dg/g77/f77-edit-x-out.f -Os (test for excess errors) spawn sis -i ./f77-edit-x-out.exe 1 2 3 1 2 3 *** EXIT code 0 PASS: gfortran.dg/g77/f77-edit-x-out.f -Os execution test FAIL: gfortran.dg/g77/f77-edit-x-out.f -Os output pattern test, is 1 2 3 1 2 3 , should match ^1 2 3( | | )1 2 3( | | )$
Re: RTEMS FORTRAN Pattern Failures
On 1/12/2015 10:30 AM, Andreas Schwab wrote: > Joel Sherrill writes: > >> FAIL: gfortran.dg/g77/f77-edit-x-out.f -Os output pattern test, is 1 2 3 >> 1 2 3 >> >> , should match ^1 2 3( >> | >> |)1 2 3( >> | >> |)$ > Where is the \r gone? The pattern has (\n|\r\n|\r). I am not exactly sure what you mean but when I run the test by itself from the command and redirect the output to a file, this is what the output looks like: 0002031203233200a0d2031203233200a0d 000 1 2 3 \r \n 1 2 3 \r \n 0100a0d2a2a202a584554496320646f2065 010 \r \n * * * E X I T c o d e 0200d30000a 020 0 \r \n 023 It looks like we have \r\n at the end of each line. Is it possible it is not CR/LF but the EXIT code message confusing the pattern? > Andreas. > -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985
Re: RTEMS FORTRAN Pattern Failures
On 1/12/2015 1:14 PM, Tobias Burnus wrote:
> Joel Sherrill wrote:
>> On 1/12/2015 10:30 AM, Andreas Schwab wrote:
>>> Joel Sherrill writes:
>>>
>>>> FAIL: gfortran.dg/g77/f77-edit-x-out.f -Os output pattern test, is 1 2 3
>>>> 1 2 3
>>>>
>>>> , should match ^1 2 3(
>>>> |
>>>> |)1 2 3(
>>>> |
>>>> |)$
>>> Where is the \r gone? The pattern has (\n|\r\n|\r).
>> I am not exactly sure what you mean but when I run the test
>> by itself from the command and redirect the output to a file,
>> this is what the output looks like:
>>
>> 0002031203233200a0d2031203233200a0d
>> 000 1 2 3 \r \n 1 2 3 \r \n
>> 0100a0d2a2a202a584554496320646f2065
>> 010 \r \n * * * E X I T c o d e
>> 0200d30000a
>> 020 0 \r \n
>> 023
>>
>> It looks like we have \r\n at the end of each line.
>>
>> Is it possible it is not CR/LF but the EXIT code message confusing the
>> pattern?
> Contrary to Andreas, I do see \r in run.txt – at least when I look at
> the file when saved from Thunderbird. Namely, the output is (sp = space,
> nl = \n, cr = \r):
>
> 1 sp 2 sp sp 3 cr cr nl
> 1 sp 2 sp sp 3 cr cr nl
> cr cr nl
> *** EXIT code 0 cr cr nl
run.txt is the cut and paste of the log file which reflects DejaGNU's
view of the
run. I think that means we are looking at output from the verbose command
invoked here in remote.exp around line 1030:
verbose -log "Executed $prog, status $status" 2
if {![string match "" $output]} {
verbose -log -- "$output" 2
}
> Namely: I do not see CR-NL but CR-CR-NL. That looks rather odd and does
> not match what you get when you manually run the program. Looing at
> other lines like "spawn sis -i ./f77-edit-x-out.exe", they have a CR-NL,
> i.e. only a single CR. Thus, the question is what inserts an additional
> "\r" into the output.
I think it is the verbose procedure in runtest.exp. It sets "newline" to 1
and prints all messages including "Executing on host:..." with a newline.
Double check me on that.
>
> Additionally, I think you are right that the "*** EXIT code 0" also
> causes problems with the pattern.
Details below but this is standard DejaGNU output when the target
doesn't return
an exit code.
> Can you try the following:
>
> a) Replace the pattern by "1 2 3(\n|\r\r\n|\r)" (twice), note the
> duplicated "\r"
> b) Remove the "dg-output "\$" line
>
> [Best would be if you could try them also separately.] My bet would be
> that doing (a) and (b) will succeed, while only (a) and (b) will fail.
>
>
> If using (a) [alone or together with (b)] works, you should really find
> out what inserts the "\r", especially as it does not appear if you
> manually run the program. "\r\r\n" is definitely not a pattern I would
> like to see in the test file.
I assume the file in question is
gcc/gcc/testsuite/gfortran.dg/g77/f77-edit-x-out.f
(a) alone didn't make it pass.
(b) alone didn't make it pass.
(a) and (b) together did not make it pass
Does this file get copied or something else during the process that
would eliminate
edits having an impact?
> If (b) works [alone or together with (a)]: Any chance that you silence
> the "\r\r\n*** EXIT code 0\r\r\n" output? I think it could potentially
> confuse other test cases and it doesn't belong there. – I am also
> inclined not to remove the '\$', unless there are very compelling
> reasons to do so.
The "***EXIT code ..." message is the standard DejaGNU message which is used
on targets which do not directly return an exit code. This is in testglue.c
in the DejaGNU installation. Look in the body of ORIG_EXIT. It is
/usr/share/dejagnu/testglue.c on the computer I am here.
If it is the ***EXIT line and the compare really doesn't see the \r,
what would be
needed to try that?
Is there an easy way to take out.txt and just force it against this .exp
pattern?
>
> Tobias
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
Re: RTEMS FORTRAN Pattern Failures
On 1/12/2015 2:49 PM, Tobias Burnus wrote:
> Joel Sherrill wrote:
>> run.txt is the cut and paste of the log file which reflects DejaGNU's
>> view of the run.
> Which means that it hopefully matches every bit of the original output
> and that no editor interferes by adding or removing line breaks.
>
>
>> Additionally, I think you are right that the "*** EXIT code 0" also
>> causes problems with the pattern.
>> Details below but this is standard DejaGNU output when the target
>> doesn't return
>> an exit code.
> Good to know. If the pattern is known, one can add it to the pattern.
>
>
>>> Can you try the following:
>>>
>>> a) Replace the pattern by "1 2 3(\n|\r\r\n|\r)" (twice), note the
>>> duplicated "\r"
>>> b) Remove the "dg-output "\$" line
>>>
>>> [Best would be if you could try them also separately.] My bet would be
>>> that doing (a) and (b) will succeed, while only (a) and (b) will fail.
>>>
>>>
>>> If using (a) [alone or together with (b)] works, you should really find
>>> out what inserts the "\r", especially as it does not appear if you
>>> manually run the program. "\r\r\n" is definitely not a pattern I would
>>> like to see in the test file.
>> I assume the file in question is
>> gcc/gcc/testsuite/gfortran.dg/g77/f77-edit-x-out.f
> Yes.
>
>> (a) alone didn't make it pass.
>> (b) alone didn't make it pass.
>> (a) and (b) together did not make it pass
>>
>> Does this file get copied or something else during the process that
>> would eliminate edits having an impact?
> I don't think so. Too bad that it didn't seem to help.
>
>> Is there an easy way to take out.txt and just force it against this
>> .exp pattern?
> Well, you could try whether PERL is able to match it, i.e. something
> like "cat file | perl ..." if you manage to get the exact output into a
> file (esp. with the right number of \r and \n, including the last line).
> I don't know whether that's really identical but it should come close to
> how DejaGNU matches the pattern.
>
> Example - I use printf instead of a file:
>
> printf '1 2 3\n1 2 3\n\n*** EXIT code 0' \
>| perl -e '$in = join("", ); if ($in =~ m/^1 2 3(\n|\r\n|\r)1
> 2 3(\n|\r\n|\r)((\n|\r\n|\r)\*\*\* EXIT code 0)?$/s) { print
> "matched\n" } else { print "not matched\n" };'
That was very close.
cat out.txt | \
perl -e '$in = join("", ); if ($in =~ m/^1 2 3(\n|\r\n|\r)1 2
3(\n|\r\n|\r)((\n|\r\n|\r)\*\*\* EXIT code 0)(\n|\r\n|\r)?$/s) { print
"matched\n" } else { print "not matched\n" };'
I think I mainly fixed the first line to have two spaces between the 2 and 3
and added another the EOL pattern at the end.
That just leaves translating that back into DejaGNU/Expect. :)
> Tobias
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
Re: RTEMS FORTRAN Pattern Failures
On 1/12/2015 3:18 PM, Tobias Burnus wrote:
> Hi Joel,
>
> Am 12.01.2015 um 22:04 schrieb Joel Sherrill:
>> That was very close.
>>
>> cat out.txt | \
>>perl -e '$in = join("", ); if ($in =~ m/^1 2 3(\n|\r\n|\r)1 2
>> 3(\n|\r\n|\r)((\n|\r\n|\r)\*\*\* EXIT code 0)(\n|\r\n|\r)?$/s) { print
>> "matched\n" } else { print "not matched\n" };'
> That won't work on systems which don't print EXIT. You have to move the
> ")" from after the "0" to before the "?" to make the whole part as
> optional (the ? applies to the preceding token).
That should be this:
cat out.txt | \
perl -e '$in = join("", ); if ($in =~ m/^1 2 3(\n|\r\n|\r)1 2
3(\n|\r\n|\r)((\n|\r\n|\r)\*\*\* EXIT code 0(\n|\r\n|\r))?$/s) { print
"matched\n" } else { print "not matched\n" };'
>> I think I mainly fixed the first line to have two spaces between the 2 and 3
>> and added another the EOL pattern at the end.
> The former was a bug (feature) of Thunderbird, which ate the second
> space, the second, I forgot.
:) I wondered about that when I started this thread. I almost compressed the
files I attached to avoid mailer issues.
>> That just leaves translating that back into DejaGNU/Expect. :)
> Well, that's simple: Either remove all "dg-output" from the test case
> and add the string between "m/" and "/s" instead of ... in
>
> C { dg-output "..." }
>
> You additionally have to change "\*" to "\\*" and "$" to "\$".
>
> Or, alternatively, only modify the last "dg-output" by replacing "\$" by
> the string starting with "((" and ending with "$". (Again, you have to
> replace \* by \\* and $ by \$.)
>
> That should be all. I wonder whether that now works or still fails.
>
> Can you try whether this works (see attachment)?
I tried it and it didn't work. :(
> Tobias
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
Warnings in libgcc/emutls.c
Hi I noticed the arm-rtems (and I assume arm-eabi) have these warnings about calloc() and realloc(). Can this file include stdlib.h to resolve this? ../../../gcc/libgcc/emutls.c: In function '__emutls_get_address': ../../../gcc/libgcc/emutls.c:159:13: warning: implicit declaration of function 'calloc' [-Wimplicit-function-declaration] arr = calloc (size + 1, sizeof (void *)); ^ ../../../gcc/libgcc/emutls.c:159:13: warning: incompatible implicit declaration of built-in function 'calloc' ../../../gcc/libgcc/emutls.c:159:13: note: include '' or provide a declaration of 'calloc' ../../../gcc/libgcc/emutls.c:171:13: warning: implicit declaration of function 'realloc' [-Wimplicit-function-declaration] arr = realloc (arr, (size + 1) * sizeof (void *)); ^ ../../../gcc/libgcc/emutls.c:171:13: warning: incompatible implicit declaration of built-in function 'realloc' ../../../gcc/libgcc/emutls.c:171:13: note: include '' or provide a declaration of 'realloc' -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985
Re: organization of optimization options in manual
On 1/15/2015 12:15 AM, Jeff Law wrote: > On 01/14/15 23:12, Sandra Loosemore wrote: >> On 01/14/2015 08:41 PM, Jeff Law wrote: >>> With the section being ~60 pages, my first thought is we have way too >>> many options! >> Heh, at least we have documentation for all those options. :-) >> >>> But that's not likely to change. Though perhaps the >>> process will encourage some culling of options that really don't make >>> sense anymore. >> Would we want to remove useless options outright, or deprecate them for >> a while with removal to happen at some future time, or just deprecate >> them and/or document that they are not useful? > We typically deprecate and leave it as a nop for a major release cycle, > then do final removal the next major release. > >> I guess it can't be any worse than it is now, though, where the whole 60 >> pages is essentially a "misc bucket". I'll see if I can put together a >> plan for splitting things up if there are too many leftovers maybe >> others can help by suggesting different/additional categories. > Sounds good. I think just starting with the list & creating the buckets > with the list. Then post here and we'll iterate and try to nail that > down before you start moving everything in the .texi file. I think this is a great idea. It may make sense for some options to end up with details in one section and a reference in another. I am wondering if there are some common questions users ask about options which could be addressed like this. Disabling C++ exceptions and RTTI plus the floating point options for performance which usually come up in Intel C vs GCC benchmarks come to mind. > jeff -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985
Re: organization of optimization options in manual
On January 17, 2015 8:34:04 AM CST, Gary Funck wrote: >On 01/14/15 23:15:59, Jeff Law wrote: >> Sounds good. I think just starting with the list & creating the >buckets >> with the list. Then post here and we'll iterate and try to nail that >down >> before you start moving everything in the .texi file. > >Something to consider, if the optimization options are re-worked: >Arrange the -O options such that -O1 can be described by a >distinct set of specific optimizations enabled (or disabled) >in addition to -O0, and -O2 would be described as a composite >of specific optimizations applied to -O1 and so on. (This >might require the addition of new optimization options.) > >For completeness, if a specific optimization requires >certain passes or the assertion of other options, that should >somehow be encoded internally within the compiler. > >This would potentially make it easier to find which optimization >(or pass) is causing a regression and might make it easier >for users to understand the exact effect of a particular -O option. Make sure whatever pattern is followed for optimizations is followed for warnings. It is nice to know when adding an option actually is needed. >- Gary --joel
