On 17/04/2025 12:19, Wasim Khan via Gcc wrote:
>
>
>> -Original Message-
>> From: Richard Earnshaw (lists)
>> Sent: 17 April 2025 14:57
>> To: Wasim Khan ; gcc-h...@gcc.gnu.org;
>> gcc@gcc.gnu.org
>> Subject: Re: memcpy issue with arm-gnu-toolc
d.
> But when I move to toolchain version 14.2 , I am getting below error.
>
>
> Linking ...
> /opt/arm-gnu-toolchain-*-aarch64-none-elf/bin/aarch64-none-elf-gcc \
> -nodefaultlibs \
> -nostartfiles \
> -mcpu=cortex-a55 \
> -Wl,--gc-secti
> -Original Message-
> From: Richard Earnshaw (lists)
> Sent: 17 April 2025 14:57
> To: Wasim Khan ; gcc-h...@gcc.gnu.org;
> gcc@gcc.gnu.org
> Subject: Re: memcpy issue with arm-gnu-toolchain-14.2.rel1-x86_64-aarch64-
> none-elf
>
> [You don't of
;t want to use
> implementation provided by libc.a.
> Things works fine with toolchain version 12.3 and my local implementation
> in utils.c is considered.
> But when I move to toolchain version 14.2 , I am getting below error.
>
>
> Linking ...
> /opt/arm-gnu-toolchain-*-aar
nking ...
/opt/arm-gnu-toolchain-*-aarch64-none-elf/bin/aarch64-none-elf-gcc \
-nodefaultlibs \
-nostartfiles \
-mcpu=cortex-a55 \
-Wl,--gc-sections \
-Wl,--build-id=none \
-T /opt/test.lds \
-Wl,-Map=/opt/test.map \
-Wl,--no-warn-rwx-seg
On Thu, Mar 28, 2024 at 2:23 AM Jan Beulich wrote:
>
> On 28.03.2024 08:43, Fangrui Song wrote:
> > On Fri, Mar 22, 2024 at 6:51 PM Fangrui Song wrote:
> >>
> >> On Thu, Mar 14, 2024 at 5:16 PM Fangrui Song wrote:
> >>>
> >>> The relocat
On Thu, Mar 28, 2024 at 6:04 AM Alan Modra wrote:
>
> On Fri, Mar 22, 2024 at 06:51:41PM -0700, Fangrui Song wrote:
> > On Thu, Mar 14, 2024 at 5:16 PM Fangrui Song wrote:
> > > I propose RELLEB, a new format offering significant file size
> > > reductions: 17.2% (x86-64), 16.5% (aarch64), and ev
On Fri, Mar 22, 2024 at 06:51:41PM -0700, Fangrui Song wrote:
> On Thu, Mar 14, 2024 at 5:16 PM Fangrui Song wrote:
> > I propose RELLEB, a new format offering significant file size
> > reductions: 17.2% (x86-64), 16.5% (aarch64), and even 32.4% (riscv64)!
> >
> > Your thoughts on RELLEB are welco
On 28.03.2024 08:43, Fangrui Song wrote:
> On Fri, Mar 22, 2024 at 6:51 PM Fangrui Song wrote:
>>
>> On Thu, Mar 14, 2024 at 5:16 PM Fangrui Song wrote:
>>>
>>> The relocation formats REL and RELA for ELF are inefficient. In a
>>> release build of Cl
On Fri, Mar 22, 2024 at 6:51 PM Fangrui Song wrote:
>
> On Thu, Mar 14, 2024 at 5:16 PM Fangrui Song wrote:
> >
> > The relocation formats REL and RELA for ELF are inefficient. In a
> > release build of Clang for x86-64, .rela.* sections consume a
> > significant po
On Thu, Mar 14, 2024 at 5:16 PM Fangrui Song wrote:
>
> The relocation formats REL and RELA for ELF are inefficient. In a
> release build of Clang for x86-64, .rela.* sections consume a
> significant portion (approximately 20.9%) of the file size.
>
> I propose RELLEB, a n
The relocation formats REL and RELA for ELF are inefficient. In a
release build of Clang for x86-64, .rela.* sections consume a
significant portion (approximately 20.9%) of the file size.
I propose RELLEB, a new format offering significant file size
reductions: 17.2% (x86-64), 16.5% (aarch64
On 12/6/23 15:03, DJ Delorie wrote:
Alexandre Oliva writes:
This looks like a latent bug in the port.
I'm not surprised, that port was weird.
This was just a plain asm insn in strub.c:
/* Make sure the stack overwrites are not optimized away. */
asm ("" : : "m" (end[0]));
whose
Alexandre Oliva writes:
> This looks like a latent bug in the port.
I'm not surprised, that port was weird.
> This was just a plain asm insn in strub.c:
>
> /* Make sure the stack overwrites are not optimized away. */
> asm ("" : : "m" (end[0]));
>
> whose constraint passes during reload, r
[adding gcc@]
Hi, Jeff,
On Dec 6, 2023, Jeff Law wrote:
> libgcc is currently failing to build on rl78, looks like it might be
> strub related.
Thanks for letting me know.
>> /home/jlaw/test/gcc/libgcc/strub.c:149:1: error: unrecognizable insn:
>> 149 | }
>> | ^
>> (insn 30 64 33 4 (asm_oper
like architecture, machine type and OS ABI in ELF header rather than
reading it from crtbegin.o. I tried my hand at it but couldn't find
anything substantial. Any suggestion regarding the same will be helpful!
Also a question to Jan and Martin, right now should I focus on debugging
part or get
uild-gcc'
> >
> > Is this expected? Is libstdc++ even supported for this target?
>
> Yes. What's your configure command? You probably need at least --with-newlib.
>
> I think my last successful msp430 build was using:
>
> .../gcc/configure --target=msp430-elf
configure command? You probably need at least --with-newlib.
I think my last successful msp430 build was using:
.../gcc/configure --target=msp430-elf --prefix=$HOME/gcc/msp430-elf
--disable-libcc1 --disable-libgomp --disable-libitm --disable-libssp
--disable-libvtv --disable-nls --with-system
I'm trying to validate a change to gcc/config/msp430/msp430.cc.
The cross-compiler builds as far as I can tell, but I hit a snag while
configuring libstdc++:
checking for shl_load... configure: error: Link tests are not allowed after
GCC_NO_EXECUTABLES.
make[1]: *** [Makefile:12334: configure-tar
ch only support the Thumb
instruction set, the PIC32MM only supports the micromips instruction
set (and not mips32).
I wonder if you can add all the possible combinations to the multilib
list for the mips*-elf target, just like the arm-*-eabi target.
Thank you very much.
On Fri, 11 Jun 2021, John Ericson wrote:
> I would like to propose that GNU tools consistently interpret configs
> with "netbsd" as meaning ELF as opposed to a.out. Currently, newer CPUs
> do that, but older ones have "netbsd" mean a.out for historical reason
providing that when configuring
for
just "netbsd" there was a prominentant message in the config log saying
something like:
"netbsd format now treated as ELF based. Use netbsdaout if you want a.out format
files".
(Probably with slightly better wording than that).
Cheers
Nick
Hello Binutils and GCC lists[1],
I would like to propose that GNU tools consistently interpret configs with
"netbsd" as meaning ELF as opposed to a.out. Currently, newer CPUs do that, but
older ones have "netbsd" mean a.out for historical reasons, and "netbsdel
Hi, elves (people who work on ELF)!
Motivated by a recent rant from Linus Torvalds on shared objects' performance
issues and a previous post about CPython 1.3x speedup with
-fno-semantic-interposition 1.3x, I have thought about an ELF world with
STB_GLOBAL variant of -Bsymbolic-functio
Hi, i work on a windows 10 development platform and I will use the portable
stdint and all and all I need. Mr. Ian Lance Taylor (Google) are not possible
for my company.
Renaud Lelièvre
Montréal
#include
#include
struct microFields {
unsigned int addr:28;
unsigned int cond:2;
Hi,
I have noticed LINK_SPEC is empty on x86_64-pc-elf and i[3456]86-pc-elf
targets. Lack of LINK_SPEC means -m16/-m32/-mx32/-m64 are not converted
to correct linker emulation mode. Is it expected behaviour?
If it's not, where would be the best place to define LINK_SPEC? Is it
okay to do th
On 22/05/2019 15:42, Szabolcs Nagy wrote:
> [AAELF64]: ELF for the Arm 64-bit Architecture (AArch64)
>https://developer.arm.com/docs/ihi0056/latest
> [VABI64]: Vector Function ABI Specification for AArch64
>
> https://developer.arm.com/tools-and-software/ser
t; The st_other member of a symbol table entry specifies the symbol's
>>>> visibility in the lowest 2 bits. The top 6 bits are unused in the
>>>> generic ELF ABI [SCO-ELF], and while there are no values reserved for
>>>> processor-speci
gt;>> visibility in the lowest 2 bits. The top 6 bits are unused in the
>>> generic ELF ABI [SCO-ELF], and while there are no values reserved for
>>> processor-specific semantics, many other architectures have used these
>>> bits.
>>>
ts. The top 6 bits are unused in the
>> generic ELF ABI [SCO-ELF], and while there are no values reserved for
>> processor-specific semantics, many other architectures have used these
>> bits.
>>
>> The defined processor-specific st_other flag
* Szabolcs Nagy:
> AAELF64: in the Symbol Table section add
>
> st_other Values
> The st_other member of a symbol table entry specifies the symbol's
> visibility in the lowest 2 bits. The top 6 bits are unused in the
> generic ELF ABI [SCO-ELF],
were discussed at
https://groups.google.com/forum/#!topic/generic-abi/Bfb2CwX-u4M
The ABI change draft is below the notes, it requires marking symbols
in the ELF symbol table that follow the vector PCS (or other variant
PCS conventions). This is most relevant to dynamic linkers with lazy
binding
On 06/11/2018 08:59 PM, Rich Felker wrote:
If the application already has to annotate that the data is
going to be read-only after ctors, it can just page-align/page-pad the
data itself and call mprotect with minimal additional effort, and no
complex interaction between application code and relro
On Mon, Jun 11, 2018 at 07:50:32PM +0200, Florian Weimer wrote:
> On 06/11/2018 04:50 PM, Rich Felker wrote:
> >On Tue, Feb 27, 2018 at 11:01:23AM +0100, Florian Weimer wrote:
> >>I think it would be a nice addition to the toolchain if it were
> >>possible to programatically initialize data in the
On 06/11/2018 04:50 PM, Rich Felker wrote:
On Tue, Feb 27, 2018 at 11:01:23AM +0100, Florian Weimer wrote:
I think it would be a nice addition to the toolchain if it were
possible to programatically initialize data in the RELRO section.
We do this in glibc, but I don't think this is currently su
On Tue, Feb 27, 2018 at 11:01:23AM +0100, Florian Weimer wrote:
> I think it would be a nice addition to the toolchain if it were
> possible to programatically initialize data in the RELRO section.
> We do this in glibc, but I don't think this is currently supported
> for general use.
>
> One impo
On 8 June 2018 at 16:11, Joseph Myers wrote:
> On Fri, 8 Jun 2018, Jonathan Wakely wrote:
>
>> > The root cause is PR66203 which I reported quite some time ago, which
>> > points to a newlib problem: on aarch64 there is no default rom
>> > monitor, one has to explicitly use a --specs flag for the l
On Fri, 8 Jun 2018, Jonathan Wakely wrote:
> > The root cause is PR66203 which I reported quite some time ago, which
> > points to a newlib problem: on aarch64 there is no default rom
> > monitor, one has to explicitly use a --specs flag for the link to
> > succeed.
>
> I have no idea why this ca
On 8 June 2018 at 16:41, Jonathan Wakely wrote:
> On 8 June 2018 at 14:22, Christophe Lyon wrote:
>> Hi,
>>
>> As I reported in
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870#c16, the build of
>> GCC for aarch64*-none-elf fails when configuring libst
On 8 June 2018 at 14:22, Christophe Lyon wrote:
> Hi,
>
> As I reported in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870#c16, the build of
> GCC for aarch64*-none-elf fails when configuring libstdc++ since
> r261034 (a week ago).
Sorry for not trying to fix it, I'm
Hi,
As I reported in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78870#c16, the build of
GCC for aarch64*-none-elf fails when configuring libstdc++ since
r261034 (a week ago).
The root cause is PR66203 which I reported quite some time ago, which
points to a newlib problem: on aarch64 there is
On Thu, 31 May 2018 07:23:22 PDT (-0700), matthew.fort...@mips.com wrote:
Palmer Dabbelt writes:
On Tue, 29 May 2018 11:02:58 PDT (-0700), Jim Wilson wrote:
> On 05/26/2018 06:04 AM, Sebastian Huber wrote:
>> Why is the default multilib and a variant identical?
>
> This is supposed to be a sing
On 01/06/18 10:23, Michael Clark wrote:
On 1/06/2018, at 6:16 PM, Sebastian Huber
wrote:
On 29/05/18 20:02, Jim Wilson wrote:
Most variants include the C extension. Would it be possible to add -march=rv32g
and -march=rv64g variants?
The expectation is that most implementations will inc
> On 1/06/2018, at 6:16 PM, Sebastian Huber
> wrote:
>
> On 29/05/18 20:02, Jim Wilson wrote:
>>> Most variants include the C extension. Would it be possible to add
>>> -march=rv32g and -march=rv64g variants?
>>
>> The expectation is that most implementations will include the C extension.
On 31/05/18 11:08, Palmer Dabbelt wrote:
On Tue, 29 May 2018 11:02:58 PDT (-0700), Jim Wilson wrote:
On 05/26/2018 06:04 AM, Sebastian Huber wrote:
Why is the default multilib and a variant identical?
This is supposed to be a single multilib, with two names. We use
MULTILIB_REUSE to map the
On 29/05/18 20:02, Jim Wilson wrote:
Most variants include the C extension. Would it be possible to add
-march=rv32g and -march=rv64g variants?
The expectation is that most implementations will include the C
extension. It reduces code size, improves performance, and I think I
read somewhere
On Thu, May 31, 2018 at 7:23 AM, Matthew Fortune
wrote:
> I do actually have a solution for this but it is not submitted upstream.
> MIPS has basically the same set of problems that RISC-V does in this area
> and in an ideal world there would be no 'fallback' multilib such that if
> you use compil
Palmer Dabbelt writes:
> On Tue, 29 May 2018 11:02:58 PDT (-0700), Jim Wilson wrote:
> > On 05/26/2018 06:04 AM, Sebastian Huber wrote:
> >> Why is the default multilib and a variant identical?
> >
> > This is supposed to be a single multilib, with two names. We use
> > MULTILIB_REUSE to map the
On Tue, 29 May 2018 11:02:58 PDT (-0700), Jim Wilson wrote:
On 05/26/2018 06:04 AM, Sebastian Huber wrote:
Why is the default multilib and a variant identical?
This is supposed to be a single multilib, with two names. We use
MULTILIB_REUSE to map the two names to a single multilib.
rohan:103
On 05/26/2018 06:04 AM, Sebastian Huber wrote:
Why is the default multilib and a variant identical?
This is supposed to be a single multilib, with two names. We use
MULTILIB_REUSE to map the two names to a single multilib.
rohan:1030$ ./xgcc -B./ -march=rv64imafdc -mabi=lp64d --print-libgcc
Hello,
I built a riscv64-rtems5 GCC (it uses gcc/config/riscv/t-elf-multilib). The
following multilibs are built:
riscv64-rtems5-gcc -print-multi-lib
.;
rv32i/ilp32;@march=rv32i@mabi=ilp32
rv32im/ilp32;@march=rv32im@mabi=ilp32
rv32iac/ilp32;@march=rv32iac@mabi=ilp32
rv32imac/ilp32;@march
I think it would be a nice addition to the toolchain if it were possible
to programatically initialize data in the RELRO section. We do this in
glibc, but I don't think this is currently supported for general use.
One important application is to allocate a memory region with mmap, on
which pr
On Sep 2, 2015 6:57 AM, "Brian Gerst" wrote:
>
> On Tue, Sep 1, 2015 at 10:21 PM, Andy Lutomirski wrote:
> > On Sep 1, 2015 6:53 PM, "Brian Gerst" wrote:
> >>
> >> On Tue, Sep 1, 2015 at 8:51 PM, Andy Lutomirski
> >> wrote:
> >> > Hi all-
> >> >
> >> > Linux has a handful of weird features tha
On Tue, Sep 1, 2015 at 10:21 PM, Andy Lutomirski wrote:
> On Sep 1, 2015 6:53 PM, "Brian Gerst" wrote:
>>
>> On Tue, Sep 1, 2015 at 8:51 PM, Andy Lutomirski wrote:
>> > Hi all-
>> >
>> > Linux has a handful of weird features that are only supported for
>> > backwards compatibility. The big one
On 2015-09-02 00:32, Andy Lutomirski wrote:
On Tue, Sep 1, 2015 at 9:18 PM, Rich Felker wrote:
On Tue, Sep 01, 2015 at 08:39:27PM -0700, Andy Lutomirski wrote:
On Tue, Sep 1, 2015 at 7:54 PM, Rich Felker wrote:
If this is not the case, I have what sounds like an elegant solution,
if it works
On Tue, Sep 01, 2015 at 10:03:27PM -0700, Andy Lutomirski wrote:
> On Tue, Sep 1, 2015 at 9:55 PM, Rich Felker wrote:
> > On Tue, Sep 01, 2015 at 09:32:22PM -0700, Andy Lutomirski wrote:
> >> On Tue, Sep 1, 2015 at 9:18 PM, Rich Felker wrote:
> >> > On Tue, Sep 01, 2015 at 08:39:27PM -0700, Andy
On Tue, Sep 1, 2015 at 9:55 PM, Rich Felker wrote:
> On Tue, Sep 01, 2015 at 09:32:22PM -0700, Andy Lutomirski wrote:
>> On Tue, Sep 1, 2015 at 9:18 PM, Rich Felker wrote:
>> > On Tue, Sep 01, 2015 at 08:39:27PM -0700, Andy Lutomirski wrote:
>> >> On Tue, Sep 1, 2015 at 7:54 PM, Rich Felker wrot
On Tue, Sep 01, 2015 at 09:32:22PM -0700, Andy Lutomirski wrote:
> On Tue, Sep 1, 2015 at 9:18 PM, Rich Felker wrote:
> > On Tue, Sep 01, 2015 at 08:39:27PM -0700, Andy Lutomirski wrote:
> >> On Tue, Sep 1, 2015 at 7:54 PM, Rich Felker wrote:
> >> > On Tue, Sep 01, 2015 at 05:51:44PM -0700, Andy
On Tue, Sep 1, 2015 at 9:18 PM, Rich Felker wrote:
> On Tue, Sep 01, 2015 at 08:39:27PM -0700, Andy Lutomirski wrote:
>> On Tue, Sep 1, 2015 at 7:54 PM, Rich Felker wrote:
>> > On Tue, Sep 01, 2015 at 05:51:44PM -0700, Andy Lutomirski wrote:
>> >> Hi all-
>> >>
>> >> Linux has a handful of weird
On Tue, Sep 01, 2015 at 08:39:27PM -0700, Andy Lutomirski wrote:
> On Tue, Sep 1, 2015 at 7:54 PM, Rich Felker wrote:
> > On Tue, Sep 01, 2015 at 05:51:44PM -0700, Andy Lutomirski wrote:
> >> Hi all-
> >>
> >> Linux has a handful of weird features that are only supported for
> >> backwards compati
On Tue, Sep 1, 2015 at 7:54 PM, Rich Felker wrote:
> On Tue, Sep 01, 2015 at 05:51:44PM -0700, Andy Lutomirski wrote:
>> Hi all-
>>
>> Linux has a handful of weird features that are only supported for
>> backwards compatibility. The big one is the x86_64 vsyscall page, but
>> uselib probably belo
On Tue, Sep 01, 2015 at 05:51:44PM -0700, Andy Lutomirski wrote:
> Hi all-
>
> Linux has a handful of weird features that are only supported for
> backwards compatibility. The big one is the x86_64 vsyscall page, but
> uselib probably belongs on the list, too, and we might end up with
> more at s
uld be done in a clean,
> > extensible way.
>
> What sets up the vsyscall page, and what information does it have
> before doing so?
>
> I'm guessing it's the kernel that sets it up, and that all it can see
> at that point is the program headers.
Currently
On Sep 1, 2015 6:53 PM, "Brian Gerst" wrote:
>
> On Tue, Sep 1, 2015 at 8:51 PM, Andy Lutomirski wrote:
> > Hi all-
> >
> > Linux has a handful of weird features that are only supported for
> > backwards compatibility. The big one is the x86_64 vsyscall page, but
> > uselib probably belongs on t
On Tue, Sep 1, 2015 at 8:51 PM, Andy Lutomirski wrote:
> Hi all-
>
> Linux has a handful of weird features that are only supported for
> backwards compatibility. The big one is the x86_64 vsyscall page, but
> uselib probably belongs on the list, too, and we might end up with
> more at some point.
On Tue, Sep 1, 2015 at 5:51 PM, Andy Lutomirski wrote:
>
> Linux has a handful of weird features that are only supported for
> backwards compatibility. The big one is the x86_64 vsyscall page, but
> uselib probably belongs on the list, too, and we might end up with
> more at some point.
>
> I'd l
Hi all-
Linux has a handful of weird features that are only supported for
backwards compatibility. The big one is the x86_64 vsyscall page, but
uselib probably belongs on the list, too, and we might end up with
more at some point.
I'd like to add a way that new programs can turn these features o
;/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin"
> ldconfig -n /home/toon/compilers/install/lib/../lib64
> /sbin/ldconfig.real:
> /home/toon/compilers/install/lib/../lib64/libstdc++.so.6.0.21-gdb.py is not
> an ELF file - it has the wrong magic bytes at the start.
>
r/bin/install -c install/.libs/libgcj_bc.lai
/home/toon/compilers/install/lib/../lib64/libgcj_bc.la
libtool: finish:
PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin"
ldconfig -n /home/toon/compilers/install/lib/../lib64
/sbin/ldconfig.real:
/home/toon/compilers/in
Hi Shanyao,
On 03/09/14 16:02, shanyao chen wrote:
Hi,
I found there is a performance problem with some simd intrinsics
(vld2_dup_*) on aarch64-none-elf. Now the vld2_dup_* are defined as
follows:
#define __LD2R_FUNC(rettype, structtype, ptrtype, \
regsuffix, funcsuffix, Q
Hi,
I found there is a performance problem with some simd intrinsics
(vld2_dup_*) on aarch64-none-elf. Now the vld2_dup_* are defined as
follows:
#define __LD2R_FUNC(rettype, structtype, ptrtype, \
regsuffix, funcsuffix, Q) \
__extension__ static __inline rettype \
__attribute__
Hi All,
I am looking at a regression (in aarch64_be-none-elf-gcc -Og and
test-case attached) where a TImode register is assigned two DImode
values and then passed to the __multf3 as argument. When, the
intermediate pseudo(TImode) is assigned a FP_REG to hold this value, the
regression shows up
On Fri, 2014-05-09 at 00:48 +0200, Jan-Benedict Glaw wrote:
> [...]
>
> Just found this for iq2000:
>
> g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions
> -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
> -Wwrite-strings -Wcast-qual -Wmissing-format-attribut
[...]
Just found this for iq2000:
g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno
Hi!
On Sat, 2014-04-19 21:54:07 +0200, Jan-Benedict Glaw wrote:
> I noticed that between 704db68e45..f2de45326 (209463..r209495),
> probbaly in e2ec52cad85e (r209484), building for arm-eabi breaks:
I oversaw this one for arc-elf:
g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE
On Sat, 2014-04-19 21:54:07 +0200, Jan-Benedict Glaw wrote:
[...]
m32r-elf looks similar, too:
g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual
-Wmissing-format-attribute -Woverloaded-virtual
On 27 November 2013 08:22, Jan-Benedict Glaw wrote:
> Looking at the code, I see no way how rclass could be used
> uninitialized. The diagnostic message looks wrong to me. May need a
> fix at a totally different location, where it is issued ;)
That's PR49401:
http://gcc.gnu.org/bugzilla/show_bu
On Tue, 2013-11-26 04:26:25 +0100, Jan-Benedict Glaw wrote:
> Build log at
> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=40716
>
> g++ -c -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -O2 -DIN_GCC
> -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti
> -fasynchronous-unwind-tab
that are
> > > already included?
> >
> > I believe it was on the microblaze where someone broke the libgcc
> > pattern for rtems by changing the pattern from XXX*-*-* to
> > XXX*-*-elf.
>
> In order to catch such a problem, we'd have to at least build
>
broke the
> libgcc pattern for rtems by changing the pattern from
> XXX*-*-* to XXX*-*-elf.
In order to catch such a problem, we'd have to at least build libgcc.
Which requires to have an assembler for the respective target first.
How should this be handled? Test if an cross-asembler for
Hi!
On Tue, 2013-11-26 04:27:56 +0100, Jan-Benedict Glaw wrote:
> Build log at
> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=40206
I think Joern is rewarded with the First Fixer's Trophy :)
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=41484
MfG, JBG
--
lieve it was on the microblaze where someone broke the
>> libgcc pattern for rtems by changing the pattern from
>> XXX*-*-* to XXX*-*-elf.
> Correct. microblaze-rtems* is incomplete in libgcc.
>
> I have a patch pending for gcc-4.8.x, but haven't yet tried with
> gcc-4.9.x.
from
XXX*-*-* to XXX*-*-elf.
Correct. microblaze-rtems* is incomplete in libgcc.
I have a patch pending for gcc-4.8.x, but haven't yet tried with
gcc-4.9.x.
Ralf
g configuration should be included.
>
It is true that the RTEMS configurations are generally similar to
the *-elf ones. However, we turn on pthreads support in C++ and
multitasking in the languages which have it including Ada. We
have good test results even in FORTRAN. With tasking and
filesystem
suggestion of which target(s) to choose?
microblazeel-elf.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
On Tue, 26 Nov 2013, Jan-Benedict Glaw wrote:
> > The idea if config-list.mk is not to build every conceivable target
> > configuration, but to give a reasonable converage of the different
> > target architectures and OS/library configurations so that you can
> > effectively test a patch with unk
=40718
(I also think that we'd have the little endian version on the target
list at contrib/config-list.mk ...)
[...]
I do not see this error in my build of microblaze-elf.
I notice that there are flags in your compile that do not appear in mine:
-pedantic -Wno-long-long -Wno-variadic-macros
On Tue, 2013-11-26 08:13:12 -0800, Michael Eager wrote:
> On 11/26/13 08:08, Jan-Benedict Glaw wrote:
> > Thanks for looking into the issue anyways! (...and what do you
> > think about adding a microblazeel target to the list?)
>
> Sounds OK to me.
Any suggestion of which target(s) to choose?
> > (I also think that we'd have the little endian version on the target
> > list at contrib/config-list.mk ...)
[...]
> I do not see this error in my build of microblaze-elf.
>
> I notice that there are flags in your compile that do not appear in mine:
> -pedantic -Wn
microblaze-rtems is almost identical to microblaze-elf.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
lized]
*recog_data.dup_loc[i] = orig_dup[i];
^
cc1plus: all warnings being treated as errors
make[2]: *** [reload1.o] Error 1
I do not see this error in my build of microblaze-elf.
I notice that there are flags in your compile that do not appear in mine:
-pedantic
On Tue, 2013-11-26 15:21:12 +, Joern Rennecke
wrote:
> On 26 November 2013 14:51, Jan-Benedict Glaw wrote:
> > On Tue, 2013-11-26 06:33:39 -0600, Joel Sherrill
> > wrote:
> > > Was microblaze-rtems attempted? I would have expected a failure
> > > like these if so.
> >
> > No, it wasn't. I
On 26 November 2013 14:51, Jan-Benedict Glaw wrote:
> On Tue, 2013-11-26 06:33:39 -0600, Joel Sherrill
> wrote:
>> Was microblaze-rtems attempted? I would have expected a failure like
>> these if so.
>
> No, it wasn't. It's not on the list of targets in
> .../gcc/contrib/config-list.mk . So w
On Tue, 2013-11-26 06:33:39 -0600, Joel Sherrill
wrote:
> Jan-Benedict Glaw wrote:
> > 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 we'd have the little
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 we
Hi!
Build log is available at
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=40112
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=40121
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=40123
http://toolchain.lug-owl.de/buildbot/show_build_details.php?i
Hi!
Build log at
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=40206
g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-
Hi!
Build log at
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=38806
g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-
Hi!
Build log at
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=40127
g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-
Hi!
Buildlog is at
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=40125
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=40126
g++ -c -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -O2 -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti
-fasynchronous-unwind-
1 - 100 of 438 matches
Mail list logo
