convention you might want every file to include?
Ciao!
Steven
--joel
Why was this rejected and not merged?
--
Joel Sherrill, Ph.D. Director of Research& Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
arm*-*-netbsd* that don't match arm*-*-netbsdelf* - i.e., old
a.out-based NetBSD - and more generally any other a.out BSD ports.) Old
in-tree GCC versions shouldn't be a limitation here - 4.1 has EABI
support.
Is there anyone maintaining arm*-*-ecos-elf?
I hope none of the above ports are using FPA.
--joel
g our own
dog food. :)
Thomas
--joel sherrill
t is possible to do the markup and
generation badly, doesn't mean it isn't possible to
do a good job in any language which supports separate
specs and bodies.
On the other hand, it is better to generate *some* free documentation,
instead of assuming that programmers will turn to proprietary
documentation which is freely available on the web.
And that's unfortunate. :(
--joel
RTEMS
include the microblaze-*-rtems* target
configure magic? I don't remember where it got left.
--joel
Adding myself to maintainer list.
Index: MAINTAINERS
===
--- MAINTAINERS (revision 164696)
+++ MAINTAINERS (working copy)
@@ -72,6
Daniel,
How do you see this impacting the sparc-rtems target?
We have v7/v8 with HW and SW FP multilibs now and
leon is important to us. :-D
--joel
On 11/19/2010 10:53 AM, Eric Botcazou wrote:
Yes, if all the people who want only one set of libraries agree on what
that set shall be (or this
Hi,
Compiling C++ on the head targeting
arm-rtems4.11, I get this error. It doesn't
occur on m68k-rtems4.11. I don't know about
the other targets yet.
Any suggestions on what is causing this
and how to resolve it?
libtool: compile: /users/joel/test-gcc/b-gcc1-arm/./gcc/xgcc
-sha
On 12/01/2010 02:16 PM, John Tytgat wrote:
In message<4cf69533.10...@oarcorp.com>
Joel Sherrill wrote:
Hi,
Compiling C++ on the head targeting
arm-rtems4.11, I get this error. It doesn't
occur on m68k-rtems4.11. I don't know about
the other targets yet.
Any sug
Hi,
I was experimenting with adding microblaze-rtems*
and got this error:
checking how to run the C preprocessor...
/users/joel/test-gcc/b-gcc1-microblaze/./gcc/xgcc
-B/users/joel/test-gcc/b-gcc1-microblaze/./gcc/ -nostdinc
-B/users/joel/test-gcc/b-gcc1-microblaze/microblaze-rtems4.11/newlib
On 12/21/2010 03:44 PM, Tobias Burnus wrote:
Joel Sherrill wrote:
I was experimenting with adding microblaze-rtems*
and got this error:
>
checking for sqrtl in -lm... configure: error: Link tests are not
allowed after GCC_NO_EXECUTABLES.
make[1]: *** [configure-target-libquadmath] Erro
help me a lot.
Is there any time scale for implementation, or any plan for which release it'll
make it into?
The leon specific bare metal targets are in the SVN head.
If you are using RTEMS, then you can use the RPMs we provide.
Regards,
Dave
--
Joel Sherrill, Ph.D. Direc
copy
for the Ada and Go builds?
Thanks.
--
Joel Sherrill, Ph.D. Director of Research& Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
On 01/28/2011 04:58 AM, Ralf Corsepius wrote:
On 01/28/2011 10:15 AM, Andreas Schwab wrote:
Ralf Corsepius writes:
- Remove newlib from the source tree
--without-newlib should probably be enough.
Good point, agreed.
In case of Joel and rtems the situation probably can be furtherly
YPOT)
That's where I hacked to say with or using newlib.
As best I can tell, that's the only place.
Ian
--
Joel Sherrill, Ph.D. Director of Research& Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS:
Hi,
I updated this morning and sh-rtems does not
build. It fails building libgcc2.c as follows:
home/joel/gcc-work/head/b-sh-rtems4.7/./gcc/xgcc
-B/home/joel/gcc-work/head/b-sh-rtems4.7/./gcc/ -nostdinc
-B/home/joel/gcc-work/head/b-sh-rtems4.7/sh-rtems4.7/newlib/ -isystem
/home/joel/gcc
included from ../../gcc/gcc/targhooks.c:67:
../../gcc/gcc/optabs.h:25:24: error: insn-codes.h: No such file or directory
In file included from ../../gcc/gcc/targhooks.c:67:
../../gcc/gcc/optabs.h:44: warning: ISO C forbids forward references to
‘enum’ types
--joel
Sorry to follow up so quick but I last built this on Jan 17 so this
is also a recent breakage.
Joel Sherrill wrote:
Hi,
I updated this morning and sh-rtems does not
build. It fails building libgcc2.c as follows:
home/joel/gcc-work/head/b-sh-rtems4.7/./gcc/xgcc
-B/home/joel/gcc-work/head/b
This appears to be different from the previous failure.
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory
`/home/joel/gcc-work/head/b-sh-rtems4.7/libdecnumber'
make[2]: Entering directory `/home/joel/gcc-work/head/b-sh-rtems4.7/gcc'
build/genextract ../../gc
Andrew Pinski wrote:
Can you try after the following two patches:
Thanks. It sure it hard to keep up around here. :)
That did it for the sh. Ignoring the precise svn revision, either
yesterday
or today, I managed to build and install the following on the head:
arm-rtems4.7
This is a breakage in about the past week. I built
a native compiler from the same source. Does this look
familiar to anyone?
home/joel/gcc-work/head/b-i386-rtems4.7/./gcc/xgcc
-B/home/joel/gcc-work/head/b-i386-rtems4.7/./gcc/ -nostdinc -B/ho
me/joel/gcc-work/head/b-i386-rtems4.7/i386
Karel Gardas wrote:
If this help, I'd like to add that I succesfully compiled
gcc-4.2-20060128.tar.bz2 for the same configuration.
I think my last SVN update that built for me was a couple of days before
that.
--joel
Cheers,
Karel
On Thu, 2 Feb 2006, Joel Sherrill wrote:
This
Richard Guenther wrote:
On 2/2/06, Joel Sherrill <[EMAIL PROTECTED]> wrote:
Karel Gardas wrote:
If this help, I'd like to add that I succesfully compiled
gcc-4.2-20060128.tar.bz2 for the same configuration.
I think my last SVN update that built for me was a cou
UDES) when built? I included LIBGCC2_INCLUDES because
that is where gcc/config/t-rtems adds
the rtems specific newlib include directory.
--joel
In file included from
../../../../gcc/libgcc-math/i386/../flt-32/e_acosf.c:21:
../../../../gcc/libgcc-math/i386/../include/math_private.h:58: error:
target=i386-rtems4.7 --enable-threads=rtems \
--prefix=/home/joel/gcc-head-test/ \
--with-gnu-as --with-gnu-ld --with-newlib --verbose --with-system-zlib \
--disable-nls --enable-version-specific-runtime-libs
--enable-languages=c,c++,ada
Some of those options are probably paranoid but that&#x
/gcc/crtstuff.c -DCRT_END \
-o crtend.o
../../gcc/gcc/crtstuff.c: In function '__do_global_ctors_aux':
../../gcc/gcc/crtstuff.c:519: internal compiler error: Segmentation fault
Is this a known issue?
--joel
files in the source tree while building.
Hasn't this been fixed before? Is there a missing
fix to merge onto the branch?
--joel
init.c:56 (set
(mem/c:HI (plus:HI (reg/f:HI 28 r28)
(const_int 1 [0x1])) [5 S2 A8])
(reg:HI 24 r24)) 12 {*movhi} (nil)
(nil))
../../../../../../gcc-4.1.0-20060223/newlib/libc/misc/init.c:59:
confused by earlier errors, bailing out
More to follow early next week I hope.
--joel
nfigure with an explicit --includedir=
I don't know what it is but I do hope this is considered a critical
packaging error
and fixed before a final release.
--joel
Ralf
l
Any ideas what slight bug there is in libssp's Makefile.am?
Thanks.
--joel
Andreas Schwab wrote:
Joel Sherrill <[EMAIL PROTECTED]> writes:
RPM invoked make install with the prefixes overriden:
make
prefix=/home/rtems/tmp/rtems-4.7-sparc-rtems4.7-gcc-newlib-gcc4.1.0newlib1.14.0-1-root-rtems/opt/rtems-4.7
Why don't you just set DESTDIR?
Wa
onger in use in workstations.
--joel sherrill
Jiri.
Ralf Corsepius wrote:
On Wed, 2006-03-15 at 20:10 -0800, Alexey Starovoytov wrote:
Hi,
The default architecture for GCC SPARC is V7.
What do gcc sparc developers think about changing it to V8PLUS?
Few things to consider:
- v7 is legacy
nything-to-ANSI-C translator,
that (whoops) loses any back-end-specific optimizations.
For those who don't already know about it, LLVM (llvm.org) has a C
back-end, among others.
- Joel
to an adress
which not belong to my ram memory.
I dont know if It is necessary to make a memory barrier because I
specify that in the linkcmds file.
If you switch to RTEMS from CVS you can use gcc 4.1.1 and a newer
binutils. This by itself may resolve your problem.
--joel
any suggestions??
than
tic4x port that we
have locked down onto an older gcc. There is a partial port to the AVR.
--joel
Richard
lf that is
close to the metal eases the complexity burden of configuring any OS on a
simulator.
--joel
Cheers,
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.
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
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
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:
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
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
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
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
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
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
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
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
7;ve seen a number of projects run into this issue (xz,
> elfutils, libfuse, libkcapi, cryptsetup).
>
And RTEMS.
--joel
>
> Thanks,
> -Vincent
>
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
>
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
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
&
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
>
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. :)
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
>
>
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
>
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
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,
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
>
>
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.
>
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
>
>
releases but
these are small.
So yes, knowing one will happen is important. Putting days/weeks/months
on it, helps people schedule. Even if that is nothing but a goal.
A statement like "within X of the 4.8.0 release date which is
expected in about Y timeframe" would help.
One r
The RTEMS Community would like to squeeze pr56771 in. It only got a fix in the
past few days. It is a one line arm-rtems specific path to libcpp configure.
Can I commit that?
--joel
RTEMS
Richard Biener wrote:
Status
==
The GCC 4.7 branch is ready for a release candidate of GCC 4.7.3
On 4/3/2013 8:36 AM, Richard Biener wrote:
On Wed, 3 Apr 2013, Joel Sherrill wrote:
The RTEMS Community would like to squeeze pr56771 in. It only got a fix in the
past few days. It is a one line arm-rtems specific path to libcpp configure.
Can I commit that?
Sure, if it got RTEMS maintainer
MS targets. powerpc-rtems takes ~1hr at -j1
to build binutils, gcc/newlib, and gdb on a 2.9Ghz i7 without testing.
Most of our targets are around 25min. As the number of multilibs
goes up, there are large variations.
Richard.
--
Joel Sherrill, Ph.D. Director of Research &
opportunity to learn more about the program
in general.
--
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
Have you compared it to -Os? That seems to produce assembly closer to what you
would likely write by hand. I haven't benchmarked it much but it gives 7-10%
smaller code in general. In many cases, fewer instructions is also a
performance win.
Gene Smith wrote:
I tried -Og optimization on a r
ave implementations. Then we can figure out
how to implement it.
For lower model CPUs, it should be safe to assume they
will never be seen in SMP systems and using a
generic RTEMS providing implementation that disables
interrupts and does the operation is OK.
--joel
> WeiY
> Best Regards
&g
On 8/9/2013 11:05 AM, Deng Hengyi wrote:
> Hi Joel,
>
> I have done a test, it seems that '-march=i386' does not provide
> "__atomic_compare_exchange_n" libs. And '-march=i486' or '-march=pentium' can
> find the '__atomic_compare_exch
For the RTEMS wiki, we require a 50 word bio and manually approve accounts. It
is effort to approve accounts but less than the spam clean up was.
It is sad either way.
--joel
Dodji Seketeli wrote:
Jonathan Wakely a écrit:
> I've reverted or deleted all the spam I could find (and
to ucontext.h which we don't have. Adding that to
RTEMS is an "opportunity" to contribute. :)
> Ian
>
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
Is avr-elf not in the set your are building? This looks like a generic target
build issue and not something architecture specific.
-Joel
Jan-Benedict Glaw wrote:
Hi!
Build log is available at
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=38764 .
g++ -c -DIN_GCC_FRONTEND
Was microblaze-rtems attempted? I would have expected a failure like these if
so.
--joel
Jan-Benedict Glaw wrote:
Hi!
Build logs at
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=39192
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=40718
(I also think that
was on the microblaze where someone broke the
libgcc pattern for rtems by changing the pattern from
XXX*-*-* to XXX*-*-elf.
Plus we do have at least one OS/Target specific file for
each *-rtems configuration. There is at least a
config/*/*rtems*.h and often a config/*/t-* which is specifi
On 11/26/2013 11:58 AM, Ralf Corsepius wrote:
> On 11/26/2013 06:38 PM, Joel Sherrill wrote:
>
>>> Is there something that microblaze-rtems exposes that is not already
>>> covered by other microblaze or rtems targets that are already included?
>>
>> I be
On a style inconsistency note, I see that some stanzas use $tmake_file
while
most use ${tmake_file}. Is there a rule? Personally I like having {} and
most
appear to have it.
Feedback appreciated.
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarco
fix this.
An explanation of what it is accomplishing would also be appreciated.
Thanks.
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Avail
bly something just isn't being linked to the executable? or
maybe not being built into libgcc?
I haven't looked into this specific case but often it is a case of
a multilib variant not being covered by the existing code.
Andrew
Andrew
--
Joel Sherrill, Ph.D. Direct
le to handle things
like this. Do the multilib's match the atomic instruction
support across the various ISA revisions?
If so, it is just a matter of ifdef's to get the right code.
Does arm-eabi have this support? We probably could
just use the same code.
r~
--
Joel
simulator is limited in memory and many
tests fail. These get rejected because the mail message is too large. If
someone is willing to help us trim things so the known failures get skipped, it
would be appreciated. We would report more. :)
--joel
RTEMS
Diego Novillo wrote:
>On Sat, Apr 7, 2
.
--joel
Christian Bruel wrote:
>> I think http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49858 is
>> essentially this issue. It can probably be closed as "won't fix",
>> though I notice the spec file format is still documented in the user
>> manual.
>
ore disallowing options not
included in .opt files, but as there are about 500 such headers it's quite
possible I missed some specs-defined options in the process.
--
Joel Sherrill, Ph.D. Director of Research& Development
joel.sherr...@oarcorp.comOn-Line Applicatio
7;t let the sparc
backend shrink like the HPPA one.
Dennis
--
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
This patch adds the microblaze-*-rtems* target to gcc.
OK to apply?
2012-05-07 Joel Sherrill
* config.gcc (microblaze-*-rtems*): New target.
* config/microblaze/rtems.h: New file
--
Joel Sherrill, Ph.D. Director of Research& Development
joel.sherr...@oarcorp
so, I will
submit a patch for review
g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions
-fno-rtti -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I
noop for RTEMS or fix the test
infrastructure that is turning it on where it doesn't exist?
Ian
--
Joel Sherrill, Ph.D. Director of Research& Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 358
On 05/18/2012 09:05 AM, Ian Lance Taylor wrote:
Joel Sherrill writes:
On 05/18/2012 08:27 AM, Ian Lance Taylor wrote:
Ralf Corsepius writes:
I am not sure, but AFAICT, -pthread is Linux-specific.
It's not properly documented, but -pthread works on a number of hosts,
including So
On 05/18/2012 10:50 AM, Ian Lance Taylor wrote:
Joel Sherrill writes:
On 05/18/2012 09:05 AM, Ian Lance Taylor wrote:
Joel Sherrill writes:
On 05/18/2012 08:27 AM, Ian Lance Taylor wrote:
Ralf Corsepiuswrites:
I am not sure, but AFAICT, -pthread is Linux-specific.
It'
}
Is there a way we could avoid that block if
gdbarch_elf_make_msymbol_special points to the default implementation?
It just seems sad to be doing all this work of creating a temporary symbol
for every solib symbol on non-mips targets...
One possible way would have been to provide no default value for
gdbarch_elf_make_msymbol_special, but then it makes the calling
of that method a little trickier. That could be worked around by
changing the default value of gdbarch_elf_make_msymbol_special to NULL,
and then having an extra wrapper function that call the gdbarch
method if not NULL or else does nothing.
--
Joel
RPMs from the EPEL
repository.
But installing them from source into a location that doesn't
conflict with the default OS install is straight forward and
well documented.
--
Joel Sherrill, Ph.D. Director of Research& Development
joel.sherr...@oarcorp.comO
+1 from me
--joel
Ian Lance Taylor wrote:
>I propose that Cary Coutant become an additional
>DWARF maintainer, along with Jason. Cary has been on the DWARF
>working group for many years and is very familiar with the format. He
>has written several patches for GCC's DWARF co
sable-werror --enable-newlib-mb \
--enable-newlib-iconv --with-gnu-ld --with-newlib \
--verbose --with-system-zlib --disable-nls \
--enable-version-specific-runtime-libs \
--enable-languages=c,c++ --target=arm-rtems4.11 \
--prefix=/home/joel/v850/install
Attached is a build log with the e
s but didn't get back around to running
the tests and reporting.
When I get home, I will do a build/test run for *-rtems and generate PRs, etc.
--joel
Robert Dewar wrote:
>On 12/15/2012 12:42 AM, Ralf Corsepius wrote:
>
>>> If you want a port to be live show that it i
deprecation.
--joel
"Joseph S. Myers" wrote:
>On Wed, 12 Dec 2012, Steven Bosscher wrote:
>
>> Linux support for i386 has been removed. Should we do the same for GCC?
>
>FWIW, glibc hasn't really supported i386 for several years (at least with
>the Linux kernel;
On 12/19/2012 4:13 PM, Janne Blomqvist wrote:
On Wed, Dec 19, 2012 at 2:32 AM, Joel Sherrill
wrote:
My primary concern centers whether any 386 w/o fpu IP cores or space hardened
i386dx/sx or 486sx CPUs are impacted. These could be used in new designs.
This also eliminates gcc from use on any
:
gcc (GCC) 4.6.3 20120306 (Red Hat 4.6.3-2)
I configured gcc svn 194667 as
/users/joel/test-gcc/gcc-svn/configure --disable-werror
--enable-languages=c,c++,ada,objc --prefix=/users/joel/test-gcc/install-svn
And the build ends with this:
g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous
> What is the status of STABS support?
In terms of GDB, it is no longer actively maintained. But if you
submit patches, I will do my best to review them.
--
Joel
itch over to DWARF,
even on older versions such as AIX 5.1.
--
Joel
shell code to the embedded awk
script?
Thanks.
--joel
On 01/04/2013 09:14 AM, Cynthia Rempel wrote:
Hi,
I tried to run the following command:
../gcc/contrib/test_summary -p my_commentary.txt -m gcc-testresu...@gcc.gnu.org
| sh
and got the following error:
sh: 22297: Mail: not found
After di
some changes, and make some fixes, mostly done by
Tristan, and normally they should have been contributed to the
FSF tree. Overall, I think we're pretty happy with GNU ld as
of now.
--
Joel
301 - 400 of 574 matches
Mail list logo
