is enabled, it fails with an assembler error. Even though I have
never
used this processor and have no plans to, went ahead and filed an issue:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118941
--joel
On Tue, Feb 18, 2025 at 4:33 PM Joel Sherrill
wrote:
>
>
> On Tue, Feb 18, 2025 at 3:
like you need to build a cross tool chain for the tic6x-elf target
which
will produce a gcc named tic6x-elf-gcc.
Richard's comments also apply but I'm not sure you were trying
a gcc targeting the tic6x
--joel
> >
> > I've read on forums that GCC 4.7 has *some* level
On Wed, Nov 20, 2024, 3:50 PM Mark Wielaard wrote:
> On Wed, Nov 20, 2024 at 04:11:16PM -0500, David Malcolm via Gcc wrote:
> > I merged libdiagnostics to GCC trunk on Monday:
> > https://gcc.gnu.org/wiki/libdiagnostics
> >
> > Unfortunately I've since discovered there's at least one libdiagnos
ntation.
>
> These are implemented in the runtime C library (libc), which are outside
> the scope of GCC itself.
> Popular such libraries you can look at are glibc and musl libc.
>
Or newlib which is commonly used in embedded systems and Cygwin.
--joel
> Thanks,
> Kyrill
>
>
> >
> > Thanks for the help.
> >
> > - Bryon
>
>
he
change.
I've had good luck replacing licenses using blockrep.sed from Paolo
Bonzini. It
takes two blocks of text as input and generates the sed command. Combine
that
with something to identify the files that need the change applied and Bob's
your
uncle.
https://sed.sourceforge.i
ections to get newer Python and GCC,
but it's harder on other hosts.
>
> I see the functions/methods in bbitmap.h definitely could be improved
> with going to C++14.
>
> Thanks,
> Andrew
>
>
> >
> > Jason
>
--joel
>
reason to think it won't be back up soon? We can switch where the scripts
fetch packages if there is a reason to be concerned.
Thanks.
--joel
RTEMS
simplest
is to just have a way to disable the daemon mode, and just have
the users wait. In the vast majority of cases, the wait will be
a few seconds. Even with a patch-series of a 100 patches, it would
mean a 1min40s wait. Very bearable.
If you agree, we can create an issue for it on the git-hooks repoisitory
on GitHub.
--
Joel
g the obsolescence in the Linux kernel.
>
Just an FYI that the RTEMS Project plans to drop NIOS II support based
on what happens with the tooling.
--joel
>
> --
> Joseph S. Myers
> josmy...@redhat.com
>
>
ry
> > decades ago, but it seems it may be time to move on.
>
> I don't see that. Many aspects of systems remain non-standardized.
>
Again from pthreads, manipulating affinity on multi-core systems and
having names for pthreads are non-standard but commonly available
with varying APIs.
And the standards have plenty of wiggle room in them. Undefined areas
or deliberately implementation defined.
--joel
>
>
> Ciao,
> Michael.
>
it approved or reviewed by just gives you two people to blame.
It is not a perfect solution either.
But double checking and checklists are good practices. They are not
foolproof if some bad actor is determined enough.
--joel
> Thanks,
> Florian
>
>
what it required.
And that led to very few people being able to successfully regenerate.
Is that avoidable?
OTOH the set of people touching these files may be small enough that
pain isn't an issue.
--joel
On Wed, Apr 3, 2024 at 5:22 AM Jan Beulich via Gcc wrote:
> On 03.04.2024 10:57,
On Wed, Mar 27, 2024 at 3:53 AM Christophe Lyon via Gcc
wrote:
> Hi!
>
> On 3/26/24 22:52, Joel Sherrill via Gcc wrote:
> > Hi
> >
> > For RTEMS, we normally build a multilib'ed gcc+newlib, but I have a case
> > where the CPU model is something not covered b
c+newlib with a single set of libraries
that are built for a specific CPU CFLAGS?
I am trying --disable-multlibs on the gcc configure and adding
CFLAGS_FOR_TARGET to make.
Advice appreciated.
Thanks.
--joel
his?
>
Looks like a solid argument to drop it.
With even MIPS Technologies moving toward RISC-V, you have to
wonder how many processor architectures are on the downhill slide
into the tar pit of extinction.
--joel
>
> Thanks,
> Andrew Pinski
>
purposes. C++11 and C++14 were
very recently added as options in a corrigenda that was released in August.
I know this isn't the primary focus for GCC but embedded isn't rare.
>From an RTEMS perspective, the OS is primarily built as C11 but that
was primarily done for access to the atomics defined there not in C99.
So it isn't that the code "isn't ready" for a new language version, it may
be because there are standards still based on older versions or the safety
review process may not accommodate a newer version. It also could be
as simple as the RTOS vendor does not recommend using it with their
OS which has been through something like a flight qualification.
--joel
>
> Thanks,
> Florian
>
>
also.
https://gtd-gmbh.gitlab.io/mcdc-checker/mcdc-checker/index.html
For RTEMS, I've tried to encourage us to just avoid the need for
MCDC analysis for years. The tools to do the analysis were proprietary
and expensive.
All that said, I'm looking forward to gcov supporting mcdc. :)
o
> gcc 9. Perhaps digging in and assessing that would be a good start.
>
One question is whether that code has proper assignments on file for
ultimate inclusion. That should be part of your assessment.
--joel
>
I don't know anything more about it, I'm just a collector of
> cross-compilers for
> obscure / lost / forgotten / abandoned targets.
>
> /Mikael
>
On Wed, May 10, 2023 at 10:14 AM Jakub Jelinek wrote:
> On Wed, May 10, 2023 at 10:10:37AM -0500, Joel Sherrill wrote:
> > > > What practices might the GCC community recommend to a project
> > > > wanting to discover the issues uncovered and slowly address them? I
&
On Tue, May 9, 2023 at 5:46 PM Jonathan Wakely
wrote:
> On Tue, 9 May 2023 at 23:38, Joel Sherrill wrote:
> > We are currently using gcc 12 and specifying C11. To experiment with
> > these stricter warnings and slowly address them, would we need to build
> > with a newer C
e can make software security one of the driving principles of GCC and
> state that explicitly. GCC needs a point of view.
>
Well said.
I know over at RTEMS, we have been using GCC since before EGCS and
during that time, we have upgraded our GCC version a lot of times. Often,
the upgrade generates more warnings. We accept that as a benefit and
cost of having a living project. We also may be on the more precise end
of the scale in specifying our GCC arguments. We specify the language
version, enable as many warnings as possible, etc. I think it is critical
that
a project pick their language version and ensure that they are not
getting the default which shifts over time.
We are currently using gcc 12 and specifying C11. To experiment with
these stricter warnings and slowly address them, would we need to build
with a newer C version?
What practices might the GCC community recommend to a project
wanting to discover the issues uncovered and slowly address them? I
i am a bit gun shy because I remember the move from GCC 3.3 to 3.4
where the improved strict alias checking gave us a LOT of warnings to
deal with and it felt overwhelming. I don't want to do that again.
But I believe in letting the compiler get stricter and find things.
Defaulting
to stricter checking is a good thing.
--joel sherrill
RTEMS
>
> Thanks, David
>
7;ve seen a number of projects run into this issue (xz,
> elfutils, libfuse, libkcapi, cryptsetup).
>
And RTEMS.
--joel
>
> Thanks,
> -Vincent
>
to do so. If it causes others
an issue, perhaps they need to align with standards a bit better. :)
--joel
On Tue, Oct 4, 2022, 5:26 PM Jason Merrill via Gcc wrote:
> On 9/28/22 16:15, Jonathan Wakely wrote:
> > As part of implementing a C++23 proposal [1] to massively increase the
&g
Well we got gcc's verbose but in the we need ld's. Should be something like
-Wl,-v
If someone actually knew offhand which linker script template of used in
this cases it would help. I don't and always have to dig.
--joel
On Mon, Jun 20, 2022, 12:09 PM Gabriele Bulfon wrote:
&g
r.xommand and script used. Just follow that info to locate the linker
script and then look just before the unaligned section.
--joel
>
> Any clue?
> Gabriele
>
>
> *Sonicle S.r.l. *: http://www.sonicle.com
> *Music: *http://www.gabrielebulfon.com
> *eXoplanets
le (section):
> offset 0x74d8de99 is non-aligned
> ld: fatal: relocation error: R_SPARC_DISP32: file
> .libs/compatibility-atomic-c++0x.o: symbol .gcc_except_table (section):
> offset 0x74d8deb9 is non-aligned
> ...
>
Any chance the linker script is missing an align di
ectory
> (Thumb-2), however, I get a sorry message related to Thumb-1?
>
Any chance you can see in the tools build log how that file is actually
compiled?
I'm suspicious that this multilib is named in a complicated way and their
command line parsing doesn't get it all the wa
Thanks for the quick reply.
On Wed, Nov 10, 2021 at 8:20 AM Jonathan Wakely wrote:
>
> On Wed, 10 Nov 2021 at 14:08, Joel Sherrill wrote:
> >
> > Hi
> >
> > It's been a while since I tried this and it appears things have
> > changed. I tried to
op Makefile.
I haven't tried the others and I don't think I have the tools
installed for epub so that will have to wait.
Any advice is appreciated.
--joel
I am pleased to announce that the GCC Steering Committee has appointed
Maciej W. Rozycki as maintainer of the Vax backend in GCC.
Maciej, please update your listing in the MAINTAINERS file.
Good luck!
--joel
On Wed, Jul 21, 2021 at 10:08 PM Jeff Law wrote:
>
>
>
> On 7/21/2021 6:31 PM, Michael Eager wrote:
> >
> >
> > On 7/21/21 5:22 PM, Joel Sherrill wrote:
> >>
> >>
> >> On Wed, Jul 21, 2021, 7:12 PM Michael Eager >> <mailto:
On Wed, Jul 21, 2021, 7:12 PM Michael Eager wrote:
> On 7/21/21 2:28 PM, Joel Sherrill wrote:
> > Hi
> >
> > We are in the process of porting RTEMS to the Microblaze and gcc does
> > not have __ELF__ as a predefine. In looking around at where to add it,
> > it l
specific header
Integrating dbxelf.h into the microblaze seems risky for one simple
builtin_define(). Adding it to config/microblaze/rtems.h won't address
the microblaze-elf target.
A suggestion on where to add the builtin_predefine is appreciated.
Thanks
--joel
This ignores a couple of plugins we use that I don't expect GCC to use.
It works great but the host dependencies are sometimes a pain. We've
ended up writing host OS specific advice/howto's to address this. Any
expectations on host pain versus the pretty painless texinfo?
Thanks.
one but does any FLOSS organization have this?
--joel
>
> paul
>
>
Hi all,
Some community members have shown interest in a patch I made a while back but
didn't submit.
I'm not looking to commit this at the moment, just to make it available (hence
why I haven't sent it to gcc-patches)>
This patch was based on master at the following commit and doesn't curr
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
ect 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
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
>
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/d83f12de08465ee5db7c3
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 deprecat
u 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/1
uld 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
he update-hook config option. I understand better,
now, and the way you handled it seems right to me.
--
Joel
t; 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
w 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
don't think I can do this for you, unfortunately.
--
Joel
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
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 ac
ing 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
f 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
On Fri, Sep 11, 2020, 5:02 PM Joel Sherrill wrote:
>
>
> On Fri, Sep 11, 2020 at 4:36 PM Janne Blomqvist
> wrote:
>
>> On Fri, Sep 11, 2020 at 6:52 PM Joel Sherrill wrote:
>> >
>> > Hi
>> >
>> > Over at RTEMS, we ran into a case where t
On Fri, Sep 11, 2020 at 4:36 PM Janne Blomqvist
wrote:
> On Fri, Sep 11, 2020 at 6:52 PM Joel Sherrill wrote:
> >
> > Hi
> >
> > Over at RTEMS, we ran into a case where the C++ atomics may not be right
> > for one of the lower level x86 models. We will inves
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 sup
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
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
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
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
d 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
nore_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
red 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
>
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, 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
> &
n 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
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:
>
ible 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
elopers 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
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
s. 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
ork, 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
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
o
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
asing, 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
> Joel, this is definitely a question for you; it's beyond my expertise in
> the working of the hooks. The issue is that when a merge commit is
> pushed, we only want mails for commits that are new *to the repository* -
> not those that are already in the repository (accessibl
t is something that you are trying to replicate
from the SVN days, and whether it still have enough value that
you would want to crowd the email subject with that piece of
information?
Perhaps the answer to my questions are somewhere in the middle,
and it is sufficient to have it in the email body alone?
--
Joel
hink we can make
it work:
One config to list the naming scheme for branches
One config to list the naming scheme for tags
I just want to be careful to also consider how all the options
are interacting with each other. In this case, we were able to
combine two requirements into one, so that addresses my concern.
--
Joel
created one called refs/heads/devel/foo or
> refs/users/someone/heads/foo. Our naming conventions mean that all
> branches in refs/heads/ should be called master, devel/something or
> releases/something. But it's easy for someone to get a "git push" command
> wrong so that it would create a badly named branch.
Could you rely on the update-hook script for that?
--
Joel
tags such as releases?
>
> I think signing future release tags is probably appropriate.
FWIW (with my GDB Release Manager hat, this time), some people have
asked about it shortly after GDB switched over to Git. I've been
signing them ever since.
--
Joel
, this will trigger an email that looks like this:
| Subject: [repository_name] Created tag v0.1
| X-Act-Checkin: repository_name
| X-Git-Author: Test Suite
| X-Git-Refname: refs/tags/v0.1
| X-Git-Oldrev: 0000
| X-Git-Newrev: c4c1e91cddc3d48a
ement.
You want to say that, before branch "" gets created, you want
to verify that a branch named either "devel/" or "releases/"
does exist? And probably also that the commit in branch ""
is already present in the branch that already exists?
IIUC, I think this one is highly specialized, and shoud be done
in the update-hook script. Would that be OK?
--
Joel
re allowed for ref patterns
> outside refs/heads.
OK.
--
Joel
Hi Joseph,
Apologies for the slow replies. The end of this week has been
pretty packed, and next week will be as well. But I will make
sure we answer every questions and suggestions you have!
On Thu, Jan 09, 2020 at 02:25:59PM +, Joseph Myers wrote:
> On Mon, 16 Sep 2019, Joel Brobec
ould suggest consideration for dumping into a buffer and having an
external
agent (e.g. debugger, JTAG based program, etc) retrieve it.
RTEMS programs generally don't exit and often have no networking. You have
to
have flexibility. No one is forcing a singular output media -- just
flexibility.
I'd love to see decision and MCDC coverage support .
--joel
>
> > Martin
>
> David
>
>
note to confirm that the documentation has now been
moved to the git-hooks github page: https://github.com/adacore/git-hooks
Don't hesitate to reach out to me, if you have questions, or would
like some help configuring the hooks.
--
Joel
On Fri, Sep 20, 2019, 3:12 PM Nicholas Krause wrote:
>
> On 9/20/19 4:09 PM, Jason Merrill wrote:
> > On Fri, Sep 20, 2019 at 8:32 AM Nicholas Krause
> wrote:
> >> I was wondering if its possible to use the C11 atomics library for
> >> multithreading
> >>
> >> GCC. Not sure if its a good idea du
> > You mean the email notification sent by the hooks when a commit
> > gets pushed? If yes, here is an example:
> >
> > https://www.sourceware.org/ml/gdb-cvs/2019-09/msg00041.html
>
> Thank you, Joel! I got a little worried how to best parse that ;-),
> but t
f yes, here is an example:
https://www.sourceware.org/ml/gdb-cvs/2019-09/msg00041.html
--
Joel
Hello everyone,
On Sat, Sep 14, 2019 at 04:53:17PM -0400, Jason Merrill wrote:
> At Cauldron this weekend Joel offered to adjust his git hooks
> (https://github.com/brobecke/git-hooks), which are already used by gdb
> and glibc, to meet GCC's needs. Separately, Joseph volunteered
On Wed, Jun 19, 2019 at 2:07 PM Jonathan Wakely
wrote:
> On Wed, 19 Jun 2019 at 20:05, Joel Sherrill wrote:
> >
> > Hi
> >
> > I was double checking the C++17 support in GCC for someone and the text
> at
> > this URL states
> > the support is expe
/projects/cxx-status.html#cxx17
Thanks.
--joel
pc=$BUILD/host-tools --with-isl=$BUILD/host-tools --disable-shared
--disable-nls --disable-threads --disable-tls --enable-checking=yes
--enable-languages=c,c++,fortran --with-newlib --with-pkgversion=unknown
Thread model: single
gcc version 10.0.0 20190612 (experimental) (unknown)
From 7e744509575030ca5
ic block?
On 14/06/2019 22:34, Segher Boessenkool wrote:
> On Wed, Jun 12, 2019 at 10:52:42AM +, Joel Hutton wrote:
>> A summary of the behaviour is:
>> when combining A -> B, the register equivalence notes of A are checked, the
>> register notes of B are not checked.
Ok with me if no one steps up and the downstream projects like Debian gets
notice. This is just a reflection of this architecture's status in the
world.
--joel
On Thu, Jun 13, 2019, 4:13 AM Richard Biener wrote:
>
> ia64 has no maintainer anymore so the following deprecates it
>
elf-gcc -S -mcpu=cortex-a53 -O2 tmp.c -ftree-vectorize -fno-inline
-fdump-rtl-all -fno-vect-cost-model -dp -fdump-rtl-combine-all
-fdump-tree-optimized -o -
From 7e744509575030ca5b3fa6042d02d27171fbfbfd Mon Sep 17 00:00:00 2001
From: Joel Hutton
Date: Tue, 11 Jun 2019 10:10:07 +0100
Subject: [PATCH] M
ean?
>
That's how I read it and that would not be a warning IMO.
Back to a point in my original email that seems to have been missed.
Doxygen reports this as a warning. I would just like the option to find it
with gcc as well.
And not checking system headers is reasonable in general.
could be we need an extra -Wxxx but
we end up spotting these with Doxygen.
Anything we are missing?
Thanks.
--joel
gaps.
I know Ada is traditionally more strongly typed than C/C++, but tf it can
be done for Ada programs reliably, why could it not be reliable in C?
>
> (Array transformations and struct splitting, on the other hand, can be
> useful.)
>
--joel
>
> Ian
>
>
>
>
t number of users. People have to
find it and then integrate it on their own. Don't make it hard for folks to
find and use your work.
* Something else entirely...
>
> If there is any interest in incorporating this work into GCC, please
> advise.
>
I think so but I am just one voice from the RTEMS community. But I think
any M0 user would be pleased.
--joel
>
> Thanks,
> Daniel Engel
>
On Tue, Aug 28, 2018, 4:54 PM Segher Boessenkool
wrote:
> Hi Joel,
>
> On Tue, Aug 28, 2018 at 04:21:25PM -0500, Joel Sherrill wrote:
> > Just wanting to confirm with someone PowerPC knowledgeable that
> > the -mspe option was indeed removed on the master and the
> >
Hi
Just wanting to confirm with someone PowerPC knowledgeable that
the -mspe option was indeed removed on the master and the
documentation needs to be updated to reflect this.
Thanks.
--joel
1 - 100 of 574 matches
Mail list logo
