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
> -Original Message-
> From: Thomas Schwinge
> Sent: Monday, September 23, 2024 7:37 PM
> To: gcc@gcc.gnu.org; Prathamesh Kulkarni
> Cc: Tom de Vries ; Roger Sayle
>
> Subject: GCC nvptx-none Target Testing (was: New page "nvptx" in the GCC
> wi
Hi!
On 2017-02-16T21:10:20+0100, I wrote:
> I created a new page "nvptx" in the GCC wiki to document
> --target=nvptx-none configurations: <https://gcc.gnu.org/wiki/nvptx>.
(I've revised that one -- it's been a few years... -- and in particular
then) I've
Sorry I am a newbie to cross compilation, but overall, as far as I can see,
the following two options both won't work:
1. If I compile instrument_cov.so with gcc as a x86-64bit ELF executable,
then it throws the above error (mentioned in my first email) when being
loaded by arm
Dear Andrew,
Thanks a lot. Let me make sure I understand the entire picture here. So
basically on my Ubuntu 18.04 x86 machine, I use:
1. gcc (version 10.0; x86) to compile arm-none-eabi-gcc.
2. And also use gcc (version 10.0; x86) to compile the plugin; I tested a
number of x86 applications and
ugin on various programs' GIMPLE code during its
> compilation with x86 gcc (version 10.0).
>
> 2. Then, I switched to use arm-none-eabi-gcc to load this plugin, and
> encountered the above issue.
Right because you did not recompile the plugin to use the headers of
arm-none-eabi-gcc co
Then, I switched to use arm-none-eabi-gcc to load this plugin, and
encountered the above issue.
3. Since I am doing a cross-platform compilation (on Ubuntu x86), I am
anticipating to NOT directly compile my plugin (as a typical .so shared
library) into an ARM library, right? Otherwise it cann
On Tue, Jul 21, 2020 at 11:25 PM Shuai Wang via Gcc wrote:
>
> Hello,
>
> I am currently trying to migrate a gcc plugin that has been well developed
> for x86 code to ARM platform (for arm-none-eabi-gcc).
>
> Currently I did the following steps:
>
> 1. write a he
Hello,
I am currently trying to migrate a gcc plugin that has been well developed
for x86 code to ARM platform (for arm-none-eabi-gcc).
Currently I did the following steps:
1. write a hello world program t.c
2. compile with the following commands:
➜ arm-none-eabi-gcc -v
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
with-multilib-list=rmprofile
>
>
>
> # If this is the top-level multilib, build all the other
> # multilibs.
> /home/R0b0t1/devel/toolgen/build/gcc-7.3.0/./gcc/xgcc
> -B/home/R0b0t1/devel/toolgen/build/gcc-7.3.0/./gcc/
> -B/home/R0b0t1/devel/toolgen/prefix/arm-none-eabi/bin/
&
0b0t1/devel/toolgen/prefix/arm-none-eabi/bin/
-B/home/R0b0t1/devel/toolgen/prefix/arm-none-eabi/lib/ -isystem
/home/R0b0t1/devel/toolgen/prefix/arm-none-eabi/include -isystem
/home/R0b0t1/devel/toolgen/prefix/arm-none-eabi/sys-include-g -O2
-mthumb -march=armv8-m.base -O2 -g -O2 -DI
R0b0t1 kirjoitti 18.8.2017 klo 19:17:
On Fri, Aug 18, 2017 at 1:09 AM, Freddie Chopin wrote:
On Thu, 2017-08-17 at 22:27 -0500, R0b0t1 wrote:
On Thu, Aug 17, 2017 at 4:44 PM, R0b0t1 wrote:
When compiling libssp, ssp.c, function __guard_setup:
O_RDONLY is undeclared (ssp.c:93:34),
ssize_t is
On Fri, 2017-08-18 at 11:17 -0500, R0b0t1 wrote:
> Just to check, this is actually an
> arm-none-eabi toolchain? I looked over the compilation flags and it
> looks like it supports all Cortex-M processor features like such a
> toolchain should. Most instructions I could find seeme
r support
>> > for generating toolchains with the crossdev project.
>> >
>> > I am very confused and what I want to do seems to be poorly
>> > documented.
>> >
>> > Thanks in advance,
>> > R0b0t1.
>
> Here you may find a com
I forgot to say, that the procedure and resulting toolchain is closely
modeled after the one provided by ARM on:
https://developer.arm.com/open-source/gnu-toolchain/gnu-rm
It just has couple of tweaks like slightly different options for
newlib, completely disabled C++ exceptions and uses the most
rce/gnu-toolchain/gnu-rm, would
> > be
> > extremely helpful. Any help provided will be used to better support
> > for generating toolchains with the crossdev project.
> >
> > I am very confused and what I want to do seems to be poorly
> > documented.
> >
&g
On Thu, Aug 17, 2017 at 4:44 PM, R0b0t1 wrote:
> When compiling libssp, ssp.c, function __guard_setup:
> O_RDONLY is undeclared (ssp.c:93:34),
> ssize_t is an unknown type name (ssp.c:96:7), and
> size_t is an unknown type name (ssp.c:113:25).
>
> ../../src/gcc-7.2.0/configure --target=$TARGET --p
When compiling libssp, ssp.c, function __guard_setup:
O_RDONLY is undeclared (ssp.c:93:34),
ssize_t is an unknown type name (ssp.c:96:7), and
size_t is an unknown type name (ssp.c:113:25).
../../src/gcc-7.2.0/configure --target=$TARGET --prefix=$PREFIX
--with-cpu=cortex-m4 --with-fpu=fpv4-sp-d16 -
Hi!
I created a new page "nvptx" in the GCC wiki to document
--target=nvptx-none configurations: <https://gcc.gnu.org/wiki/nvptx>.
Grüße
Thomas
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 7 August 2013 14:10, David Edelsohn wrote:
> The same error occurs on AIX because the tests are run without pthreads.
We moved the thread to the libstdc++ list, where I pointed out that
is missing the "#pragma GCC system_header" that
would suppress the warnings.
The same error occurs on AIX because the tests are run without pthreads.
- David
On Wed, Aug 7, 2013 at 6:22 AM, Bin.Cheng wrote:
> Hi,
> I spotted case ext/headers.cc failed on arm-none-eabi with below information:
>
> In file included from
> /home/build/work/gcc-build/arm-no
Hi,
I spotted case ext/headers.cc failed on arm-none-eabi with below information:
In file included from
/home/build/work/gcc-build/arm-none-eabi/armv7-m/libstdc++-v3/include/arm-none-eabi/bits/gthr.h:148:0,
from
/home/build/work/gcc-build/arm-none-eabi/armv7-m/libstdc++-v3
l.
Yeah, actually I was wrong here, I see that in C99 (but not C90) the
preprocessor types are now specified in target terms. Integers are
always intmax_t or uintmax_t. So it would theoretically be possible to
specify floating point (if permitted by your extension) as using the
target type.
On Tue, 2011-03-01 at 13:45 -0800, Ian Lance Taylor wrote:
> Steve Ellcey writes:
>
> > According to PR 20095 the reason for not implementing
> > __gcc_personality_v0 is that the HP unwind library does not implement
> > _UA_END_OF_STACK which is a GCC extension to the standard IA64 unwind
> > ABI
Steve Ellcey writes:
> According to PR 20095 the reason for not implementing
> __gcc_personality_v0 is that the HP unwind library does not implement
> _UA_END_OF_STACK which is a GCC extension to the standard IA64 unwind
> ABI and the HP-UX system unwind does not support it so the only way
> to i
On Tue, 2011-03-01 at 11:10 +0100, Richard Guenther wrote:
> It comes from the fact that we delay choosing a personality function
> for functions that are happy with any personality. There is
> the function_needs_eh_personality () function that decides this.
> If you force that to never return eh
On Tue, Mar 1, 2011 at 12:27 AM, Steve Ellcey wrote:
> On Mon, 2011-02-28 at 23:56 +0100, Richard Guenther wrote:
>
>> The gcc_personality is provided by libgcc_s I think, it's what you
>> get when compiling C code with -fexceptions and install
>> cleanup handlers.
>>
>> It seems that LTO comes to
On Tue, 2011-03-01 at 10:14 +1000, Richard Henderson wrote:
> On 03/01/2011 09:27 AM, Steve Ellcey wrote:
> > The libgcc_s on the ia64-hp-hpux* platform, at least when built using
> > the system unwind library, does not have a gcc personality function and
> > so far it has not needed one.
>
> How
On 03/01/2011 09:27 AM, Steve Ellcey wrote:
> The libgcc_s on the ia64-hp-hpux* platform, at least when built using
> the system unwind library, does not have a gcc personality function and
> so far it has not needed one.
How is that possible? Do any of the gcc.dg/cleanup-*.c tests work?
r~
On Mon, 2011-02-28 at 23:56 +0100, Richard Guenther wrote:
> The gcc_personality is provided by libgcc_s I think, it's what you
> get when compiling C code with -fexceptions and install
> cleanup handlers.
>
> It seems that LTO comes to the conclusion that the C++ specific
> personality is not ne
ality __gcc_personality_v0#
> pr33572.s: stringz "\0014__gxx_personality_v0"
> pr33572.s: .global __gxx_personality_v0#
> pr33572.s: .type __gxx_personality_v0#, @function
> pr33572.s: .personality __gxx_personality_v0#
>
> When I add -flto-partition=none t
y_v0#
ccG1Elhg.ltrans0.s: .type __gcc_personality_v0#, @function
ccG1Elhg.ltrans0.s: .personality__gcc_personality_v0#
pr33572.s: stringz "\0014__gxx_personality_v0"
pr33572.s: .global __gxx_personality_v0#
pr33572.s: .type __gxx_personality_v0#, @function
pr3357
.ltrans0.ltrans.o
> 1 errors.
> collect2: ld returned 1 exit status
>
> (This is using the HP linker which I do for all my GCC builds.)
so you do not have the linker-plugin?
> If I add -flto-partition=none to the link, then everything works fine.
> I notice that the =none option fo -f
nker which I do for all my GCC builds.)
If I add -flto-partition=none to the link, then everything works fine.
I notice that the =none option fo -flto-partition does not seem to be
documented in invoke.texi, which only covers 1to1 and balanced so I am
not sure what it means (put everything in
s/devel/gmp/Portfile
But the --host=none-apple-darwin was initially added on 2004-12-03
(revision 9565), and I don't know if removing it has been tested.
--
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.v
, so using more C and less assembly can be a
good thing (GCC's usage of GMP does not include manipulating really
really huge numbers).
gmp/configure is where the blame really lies, but if gcc configured gmp
"normally",
this wouldn't occur. Or, is cpu=none not so abnorma
in filter_tee_header reading the output of
a failed exec.
Ignoring the signal under a Python wrapper however, it continues on
and deletes the output, causing gmp/configure to fail because it is looking
for the output.
gmp/configure is where the blame really lies, but if gcc configured gmp
"
Jay wrote:
Andrew, Can you explain more why?
Because at some point, no released version worked on intel macs.
And then gmp/configure runs flex.
And then sometimes?always flex tries to run getenv("M4") || "m4".
Yes, Flex uses m4.
gmp/configure probably should not be setting M4
Yes, I thi
get, gmp's configure
sets M4=m4-not-needed.
Setting the processor to "none" is a good way to get it down the "not needed"
path.
Though there might be other ways there, granted.
And then gmp/configure runs flex.
And then sometimes?always flex tries to run getenv("M4&q
On Wed, Jun 18, 2008 at 12:40 AM, Jay <[EMAIL PROTECTED]> wrote:
> Ah, I didn't realize any C or C++ code could be configured for other than a
> specific processor but I guess that makes sense -- it is Makefile, config.h,
> and such that are being modified, not the .o files, and they might be the
>
x27;t seen such configure processor=none use.).
- Jay
> Date: Tue, 17 Jun 2008 13:39:42 -0400
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Re: configuring in-tree gmp/mpfr with "none"?
> CC: gcc@gcc.gnu.org
>
> On Sun, Jun 15, 2008 at 12:49 PM, Jay
On Sun, Jun 15, 2008 at 12:49 PM, Jay <[EMAIL PROTECTED]> wrote:
>
> When gcc configures the in-tree gmp/mpfr, why
> does it use --host=none-${host_vendor}-${host_os}
> --target=none-${host_vendor}-${host_os}
>
> instead of --host=${host_alias} --target=${target
When gcc configures the in-tree gmp/mpfr, why
does it use --host=none-${host_vendor}-${host_os}
--target=none-${host_vendor}-${host_os}
instead of --host=${host_alias} --target=${target_alias}
This "breaks" config.cache if used across directories, because the platforms
change.
On Tue, Oct 23, 2007 at 09:54:55AM +0800, Franklin wrote:
> Hi, list.
>
> Right now I'm building new toolchain using old one provided by our vendor. I
> have built binutils and gcc-4.1.1 successfully. However while building
> glibc-2.4 it always told me:
>
> running configure fragment for npt
Hi, list.
Right now I'm building new toolchain using old one provided by our vendor. I
have built binutils and gcc-4.1.1 successfully. However while building
glibc-2.4 it always told me:
running configure fragment for nptl/sysdeps/pthread
checking for forced unwind support... no
configure: er
"Doug Gregor" <[EMAIL PROTECTED]> writes:
Am I the only one to receive Doug's recent messages with empty body?
-- Gaby
"Tabony, Charles" <[EMAIL PROTECTED]> writes:
> What does it mean by "unit none"?
First I'll note that you shouldn't see this when using the DFA
scheduler (define_insn_reservation, etc.). You should only see it
when using the old pipeline descriptio
;; -- --- -
;;917 0 012 10 - 0 none : 83 10
;; 1062 0 111 10 - 0 none : 83 33
32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12
;; 1236 0 110 10 - 0 none : 83 13
On Fri, Mar 11, 2005 at 09:54:09PM -0500, Ian Lance Taylor wrote:
>James E Wilson writes:
>
>> On Fri, 2005-03-11 at 17:48, Ian Lance Taylor wrote:
>> > All true, but I want to note that the preferred non-GNU name is
>> > sourceware.org.
>>
>> What about the trademark status? Last I heard, the tr
On Fri, Mar 11, 2005 at 04:01:51PM -0800, Joe Buck wrote:
>On Fri, Mar 11, 2005 at 03:57:02PM -0800, James E Wilson wrote:
>>System adminstration work is performed by overseers AT sources PERIOD redhat
>>PERIOD com
>
>overseers AT gcc PERIOD gnu PERIOD org works just as well, since it's the same
James E Wilson <[EMAIL PROTECTED]> writes:
> On Fri, 2005-03-11 at 17:48, Ian Lance Taylor wrote:
> > All true, but I want to note that the preferred non-GNU name is
> > sourceware.org.
>
> What about the trademark status? Last I heard, the trademark holder had
> asked us to stop using the name.
On Fri, 2005-03-11 at 17:48, Ian Lance Taylor wrote:
> All true, but I want to note that the preferred non-GNU name is
> sourceware.org.
What about the trademark status? Last I heard, the trademark holder had
asked us to stop using the name. That is when and why the machine got
renamed away from
James E Wilson <[EMAIL PROTECTED]> writes:
> On Fri, 2005-03-11 at 16:01, Joe Buck wrote:
> > [EMAIL PROTECTED] works just as well, since it's the same machine by
> > a different name. On this list we should be advertising the gcc.gnu.org
> > name, I think.
>
> True. But if you want to look at
On Fri, 2005-03-11 at 16:01, Joe Buck wrote:
> [EMAIL PROTECTED] works just as well, since it's the same machine by
> a different name. On this list we should be advertising the gcc.gnu.org
> name, I think.
True. But if you want to look at the mailing list archive, you have to
use the non GNU na
On Fri, Mar 11, 2005 at 03:57:02PM -0800, James E Wilson wrote:
> System adminstration work is performed by [EMAIL PROTECTED]
[EMAIL PROTECTED] works just as well, since it's the same machine by
a different name. On this list we should be advertising the gcc.gnu.org
name, I think.
I've usually
Toon Moene wrote:
Again I got a reaction of accepting write after approval (this time for
Feng Wang) as "processed by: None".
System adminstration work is performed by [EMAIL PROTECTED]
You should ask them. Checking the overseers mailing list archive, I
see that the last mes
Again I got a reaction of accepting write after approval (this time for
Feng Wang) as "processed by: None".
This is not encouraging - is someone reading these acceptances (despite
the "processed by: None" part) ?
FYI, Feng Wang's copyright assignment papers date from S
69 matches
Mail list logo
