Hello,
Apparently, at least for MIPS target, GCC generates labels starting
from 2: $L2, $L3, etc.
Do you know why the numbering begins at 2?
Regards,
Joel
> When I saw this question before, I thought that it'd be easy to find
> out by debugging gcc. However, I also thought that there's no really
> good reason why anyone would need the answer, so I didn't look.
>
> You might get more response from others if you said why it's important
> for you to kn
mpiled with and
without strict-aliasing. If there is a difference,
we will have to review it. This eliminates a lot of the code base but
it is still generating a lot of cases to examine by
hand.
I'm curious if your patch will ease this process.
Thank you,
Silvius
--joel sherrill
Andrew Haley wrote:
Joel Sherrill writes:
> Silvius Rus wrote:
> >
> > I wrote some code (not released yet) that improves the accuracy of
> > -Wstrict-aliasing using tree-ssa-alias information. The primary idea
> > was to tell the programmer "go fix t
ler (80+ extra failures out of 1800+ tests).
>
> Could you please let us know if this is -O0 or not. For -O0, I'd
> like to think that the debugging experience shouldn't be worse. If
> it is at -O0, I'd encourage bug reports for all the problems.
It is indeed at -O0 (for probably 99% of our testcases).
--
Joel
build is probably about 1/3
of the way through and so far, I have not encountered any problems.
I have a lot left to build though and haven't actually run an executable
yet.
--joel
Mark Mitchell wrote:
GCC 4.2.0 RC3 is now available from:
ftp://gcc.gnu.org/pub/gcc/prerelease-
Mark Mitchell wrote:
Joel Sherrill wrote:
Ralf encountered problems on the avr and bfin during the tool
build and has filed or updated PRs for those.
Understood, and thnanks for testing!
I should make clear that I don't see release candidates as opportunities
for general te
ny interest
in this, please respond. Thanks.
- 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
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
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
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
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
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
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
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
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
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:
>
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
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
> &
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:
>
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
>
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
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
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
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
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
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
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 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, 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
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
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
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
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
don't think I can do this for you, unfortunately.
--
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
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
he update-hook config option. I understand better,
now, and the way you handled it seems right to me.
--
Joel
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
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
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
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
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
>
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
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
one but does any FLOSS organization have this?
--joel
>
> paul
>
>
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.
8 && _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
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: incompatibl
eted 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
>>> 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
s.
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
ructures 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
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 w
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
>> >>
>
gure 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
.
--joel
t 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
after being up too
long.
--joel
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
uot;.
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
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
oop 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ópe
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
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
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 re
nity
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
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
ooked into it deeply.
In general coroutine support requires the ability to designate some
area of memory as stack space.
Ian
--joel
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 wit
hugely
unuseful {sig,}{set,long}jmp() but removed the actually useful *context()
(amended somehow like above).
Ciao,
Michael.
--joel
On 5/9/2016 3:41 PM, Ian Lance Taylor wrote:
On Mon, May 9, 2016 at 1:07 PM, Joel Sherrill wrote:
One complication on RTEMS which is a single process, multi-threaded RTOS
is that we can no longer check the stack bounds. For threads, we know
where the stack memory is and the range for each
ojects are able to
>> succeed!
>
>There is some history and links at
>https://en.wikipedia.org/wiki/GNU_Compiler_Collection .
>
>In my opinion, the history of GCC is not really one of drama or even
>anecdotes, except for the EGCS split.
I am not even sure that is interest
function `_static_initialization_and_destruction_0':
/users/joel/rtems-4.11-work/rtems-testing/rtems/build-sh-gensh1-rtems/sh-rtems4.11/c/gensh1/testsuites/samples/cdtest/../../../../../../../rtems/c/src/../../testsuites/samples/cdtest/main.cc:141:
undefined reference to `__dso_handle'
/users/
date sweep for C++ transition missed this file?
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
On 5/1/2014 3:29 PM, Oleg Endo wrote:
> On 01 May 2014, at 22:08, Joel Sherrill wrote:
>
>> Hi
>>
>> gcc-4.8.2 targeting sh-*-* fails to compile on
>> FreeBSD 10 which is using clang. I am hoping someone
>> has some ideas about these.
> Yes, I've no
ms4.11-gcc
COLLECT_LTO_WRAPPER=/users/joel/rtems-4.11-work/tools/libexec/gcc/sh-rtems4.11/4.8.2/lto-wrapper
Target: sh-rtems4.11
Configured with: ../gcc-4.8.2/configure
--prefix=/users/joel/rtems-4.11-work/tools
--bindir=/users/joel/rtems-4.11-work/tools/bin
--exec_prefix=/users/joel/rtems-4.11-
a_options="${extra_options} sh/superh.opt" ;;
Do we need to add those? Anything else we might be missing?
On 5/5/2014 11:37 AM, Joel Sherrill wrote:
> Hi
>
> We have a few build failures on the RTEMS target where it appears
> that the -ml argument to make a relocatable is
rated.
Other than fixing the manual or downgrading makeinfo, any suggestions
or comments?
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support
e
was aware of it.
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
Hi
I was updating the RTEMS scripts to build GNAT and it appears
that passing CFLAGS_FOR_TARGET in to add a -I option to
the build no longer works. We were using it so the Ada build
could find the networking .h files.
What's the current way of doing this?
Thanks.
--
Joel Sherrill,
es.
>
> If the library is not going to be expanded to support all GPUs and
> offload targets, the library name should be more specific to Intel.
That matches what I understood and should have said Yes to.
> Thanks, David
--
Joel Sherrill, Ph.D. Director of Research & D
be
>>make CFLAGS="-g -O2 -fbracket-depth=512"
> Also i thought we did not support cross building with anything besides gcc.
The RTEMS community sees this when using clang/llvm on FreeBSD.
Franzi.. did the suggestion from Chris Johns to increase the limit
to
uilds fail with:
make[4]: Entering directory
`/users/joel/test-gcc/b-m32c-elfgcc/m32c-elf/m32cm/libgcc'
make[4]: *** No rule to make target `all'. Stop.
At the point of the failure, the m32c-elf directory has these:
$ find m32c-elf/ -type d
m32c-elf/
m32c-elf/libgcc
m32c-elf/libgcc/confh
/greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/final.c:2891
> 0x6258ef final(rtx_def*, _IO_FILE*, int)
> /greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/final.c:2023
> 0x626035 rest_of_handle_final
> /greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/final.c:4427
> 0x626035 execute
>
thing odd in the top
configurery magic for m32c which could cause this but I could
easily be missing something.
On 7/17/2014 3:17 PM, Joel Sherrill wrote:
> On 7/17/2014 3:08 PM, DJ Delorie wrote:
>> I just tried a 4.9.1 build and got this error:
> Same error in m32c-elf/m32cm/libg
d in darwin.opt with this:
fapple-kext
Target Report C++ Var(flag_apple_kext)
Generate code for darwin loadable kernel extensions
Who is comfortable fixing that?
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
On August 31, 2014 8:19:49 AM CDT, Peng Fan wrote:
>Hi,
>
>I am writing some code and found that system crashed. I found it was
>unaligned access which causes `data abort` exception. I write a piece
>of code and objdump
>it. I am not sure this is right or not.
>
>command:
>arm-poky-linux-gnueabi
wn spam my accounts. My wife uses a
couple of them. I think one is stopforumspam.com. you may be able to automate
checking for the account there. These are manually reported account by forum
admins.
--joel
> Jakub
it might be missing it'd be helpful for
> evaluation.
>
> My recommendation would be to file a bug report with the reproducer.
> m68k isn't nearly as important today as it has been in the past, so
> getting developer time to hash through how all this should work for the
> coldfire may be difficult.
>
> jeff
>
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
expects argument of type 'double', but
argument 2 has type 'float' [-Wformat=]
The code is:
#include
void f(float X)
{
printf( "%f", X );
}
Any ideas? Should I raise a PR?
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oa
On September 10, 2014 3:40:05 PM CDT, "Joseph S. Myers"
wrote:
>On Wed, 10 Sep 2014, Joel Sherrill wrote:
>
>> Hi
>>
>> We have a few RTEMS BSPs which use CPUs where float, double,
>> and long double are the same. This triggers the printf format
>
-exceptions on the
configure line. Before we didn't have to do this.
FWIW I think this same issue is tripped by the h8300.
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS H
to detect exception model
make[1]: *** [configure-target-libgcc] Error 1
Any suggestions?
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Avail
toconf probe code. m32c when -mcpu=m32cm and h8300
when -ms.
I suppose I need to file these as target specific regressions since 4.9.
Thanks for prodding my rusty memory.
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Application
^
../../../../../../gcc/libstdc++-v3/src/c++98/mt_allocator.cc:643:52:
warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
__gthread_setspecific(freelist._M_key, (void*)_M_id);
^
Thanks.
--
Joel Sherrill
Attached is a patch which changes size_t to uintptr_t.
It is enough to let the build continue. But I would appreciate
feedback given the code.
--joel
On 11/7/2014 9:07 AM, Joel Sherrill wrote:
> Hi
>
> On m32c-rtems, we have a build error in C++ because size_t
> is 16-bits and poi
On 11/7/2014 9:25 AM, Paolo Carlini wrote:
> Hi,
>
> On 11/07/2014 04:07 PM, Joel Sherrill wrote:
>> Hi
>>
>> On m32c-rtems, we have a build error in C++ because size_t
>> is 16-bits and pointers are 24 bits. m32c-elf probably does not
>> enable __GTHREAD
On November 8, 2014 9:00:02 AM CST, Jonathan Wakely
wrote:
>On 7 November 2014 16:56, Joel Sherrill wrote:
>>
>> On 11/7/2014 9:25 AM, Paolo Carlini wrote:
>>> Hi,
>>>
>>> On 11/07/2014 04:07 PM, Joel Sherrill wrote:
>>>> Hi
>>>&g
1 - 100 of 574 matches
Mail list logo
