from:"Joel"

> I think it's desirable for development that *happens on* the personal and 
> vendor branches to be visible in gcc-cvs - that is different from things 
> getting merged into them.
> 
> Likewise for the refs/heads/devel/* development branches - 
> non-fast-forward pushes are not permitted there, but such branches can 
> expect to have lots of merges from master, and it's the actual development 
> taking place *on* the branches - the new commits - that is of interest to 
> see on gcc-cvs, not the merging of existing commits.

Would it be sufficient to say that some branches would only
trigger a summary email, but not individual commit emails?
The downside is that you would not be getting the "diff" for
commits that are really completely new. But on the other hand,
it would fit better with the fact that user branches could have
frequent re-basing, thus causing the same commit email being sent
over and over at each rebase operation. It would also answer
the issue of the number of emails being sent when people are doing
a merge which brings in more commits than the max-emails number.

-- 
Joel

Re: Whitespace at the start of first line of commit

> Unfortunately, that's not as simple to implement as I'd hoped, because 
> git.py:git_run removes all leading and trailing whitespace from the output 
> of the git command it runs, so the code checking commit messages can't 
> tell whether there was whitespace at the start of the first line (or the 
> end of the last line, I suppose) at all.  I don't know what git commands 
> the hooks are using that might depend on removing leading whitespace (no 
> doubt the removal of trailing whitespace is needed in various places to 
> remove a final newline output by commands giving single-line output).

A quick run of the testsuite reveals that this assumption is made
all over. I am opposed to having this feature be a standard feature
of the git-hooks, so you wouldn't have to add an ad hoc check.
The way I would do it is by enhancing the git_run function to check
for a parameter named "_no_strip" and block the strip() operation
when passed as True. You can then implement your check using the usual
git interface, with the extra "_no_strip=True" parameter.

Do open a GitHub issue if you'd like me to add this check to
the git-hooks. I will likely give it less priority because
you'll have a way to implement it on your on, but I will get to it
eventually.

-- 
Joel

Re: Whitespace at the start of first line of commit

> A quick run of the testsuite reveals that this assumption is made
> all over. I am opposed to having this feature be a standard feature
> of the git-hooks, so you wouldn't have to add an ad hoc check.
> The way I would do it is by enhancing the git_run function to check
> for a parameter named "_no_strip" and block the strip() operation
> when passed as True. You can then implement your check using the usual
> git interface, with the extra "_no_strip=True" parameter.
> 
> Do open a GitHub issue if you'd like me to add this check to
> the git-hooks. I will likely give it less priority because
> you'll have a way to implement it on your on, but I will get to it
> eventually.

I apologize.  Re-reading myself, I'm mixing various issues and not being
clear as a result, let me rephrase:

   For your immediate need, I am proposing a way to adapt the git_run
   function so you can use it to implement your check. Another option
   is to use Python's subprocess module directly, but I think this will
   be more work than what I suggest.

   For the longer term, you'll have access to a hook that you can
   use to call a script to validate an update. In that hook, you'll
   have total implementation freedom, so you can implement that check
   there, and not have to worry about that implementation detail in
   the git-hooks.

   Also longer term, I can add that check directly in the git-hooks
   as well. I don't remember anyone ever really making this kind
   of mistake, but it doesn't mean that it's unlikely either, nor
   that it would be specific to the GCC community. Hence the merit
   of having it in git-hooks directly.

-- 
Joel

Re: gcc-cvs mails for personal/vendor branches for merge commits

> AFAIU, we have access to more fine-grained information; isn’t it possible
> to differentiate “new” commits, from ‘merges’ and from ‘rebases’?
> (because a ‘new’ commit does not have the extra fields set up for merges
>  and rebases).

In my opinion, this would create a lot of complication for the benefits
being gained. I also think that the more variations of behaviors you
introduce, the harder is becomes for people to know what's right and
what's not expected.  People then start getting surprised and start
asking about it. At best, it's just a quick answer, but in some cases,
it takes time to remember why we set things up the way they are and why
it doesn't make sense to change it. Over the years, I have really learnt
to enjoy the benefits of consistency, even if it is means some areas
are suboptimal. The "suboptimality" can still be a better compromise
overall than a superengineered system.

> For example, I’d like to know that user/fred has rebased the branch i’m
> interested in but OTOH, would not find the per-commit mails useful (so a
> summary there is good).
> 
> If a push contains a combination of things - new work, merged and rebased
> commits - then there would have to be some way to react to split or aggregate
> the messages / diffs per commit id.

-- 
Joel

Re: gcc-cvs mails for personal/vendor branches for merge commits

> > Would it be sufficient to say that some branches would only
> > trigger a summary email, but not individual commit emails?
> 
> Maybe that will end up being appropriate for users / vendors branches, if 
> we can't effectively distinguish rebased commits from new ones.  But for 
> shared fast-forward-only development branches, I think the individual 
> commit emails are appropriate for commits new to the branch, while a 
> summary email is appropriate for merges to the branch.

OK. I will see if there is a reasonable way to provide this.

-- 
Joel

Re: gcc-cvs mails for personal/vendor branches for merge commits

> > > AFAIU, we have access to more fine-grained information; isn’t it possible
> > > to differentiate “new” commits, from ‘merges’ and from ‘rebases’?
> > > (because a ‘new’ commit does not have the extra fields set up for merges
> > >   and rebases).
> > 
> > In my opinion, this would create a lot of complication for the benefits
> > being gained. I also think that the more variations of behaviors you
> > introduce, the harder is becomes for people to know what's right and
> > what's not expected.  People then start getting surprised and start
> > asking about it. At best, it's just a quick answer, but in some cases,
> > it takes time to remember why we set things up the way they are and why
> > it doesn't make sense to change it. Over the years, I have really learnt
> > to enjoy the benefits of consistency, even if it is means some areas
> > are suboptimal. The "suboptimality" can still be a better compromise
> > overall than a superengineered system.
> 
> Spamming the list with emails every time someone merges master to their
> development branch sounds highly suboptimal, and likely to lead to disabling
> email entirely for those branches.  Is it so complicated to send a single
> email for a merge commit or non-fast-forward push?

Well, no. I was going so say that this is what I have been proposing
all along, except the way you phrased your suggestion above makes
me think that perhaps you want something more automatic, where the hooks
decide dynamically, rather than the choice being made by configuration.
So it's not exactly the same, but quite similar in spirit.  I think
we can find ways that will satisfy the need for fewer emails without
having to have that extra logic, though.

Also, you guys have to understand that you are all coming to me from
multiple directions at the same time, and making requests that are
not always easy to reconcile. I do completely understand that getting
hundreds of emails because of a merge into a development branch is far
from optimal, and it's absolutely not what I am suggesting we do here.
In fact, you'll see that I told Joseph in a separate mail that I will
think this over and try to come up with something that answers the
situation he described. What I am alerting people to is trying to
have special-case handling for every scenario we can conceive.

I'm wondering if we wouldn't be better off having this discussion live
over a meeting or a series of meetings...

-- 
Joel

Re: Architecture instruction utilization rates

2020-04-13 Thread Joel Sherrill

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

2020-04-17 Thread Joel Sherrill

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

2020-04-20 Thread Joel Sherrill

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

2020-04-20 Thread Joel Sherrill

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

2020-04-20 Thread Joel Sherrill

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

2020-04-21 Thread Joel Sherrill

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

2020-04-22 Thread Joel Sherrill

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

2020-06-18 Thread Joel Sherrill

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

2020-06-25 Thread Joel Sherrill

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

2020-06-25 Thread Joel Sherrill

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
>

Re: Coding style for C++ constructs going forward

2020-08-07 Thread Joel Brobecker

Hi Luis,

> cc-ing the GCC mailing list, as we may want to use the same coding style for
> GDB and GCC.
> 
> Yesterday I brought this topic up on IRC. I notice we started using more and
> more the "auto" keyword. In some cases, this is actually useful and makes
> the code a bit more compact. GDB has been using those more often, whereas
> GCC, for example, isn't using those too much.
> 
> Looking at the coding standards for GCC
> (https://gcc.gnu.org/codingconventions.html), I don't see anything dictating
> best practices for "auto" use.
> 
> I guess it is a consensus that "auto" is a good fit when dealing with
> iterators, lambda's and gnarly templates (but only when the type is already
> obvious from its use).
> 
> There are other situations where "auto" may make things a little more
> cryptic when one wants to figure out the types of the variables. One example
> of this is when you have a longer function, and you use "auto" in a variable
> that lives throughout the scope of the function. This means you'll need to
> go back to its declaration and try to figure out what type this particular
> variable has.
> 
> Pedro has pointed out LLVM's coding standards for "auto", which we may or
> may not want to follow/adopt: 
> https://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable
> 
> It sounds like a reasonable idea to me. Thoughts?

Thanks for the pointer to LLVM's CS guideline. FWIW, it's explaining
quite nicely what I had in the back of my mind. I think it would be
a good starting point, at least for discussing whathever guidelines
we might want to adopt in GDB.

> Are there other C++ constructs people think would benefit from a more formal
> style guideline? As we move to newer C++ standards over time, it is more
> likely we will start using newer constructs, and some of those may make the
> code potentially less readable.

-- 
Joel

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

2020-09-12 Thread Joel Sherrill

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
>>
>

Re: Git rejecting branch merge

> > The problem is that the push fails witih:
> > 
> > remote: *** The following commit was rejected by your 
> > hooks.commit-extra-checker script (status: 1)
> > remote: *** commit: 03e87724864a17e22c9b692cc0caa014e9dba6b1
> > remote: *** The first line of a commit message should be a short
> > description of the change, not a single word.
> > remote: error: hook declined to update
> 
> Joel, my understanding was that commit-extra-checker was the right setting 
> to use for a hook that should check new commits - commits new to the 
> repository, not commits already in the repository that are being added to 
> the ancestry of a ref.  Is that not the case?  All the checks I've 
> implemented via that hook are only intended to apply to commits that are 
> new to the repository.

That's correct. The commit-extra-checker is called using the same list
of "added commits" as the other checks implemented in the hooks, and
that list excludes all commits accessible from existing references
in the repository.

-- 
Joel

Re: Git rejecting branch merge

> > That's correct. The commit-extra-checker is called using the same list
> > of "added commits" as the other checks implemented in the hooks, and
> > that list excludes all commits accessible from existing references
> > in the repository.
> 
> Since 03e87724864a17e22c9b692cc0caa014e9dba6b1 has been in the repository 
> (on master) since before GCC 10 branched, something must be going wrong 
> for a push to be rejected based on a check of that commit.

OK. Can you create a tarball of the GCC's bare repository as it is now,
and give me access to both this tarball and the branch that the user
was trying to update, I can try to spend a bit of time this weekend
trying to reproduce and then investigating it. And just for the avoidance
of doubt, if I could get the git command that was used to attempt
the push, this would avoid wasting time investigating the wrong thing.

In the meantime, perhaps you can add a workaround in your script
that calls git to check whether the commit already exists in one
of the references, and if it does, just bail?

-- 
Joel

Re: Git rejecting branch merge

On Tue, Sep 29, 2020 at 10:01:23AM -0700, Joel Brobecker wrote:
> > > That's correct. The commit-extra-checker is called using the same list
> > > of "added commits" as the other checks implemented in the hooks, and
> > > that list excludes all commits accessible from existing references
> > > in the repository.
> > 
> > Since 03e87724864a17e22c9b692cc0caa014e9dba6b1 has been in the repository 
> > (on master) since before GCC 10 branched, something must be going wrong 
> > for a push to be rejected based on a check of that commit.
> 
> OK. Can you create a tarball of the GCC's bare repository as it is now,
> and give me access to both this tarball and the branch that the user
> was trying to update, I can try to spend a bit of time this weekend
> trying to reproduce and then investigating it. And just for the avoidance
> of doubt, if I could get the git command that was used to attempt
> the push, this would avoid wasting time investigating the wrong thing.

Good news; If I read the code correctly, I think I found the source
of your issue, and the fix should be relatively simple. The data above
would be useful to confirm we're looking at the same issue, though.

> In the meantime, perhaps you can add a workaround in your script
> that calls git to check whether the commit already exists in one
> of the references, and if it does, just bail?

-- 
Joel

Re: Git rejecting branch merge

On Tue, Sep 29, 2020 at 07:16:45PM +0200, Jan Hubicka wrote:
> > On Tue, 29 Sep 2020, Joel Brobecker wrote:
> > 
> > > > > That's correct. The commit-extra-checker is called using the same list
> > > > > of "added commits" as the other checks implemented in the hooks, and
> > > > > that list excludes all commits accessible from existing references
> > > > > in the repository.
> > > > 
> > > > Since 03e87724864a17e22c9b692cc0caa014e9dba6b1 has been in the 
> > > > repository 
> > > > (on master) since before GCC 10 branched, something must be going wrong 
> > > > for a push to be rejected based on a check of that commit.
> > > 
> > > OK. Can you create a tarball of the GCC's bare repository as it is now,
> > > and give me access to both this tarball and the branch that the user
> > > was trying to update, I can try to spend a bit of time this weekend
> > > trying to reproduce and then investigating it. And just for the avoidance
> > > of doubt, if I could get the git command that was used to attempt
> > > the push, this would avoid wasting time investigating the wrong thing.
> > 
> > It's /git/gcc.git on sourceware (I think you have shell access, or can git 
> > clone --mirror to get a full bare copy).  
> > refs/users/hubicka/heads/honza-gcc-benchmark-branch currently points to 
> > c478047c0fd71e8bd8e069c729b57a89b75ee004, "Add changelog".  I don't know 
> > exactly what Honza is pushing there (whether it's a merge or a rebase), 
> > but whatever he's pushing, the hook should not be checking commits that 
> > are already in the repository.
> 
> I did the following (and perhaps you can do it for me)
> 
> git branch -D me/honza-gcc-benchmark-branch
> git checkout master
> git co -b me/honza-gcc-benchmark-branch
> git push -f
> 
> Which I hope should replace the existing (old) branch by a copy of
> current trunk on which I could do more of tuning tests.

So, IIUC, you're trying to replace the old
refs/users/hubicka/heads/honza-gcc-benchmark-branch
with whatever is on master at this moment, is that correct
(that would wipe whatever changes you've made in your old
branch)?

For instance, currently master is pointing to commit
adcf8a11c772e7a0c64d4ae3eb19a520566f32b9.

-- 
Joel

Re: Git rejecting branch merge

2020-10-01 Thread Joel Brobecker

> I wonder I can get the branch moved, so I can do the benchmarking :)
> Any suggestions how to do that?

Unfortunately, I think the only way (sort of adding the suggested
workaround in the commit-extra-checker script), is to update
the branch directly in the bare repository on sourceware.org.
This would cause the hooks to be by-passed, I believe, so no emails.
If those are desired, and we remember to keep track of the branch's HEAD
before and after, we can call the hook manually to get them sent.

I have login access on the hosting machine, but through an unprivileged
user, so I don't think I can do this for you, unfortunately.

-- 
Joel

Re: Git rejecting branch merge

2020-10-01 Thread Joel Brobecker

> > I wonder I can get the branch moved, so I can do the benchmarking :)
> > Any suggestions how to do that?

I just installed a small patch, hot-fix style which I am hoping will
fix your problem. Can you try it? It passes the testsuite, so the change
should be safe.

Let me know how it goes. I will finish the work over the weekend
so as to replace the local diff by an actual commit (after review
from a coworker of mine).

-- 
Joel

Re: Git rejecting branch merge

2020-10-02 Thread Joel Brobecker

> > I can confirm I was able to delete a branch on remove server:
> >
> > $ git push origin --delete refs/users/marxin/heads/gfc-trailing-spec
> > To git+ssh://gcc.gnu.org/git/gcc.git
> >   - [deleted] refs/users/marxin/heads/gfc-trailing-spec
> 
> That's because I fixed GCC's hook to allow branch deletion:
> https://gcc.gnu.org/pipermail/gcc/2020-October/233914.html

Interesting that you would manage this aspect yourselves.
The git-hooks have a config option that allow to control which branch
can be deleted (via a list of regular expressions).

-- 
Joel

Re: Git rejecting branch merge

2020-10-02 Thread Joel Brobecker

> Which is what Joseph said, I think. The problem was that the
> update_hook script still gets called for branch deletions, and it was
> rejecting them. My fix was just to stop rejecting them:
> 
> Author: Jonathan Wakely 
> Date:   Thu Oct 1 18:04:54 2020 +
> 
>Do not check anything for ref deletions
> 
> diff --git a/update_hook b/update_hook
> index 8b342b5..a392230 100755
> --- a/update_hook
> +++ b/update_hook
> @@ -12,6 +12,9 @@ def main():
> ref_name = sys.argv[1]
> old_object = sys.argv[2]
> new_object = sys.argv[3]
> +if re.fullmatch('0+', new_object) is not None:
> +# This is a branch deletion.
> +sys.exit(0)
> # Do not allow updates introducing ancestry based on the old
> # git-svn repository, to ensure people rebase onto the new history
> # rather than merging branches based on git-svn history into those
> 
> 
> 
> Maybe the hooks.update-hook script should not be called at all for ref
> deletions, if they are meant to be handled elsewhere.

Thanks for explaining the context; the script was being called by
the git-hooks via the update-hook config option. I understand better,
now, and the way you handled it seems right to me.

-- 
Joel

Re: Git rejecting branch merge

2020-10-05 Thread Joel Brobecker

> > > I wonder I can get the branch moved, so I can do the benchmarking :)
> > > Any suggestions how to do that?
> 
> I just installed a small patch, hot-fix style which I am hoping will
> fix your problem. Can you try it? It passes the testsuite, so the change
> should be safe.

And now, the fix that was actually pushed has also been deployed.

> Let me know how it goes. I will finish the work over the weekend
> so as to replace the local diff by an actual commit (after review
> from a coworker of mine).

-- 
Joel

support in C++2x

2020-10-09 Thread Joel Sherrill

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

2020-10-09 Thread Joel Sherrill

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

2020-10-28 Thread Joel Sherrill

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

2020-10-29 Thread Joel Sherrill

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

2021-01-15 Thread Joel Sherrill

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

2021-03-04 Thread Joel Sherrill

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

2021-03-31 Thread Joel Sherrill

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

2015-06-30 Thread Joel Sherrill




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

2015-08-03 Thread Joel Sherrill


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

2015-08-03 Thread Joel Sherrill


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?

2015-08-20 Thread Joel Sherrill

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

2015-08-26 Thread Joel Sherrill



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

2015-08-27 Thread Joel Sherrill




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

2015-10-26 Thread 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.

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

2015-10-26 Thread 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.


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

2015-10-26 Thread Joel Sherrill



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

2015-10-29 Thread Joel Sherrill




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

2016-01-04 Thread Joel Sherrill

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

Re: [RFC] DW_OP_piece vs. DW_OP_bit_piece on a Register

2016-01-16 Thread Joel Brobecker

> After analyzing some test case failures in GCC and GDB I realized that
> there are various problems with the handling of DWARF pieces
> (particularly from registers) in the current implementations of GCC and
> GDB.  I'm working on a fix for the GDB part, but first I'd like to check
> whether I'm heading into the right direction -- or what the right
> direction is supposed to be.  The article below outlines these issues
> and the suggested solution options.

This is a very nice and detailed analysis of the current situation.
Thank You!

I admit that I read through the document fairly rapidly; it does
seem to me, at this point, that the first step might be to get
clarification from the DWARF committee? Or is input from the GCC/GDB
community going to help the discussion with the DWARF committee?

-- 
Joel

Committing via git

2016-02-26 Thread Joel Sherrill

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

2016-02-26 Thread Joel Sherrill




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

2016-02-28 Thread Joel Sherrill



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

2016-02-29 Thread Joel Sherrill

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

2016-03-03 Thread Joel Sherrill

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

2016-04-16 Thread Joel Sherrill


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

2016-04-17 Thread Joel Sherrill



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

2016-04-18 Thread Joel Sherrill




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

2016-04-21 Thread Joel Sherrill




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

2016-05-04 Thread Joel Sherrill



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