Please don't cross-post to several mailing lists, this belongs on the
gcc-help mailing list only.
On Wed, 1 Mar 2023, 06:33 Kondreddy, Vinay Kumar, <
vinaykumar.kondre...@staples.com> wrote:
> Hi Team,
>
>
>
> We are using GCC 4.8.3 for one of our legacy applications i.e: Automatch.
> after dat
Hi Team,
We are using GCC 4.8.3 for one of our legacy applications i.e: Automatch. after
database upgrade from 11/2 to 19.0.0, while recompiling one of our proc program
we are getting below error. Could you please help us to resolve below issue.
Please find full error trace in above attachment.
On Thu, Oct 06, 2022 at 06:57:40PM -0400, Michael Collison wrote:
> I am trying to improve code generation for coremark to match a recent
> improvement that was made in LLVM.
>
> I added the following transformation to match.pd which attempts to replace a
> branch with straight line code:
>
> /*
On Thu, Oct 6, 2022 at 4:00 PM Michael Collison wrote:
>
> I am trying to improve code generation for coremark to match a recent
> improvement that was made in LLVM.
>
> I added the following transformation to match.pd which attempts to
> replace a branch with straight line code:
>
> /* (cond (and
I am trying to improve code generation for coremark to match a recent
improvement that was made in LLVM.
I added the following transformation to match.pd which attempts to
replace a branch with straight line code:
/* (cond (and (x , 0x1) == 0), y, (z ^ y) ) -> (-(and (x , 0x1)) & z ) ^
y */
On Apr 20, 2021, at 9:11 AM, Gabriel Paubert
mailto:paub...@iram.es>> wrote:
(lldb) di -s 0x000103d6 -c 10
libgambit.dylib`___SCMOBJ_to_NONNULLSTRING:
0x103d6 <+1504>: jl 0x103d60026 ; <+1542> at
c_intf.c:3282:9
0x103d60002 <+1506>: orb%al, 0x31(%rbp)
0
On Tue, Apr 20, 2021 at 12:20:06PM +, Lucier, Bradley J via Gcc wrote:
> I’m seeing an “Illegal Instruction” fault and don’t quite know how to
> generate a proper bug report yet.
>
> This is the compiler:
>
> [Bradleys-Mac-mini:~] lucier% /usr/local/gcc-10.3.0/bin/gcc -v
> Using built-in spe
Lucier, Bradley J via Gcc wrote:
I’m seeing an “Illegal Instruction” fault and don’t quite know how to
generate a proper bug report yet.
This is the compiler:
[Bradleys-Mac-mini:~] lucier% /usr/local/gcc-10.3.0/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-10.3.0/bin/gcc
COLLE
I’m seeing an “Illegal Instruction” fault and don’t quite know how to generate
a proper bug report yet.
This is the compiler:
[Bradleys-Mac-mini:~] lucier% /usr/local/gcc-10.3.0/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-10.3.0/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-10.3.0/l
On Fri, Jul 29, 2016 at 11:05:13AM +0200, Georg-Johann Lay wrote:
> There might still problems linger around if hard-regs are used:
>
> Suppose we set the reg in DImode and then get_last_value is called for the
> same reg in SImode. Using the DI value might be wrong, e.g. if it is used
> to com
On 29.07.2016 09:47, Segher Boessenkool wrote:
Hi Johann,
I tested a variant of your patch, building Linux for 32 different
(sub-)architectures; surprisingly (to me) there are no regressions
at all.
I am not so surprised because most backends don't make such an intense use of
hard-regs like t
Hi Johann,
I tested a variant of your patch, building Linux for 32 different
(sub-)architectures; surprisingly (to me) there are no regressions
at all.
Do you want to send it to gcc-patches?
Segher
diff --git a/gcc/combine.c b/gcc/combine.c
index 77e0d2b..750bf83 100644
--- a/gcc/combine.c
++
On Wed, Jul 27, 2016 at 09:14:27PM +0200, Georg-Johann Lay wrote:
> >diff --git a/gcc/combine.c b/gcc/combine.c
> >index 77e0d2b..dec6226 100644
> >--- a/gcc/combine.c
> >+++ b/gcc/combine.c
> >@@ -9977,6 +9977,9 @@ reg_num_sign_bit_copies_for_combine (const_rtx x,
> >machine_mode mode,
> >
Segher Boessenkool schrieb:
On Tue, Jul 26, 2016 at 03:38:18PM +0200, Georg-Johann Lay wrote:
@@ -13206,6 +13206,13 @@ get_last_value (const_rtx x)
&& DF_INSN_LUID (rsp->last_set) >= subst_low_luid)
return 0;
+ /* If the lookup is for a hard register make sure that value contains
at
On Tue, Jul 26, 2016 at 03:38:18PM +0200, Georg-Johann Lay wrote:
> >>@@ -13206,6 +13206,13 @@ get_last_value (const_rtx x)
> >> && DF_INSN_LUID (rsp->last_set) >= subst_low_luid)
> >> return 0;
> >>
> >>+ /* If the lookup is for a hard register make sure that value contains
> >>at
> >>
On 26.07.2016 14:51, Segher Boessenkool wrote:
On Tue, Jul 26, 2016 at 02:14:49PM +0200, Georg-Johann Lay wrote:
which returns const0_rtx because reg 18 is set in insn 43 to const0_rtx.
Total outcome is that the right shift of reg:DI 18 is transformed to a
no-op move and cancelled out in the rem
On Tue, Jul 26, 2016 at 02:14:49PM +0200, Georg-Johann Lay wrote:
> >>which returns const0_rtx because reg 18 is set in insn 43 to const0_rtx.
> >>Total outcome is that the right shift of reg:DI 18 is transformed to a
> >>no-op move and cancelled out in the remainder.
> >
> >Why does num_sign_bit_c
On 25.07.2016 23:05, Segher Boessenkool wrote:
On Mon, Jul 25, 2016 at 02:28:28PM +0200, Georg-Johann Lay wrote:
(insn 43 31 44 2 (set (reg:QI 18 r18)
(const_int 0 [0])) bug-combin.c:29 56 {movqi_insn}
(nil))
(insn 51 50 52 2 (set (reg:QI 16 r16)
(const_int 40 [0x28])) bu
On Mon, Jul 25, 2016 at 02:28:28PM +0200, Georg-Johann Lay wrote:
> (insn 43 31 44 2 (set (reg:QI 18 r18)
> (const_int 0 [0])) bug-combin.c:29 56 {movqi_insn}
> (nil))
> (insn 51 50 52 2 (set (reg:QI 16 r16)
> (const_int 40 [0x28])) bug-combin.c:29 56 {movqi_insn}
> (nil)
Tracking this wrong-code bug, I ended up in combine.c::get_last_value() which
returns a wrong result. gcc generates wrong code at least with: 4.9 head, 5.2,
6.1 and trunk from today.
Before combine we have:
(insn 43 31 44 2 (set (reg:QI 18 r18)
(const_int 0 [0])) bug-combin.c:29 56 {m
On 11/04/15 04:08, Kumar Aditya wrote:
> I am new user of Linux. I have RHEL 6.0 installed and want to run C++
> on my system but I do not know how.
yum install gcc-c++.
Andrew.
Hey Kumar.
Just use your package manager.
in terminal:
yum search gcc-c++
Determine which version are available.
Then run:
yum install gcc-c++
You will need root access for the install step.
If you want another version RPM’s can be found here:
http://www.rpmfind.net/linux/rpm2h
Hello GCC team,
Greetings...
I am new user of Linux. I have RHEL 6.0 installed and want to run C++
on my system but I do not know how.
Please help me or let me know where to contact.
--
Thanks & Regards,
Kumar Aditya
+919015142426
On Wed, 25 Feb 2015, Sandra Loosemore wrote:
>> Patch is a part of a series which is waiting for additional steering
>> committee approval due to copyright and a license.
> I don't imagine the documentation for *features already committed*
> needs to wait for steering committee approval; per the G
On 02/25/2015 09:47 AM, Ilya Enkovich wrote:
2015-02-25 19:16 GMT+03:00 Sandra Loosemore :
On 02/25/2015 12:56 AM, Ilya Enkovich wrote:
2015-02-24 19:47 GMT+03:00 Sandra Loosemore :
Poking around, I see that the -fcheck-pointer-bounds and various -fchkp-*
options are listed in c-family/c.op
2015-02-25 19:16 GMT+03:00 Sandra Loosemore :
> On 02/25/2015 12:56 AM, Ilya Enkovich wrote:
>>
>> 2015-02-24 19:47 GMT+03:00 Sandra Loosemore :
>>>
>>>
>>> Poking around, I see that the -fcheck-pointer-bounds and various -fchkp-*
>>> options are listed in c-family/c.opt, but they are not listed in
On 02/25/2015 12:56 AM, Ilya Enkovich wrote:
2015-02-24 19:47 GMT+03:00 Sandra Loosemore :
Poking around, I see that the -fcheck-pointer-bounds and various -fchkp-*
options are listed in c-family/c.opt, but they are not listed in the GCC
manual. The section on intrinsics is not enough, by itse
2015-02-24 19:47 GMT+03:00 Sandra Loosemore :
> On 02/24/2015 01:14 AM, Ilya Enkovich wrote:
>>
>> 2015-02-20 19:39 GMT+03:00 Sandra Loosemore :
>>>
>>> On 02/20/2015 01:12 AM, Ilya Enkovich wrote:
2015-02-20 3:48 GMT+03:00 Sandra Loosemore :
>
>
> The section "Pointer Bo
On 02/24/2015 01:14 AM, Ilya Enkovich wrote:
2015-02-20 19:39 GMT+03:00 Sandra Loosemore :
On 02/20/2015 01:12 AM, Ilya Enkovich wrote:
2015-02-20 3:48 GMT+03:00 Sandra Loosemore :
The section "Pointer Bounds Checker builtins" in extend.texi is on my
list
for being in need of copy-editing, b
2015-02-20 19:39 GMT+03:00 Sandra Loosemore :
> On 02/20/2015 01:12 AM, Ilya Enkovich wrote:
>>
>> 2015-02-20 3:48 GMT+03:00 Sandra Loosemore :
>>>
>>> The section "Pointer Bounds Checker builtins" in extend.texi is on my
>>> list
>>> for being in need of copy-editing, but reading through the exist
On 02/20/2015 01:12 AM, Ilya Enkovich wrote:
2015-02-20 3:48 GMT+03:00 Sandra Loosemore :
The section "Pointer Bounds Checker builtins" in extend.texi is on my list
for being in need of copy-editing, but reading through the existing text, I
am quite confused. In several places it refers to turn
2015-02-20 3:48 GMT+03:00 Sandra Loosemore :
> The section "Pointer Bounds Checker builtins" in extend.texi is on my list
> for being in need of copy-editing, but reading through the existing text, I
> am quite confused. In several places it refers to turning the Pointer
> Bounds Checker off, but
The section "Pointer Bounds Checker builtins" in extend.texi is on my
list for being in need of copy-editing, but reading through the existing
text, I am quite confused. In several places it refers to turning the
Pointer Bounds Checker off, but how do you do that? I don't see any
documented c
On Mon, Feb 17, 2014 at 5:28 AM, Richard Biener
wrote:
> On Mon, Feb 17, 2014 at 1:15 PM, Dominik Vogt wrote:
>> On Fri, Feb 14, 2014 at 02:40:44PM +0100, Richard Biener wrote:
>>> On Fri, Feb 14, 2014 at 9:59 AM, Dominik Vogt
>>> wrote:
>>> > Given a specific VAR_DECL tree node, I need to find
On Mon, Feb 17, 2014 at 1:15 PM, Dominik Vogt wrote:
> On Fri, Feb 14, 2014 at 02:40:44PM +0100, Richard Biener wrote:
>> On Fri, Feb 14, 2014 at 9:59 AM, Dominik Vogt
>> wrote:
>> > Given a specific VAR_DECL tree node, I need to find out whether
>> > its type is built in or not. Up to now I ha
On Fri, Feb 14, 2014 at 02:40:44PM +0100, Richard Biener wrote:
> On Fri, Feb 14, 2014 at 9:59 AM, Dominik Vogt wrote:
> > Given a specific VAR_DECL tree node, I need to find out whether
> > its type is built in or not. Up to now I have
> >
> > tree tn = TYPE_NAME (TREE_TYPE (var_decl));
> >
On Fri, Feb 14, 2014 at 9:59 AM, Dominik Vogt wrote:
> Given a specific VAR_DECL tree node, I need to find out whether
> its type is built in or not. Up to now I have
>
> tree tn = TYPE_NAME (TREE_TYPE (var_decl));
> if (tn != NULL_TREE && TREE_CODE (tn) == TYPE_DECL && DECL_NAME (tn))
>
Given a specific VAR_DECL tree node, I need to find out whether
its type is built in or not. Up to now I have
tree tn = TYPE_NAME (TREE_TYPE (var_decl));
if (tn != NULL_TREE && TREE_CODE (tn) == TYPE_DECL && DECL_NAME (tn))
{
...
}
This if-condition is true for both,
int x;
On Mon, Oct 31, 2011 at 10:58:03AM -0500, Moffett, Kyle D wrote:
> I have not yet been able to figure out if it's a libgcc issue or an
> actual compiler issue.
It is a gcc bug. I've added a comment to the PR.
--
Alan Modra
Australia Development Lab, IBM
Hello,
I'm looking for advice on how to debug and fix PR50906:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50906
The basic summary is that GCC is generating bad unwinder information or
is incorrectly saving registers onto the stack on PowerPC e500v2. Any
ordinary function call+return works fin
On 08/23/2010 11:05 AM, Mohamed Shafi wrote:
> sub.s32 srcdstGP, #imm16 // signed 16-bit register to immediate subtract
> sub.u32 srcdstGP, #imm16 // unsigned 16-bit register to immediate subtract
Having both of these is probably not useful. Bernd pointed
out that a 17-bit constant would be more
On 08/23/2010 08:05 PM, Mohamed Shafi wrote:
> sub.s32 srcdstGP, #imm16 // signed 16-bit register to immediate subtract
> sub.u32 srcdstGP, #imm16 // unsigned 16-bit register to immediate subtract
If you're using a bit to decide between these two, a better encoding
would be to just support a sing
Mohamed Shafi writes:
> I want to know if it is good to have both sign and zero extension for
> 16bit immediate.
Hard to say. It really depends on the kind of constants you expect your
programs to use. It's generally a good idea to have an efficient way to
load small constants which many progr
Hello all,
I am trying to do a port on GCC 4.5. The target has a memory
resolution of 32bits i.e. char is 32bits in the target (addr 0 selects
1st 32bit and addr 1 selects 2nd 32bit). It has only word (32bit)
access.
In terms of address resolution this target is similar to c4x which
became obsole
Hello,
Several of us are trying to put together a "PowerPCSPE" Debian port
(powerpc-linux-gnuspe, based around the e500v2), and we're experiencing a
pretty bad FP register-save bug (PR44364 [0]). Specifically, it seems like GCC
will occasionally only save half of the 64-bit double register on
Thanks
I am submitting patch to drop count to 10,000 for 16 bit int target.
Using 32 bit counter of 1 million takes a minute or so on simulator -
which is high.
The lower count is quick and only requires a (16bit) stack limit to be
lower than 10MB - which is pretty safe.
Andy
Joseph S. My
On Sun, 6 Dec 2009, Andrew Hutchinson wrote:
> The test appears to be unsafe. The original fault was failure to deallocate
> VLA on the jump - thus with the fault present the test would appear to perform
> 1 million new allocation - and fail presumably due to either execution time or
> run time er
I need advise before I submit pathc to fix the test
gcc-torture/execute/vla-dealloc-1.c (attached below)
The test appears to be unsafe. The original fault was failure to
deallocate VLA on the jump - thus with the fault present the test would
appear to perform 1 million new allocation - and fa
On 12/04/09 10:00, jose manuel Herrera Magana wrote:
i am try to star hit my password and just don't letme beginig and tele smoking
about certifiques and signaturas than i never see befor
well first things first is gcc has nothing
todo with your password settings.
maybe resetting your accoun
i am try to star hit my password and just don't letme beginig and tele smoking
about certifiques and signaturas than i never see befor
Shankar Iyer writes:
> I have compiled and generated a C++ shared library with the "-fPIC" option.
> But this shared library requires text relocation during runtime and is not
> usable on seLinux which disables writeable text segments. The text relocation
> is due to use of exceptions inside
Hi,
I have compiled and generated a C++ shared library with the "-fPIC" option.
But this shared library requires text relocation during runtime and is not
usable on seLinux which disables writeable text segments. The text relocation
is due to use of exceptions inside the shared library. There
Vikram KS wrote:
So in the back-end there are driver options that will help me to
invoke the existing tool-chain through GCC driver. But the assembler
takes only .sl extensions. I tried to replace the .s extension with
.sl extension. But by default the cc1 will have some options passed
from the
On Thu, Jul 30, 2009 at 8:14 PM, Basile STARYNKEVITCH
wrote:
>
> Vikram KS wrote:
>>
>> Hi,
>>
>> I have some question on gcc driver.
>
> You really should give more context. Are you doing cross-compilation? Are you
> patching the GCC sources? Why do you want to generate a *.sl file? What are
>
Vikram KS wrote:
Hi,
I have some question on gcc driver.
You really should give more context. Are you doing cross-compilation?
Are you patching the GCC sources? Why do you want to generate a *.sl
file? What are your host & target systems?
Whenever we invoke gcc, it'll pass some default opt
Hi,
I have some question on gcc driver.
Whenever we invoke gcc, it'll pass some default options to the
compiler, assembler linker etc. But if i dont want to pass all these
default options but only some of them, what should i do?
For eg: gcc will pass the following option to cc1
/usr/libexec/gcc
Hi,
My name is Mallik and I work for Sun. I need a favor from you. I need
to cross compile our product to work on x86 Atom Processor on CentOS.
Could you please point me to the link where I can download the gcc
binaries. I downloaded the source from ix86/gcc-4_4-branch but facing
some pro
This list is for discussing GCC development, not deal with usage
problems. Please try asking [EMAIL PROTECTED]
Thanks,
Ben
Hi,
I appreciate if someone can help me with my linking error:
In my "c++" options , i already have ' -L/usr/local/lib -lgnet-2.0'.
I get a number of '7: undefined reference to `gnet_conn_readline'' errors.
Can you please tell me why the linking fails? I have the 'gnet.h'
include in my .cpp an
On Mon, Feb 25, 2008 at 3:23 PM, Mag cool <[EMAIL PROTECTED]> wrote:
> hi, i am a beginner in this tech world. i want to learn 1/how to do
> programming in c in unix or linux. i don't know anything about linux. where
> to start.
>
Try this book: http://www.advancedlinuxprogramming.com/
>
>
>
hi, i am a beginner in this tech world. i want to learn how to do programming
in c in unix or linux. i don't know anything about linux. where to start.
Looking for last minute shopping deals?
Find them
hi, i am a beginner in this tech world. i want to learn 1/how to do programming
in c in unix or linux. i don't know anything about linux. where to start.
Never miss a thing. Make Yahoo your home page.
h
Hello!
Execuse me but I have something bothering me.
I inserted a method into rest_of_compilation() (before calling
rest_of_handle_life()) to insert some new insn before insn were
translated to asm. But after my modification, when processing some
insn moving one pseudo reg to another ps
Michael_fogel writes:
> Hello
>
> For my diploma thesis I have to implement a new back-end for GCC.
> The microcontroller is based on an FPGA and was developed one year ago.
> Only an Assembler is available and now my university lecturer wants an C
> compiler too. I decided to use GCC in v
Hello
For my diploma thesis I have to implement a new back-end for GCC.
The microcontroller is based on an FPGA and was developed one year ago.
Only an Assembler is available and now my university lecturer wants an C
compiler too. I decided to use GCC in version 4.2.1 as basis for the new
comp
> I don't know about using reference types, but there are several math
> builtins that "return" multiple values, the extra ones via pointer
> arguments. E.g. see frexp, lgamma_r, modf, remquo and/or sincos.
Like I said, I'm kinda locked into the syntax. People have been using
these builtins for
On Thu, 9 Aug 2007, DJ Delorie wrote:
> Could someone provide a hint for me? I'm trying to put in "real"
> prototypes for a builtin function where the arguments don't follow the
> default promotion rules. Specifically, one of the arguments is a
> reference type (like C++'s "int&"). However, I'm
I'm hoping I can get it to do what I want, if only I can get the MI to
treat the function definition given to it by the target as the one
true definition, and not just some advisory one.
DJ Delorie <[EMAIL PROTECTED]> writes:
> Is there a trick to this? I need this type of functionality because
> some builtins modify multiple values, so a simple return value is
> insufficient, plus this worked with older versions of gcc so our users
> are used to it syntax-wise.
I've never found
Could someone provide a hint for me? I'm trying to put in "real"
prototypes for a builtin function where the arguments don't follow the
default promotion rules. Specifically, one of the arguments is a
reference type (like C++'s "int&"). However, I'm bumping into two
problems:
1. The compiler e
On Mon, Oct 02, 2006 at 12:42:04PM +0200, Wolfgang Mües wrote:
> Now it's time to give a big "thank you" to all persons involved,
> ecpecially Rask Ingemann Lambertsen with his invaluable help.
>
> As I started this project, I feared that I would never succeed, and
> now ... the modified compile
Now it's time to give a big "thank you" to all persons involved,
ecpecially Rask Ingemann Lambertsen with his invaluable help.
As I started this project, I feared that I would never succeed, and
now ... the modified compiler is used about 3 month now, and DSLINUX
with this crude modification is
Rask,
On Sunday 06 August 2006 02:05, Rask Ingemann Lambertsen wrote:
> Yes, it only cures the symptom, but it could take a lot of time to
> find the cause, and the gain is small, so I think it is OK to leave
> it like this for now.
OK.
> This insn was generated from the "reload_outqi" pattern. I
On Sat, Aug 05, 2006 at 09:03:34PM +0200, Wolfgang Mües wrote:
> First, I have had a problem with loading a register with a constant.
> (no clobber). I have solved this problem by adding
>
> > (define_insn "_arm_movqi_insn_const"
[cut]
>
> I am very shure that this does only cure the symptoms, a
Rask,
On Friday 21 July 2006 15:26, Rask Ingemann Lambertsen wrote:
> I found that this peephole optimization improves the code a whole
> lot:
Done.
> Another way of improving the code was to swap the order of the two
> last alternatives of _arm_movqi_insn_swp.
Done.
Anyway, the problems with
On Thu, Jul 20, 2006 at 04:37:41PM +0200, Rask Ingemann Lambertsen wrote:
> ;; This is primarily a hack for the Nintendo DS external RAM.
> (define_insn "_arm_movqi_insn_swp"
> [(set (match_operand:QI 0 "reg_or_Qmem_operand" "=r,r,r,Q,Q")
> (match_operand:QI 1 "general_operand" "rI,K,m,r,r"
On Thu, Jul 20, 2006 at 03:27:49PM +0200, Rask Ingemann Lambertsen wrote:
> (define_expand "reload_outqi"
> [(clobber (match_operand:QI 0 "memory_operand" "=Q"))
>(clobber (match_operand:DI 2 "register_operand" "=&r"))
>(set (match_dup 4) (match_dup 5))
>(parallel [
>(set (match_
On 20 July 2006 16:25, Ian Lance Taylor wrote:
> "Dave Korn" <[EMAIL PROTECTED]> writes:
>
>> Is there any generic advice available as to when and why one should use
>> emit_insn (gen_rtx_SET ()) as opposed to emit_move_insn (...)?
>
> It depends on where you are in the compiler. You can
"Dave Korn" <[EMAIL PROTECTED]> writes:
> Is there any generic advice available as to when and why one should use
> emit_insn (gen_rtx_SET ()) as opposed to emit_move_insn (...)?
It depends on where you are in the compiler. You can only use
gen_rtx_SET if you know that the resulting insn w
On Wed, Jun 07, 2006 at 07:22:31AM +0200, Wolfgang Mües wrote:
> On Tuesday 06 June 2006 21:33, Rask Ingemann Lambertsen wrote:
>
> > Yet another register which stands a good chance of being reusable is
> > the register containing the address.
>
> Yes, but that is not allowed according to the spe
On Thu, Jul 20, 2006 at 08:02:45AM +0200, Wolfgang Mües wrote:
> But it's not the only function which uses gen_rtx_SET. There are also
> much places with
>
> > emit_constant_insn (cond,
> > gen_rtx_SET (VOIDmode, target, source));
>
> Isn't it better to replace gen_rtx_SET?
gen_rtx_SET()
On Thu, 2006-07-20 at 12:04, Dave Korn wrote:
> On 20 July 2006 07:03, Wolfgang Mües wrote:
>
> > Hello Rask,
> >
> > On Wednesday 19 July 2006 13:24, Rask Ingemann Lambertsen wrote:
> >> I've spotted a function named emit_set_insn() in arm.c. It might be
> >> the problem, because it uses gen_rtx
On 20 July 2006 07:03, Wolfgang Mües wrote:
> Hello Rask,
>
> On Wednesday 19 July 2006 13:24, Rask Ingemann Lambertsen wrote:
>> I've spotted a function named emit_set_insn() in arm.c. It might be
>> the problem, because it uses gen_rtx_SET() directly.
>
> But it's not the only function which u
Hello Rask,
On Wednesday 19 July 2006 13:24, Rask Ingemann Lambertsen wrote:
> I've spotted a function named emit_set_insn() in arm.c. It might be
> the problem, because it uses gen_rtx_SET() directly.
But it's not the only function which uses gen_rtx_SET. There are also
much places with
> e
On Wed, Jul 19, 2006 at 01:24:59PM +0200, Rask Ingemann Lambertsen wrote:
>
> The function named emit_move_insn() ought to do the trick here, but
> is perhaps a bit heavyweight for this purpose. Anyway, try this patch
> (untested), which should plug this particular hole:
There was an unbalanced p
On Wed, Jul 19, 2006 at 07:52:32AM +0200, Wolfgang Mües wrote:
> Hello,
>
> after getting a "working" version of the gcc 4.0.2 with the Nintendo
> 8-bit-write problem, I was busy the last weeks trying to adapt the
> linux system (replacing I/O with writeb() macros, removing strb
> assembler cal
Hello,
after getting a "working" version of the gcc 4.0.2 with the Nintendo
8-bit-write problem, I was busy the last weeks trying to adapt the
linux system (replacing I/O with writeb() macros, removing strb
assembler calls).
However, it turned out that the sources of the linux kernel are a far
[EMAIL PROTECTED] writes:
> I am getting the following compilation error:
>
> /tmp/ccIUvX3i.o(.gnu.linkonce.d._ZTV4ListIiE+0x8): undefined reference to
> `List::Find(int const&)'
Wrong mailing list. This sort of question should go to
[EMAIL PROTECTED] Thanks.
I don't know the answer to your q
Hi :
I am getting the following compilation error:
/tmp/ccIUvX3i.o(.gnu.linkonce.d._ZTV4ListIiE+0x8): undefined reference to
`List::Find(int const&)'
the declaration is:
virtual int Find (const Etype &X);
and the definition is:
template
int
List::Find (const Etype &X){
Node
On Jun 28, 2006, at 1:59 PM, [EMAIL PROTECTED] wrote:
I am a PhD student working on optimal instruction scheduling
problems. I want to
integrate my scheduler into the GCC. Can you tell me where to
start? and
important links which can be helpful for the integration work?
I'd start by downlo
hello:
I am a PhD student working on optimal instruction scheduling problems. I want
to
integrate my scheduler into the GCC. Can you tell me where to start? and
important links which can be helpful for the integration work?
Thanks
Abid Malik
This mail
On Fri, Jun 02, 2006 at 09:24:17AM +0200, Rask Ingemann Lambertsen wrote:
> The rest of the ARM backend presently assumes that the pattern has the form
>
> (set (operand:QI 0) (operand:QI 1))
>
> but now we've changed it to
>
> (parallel [(set (operand:QI 0) (operand:QI 1))
> (clobber
On Thu, Jun 08, 2006 at 11:02:12PM +0200, Wolfgang Mües wrote:
> Rask,
>
> > arm-elf-gcc -g -mswp-byte-writes -Wall -O2 -fomit-frame-pointer
> > -ffast-math -mthumb-interwork -isystem
> > /usr/lib/devkitpro/libnds/include -mcpu=arm9tdmi -mtune=arm9tdmi
> > -DARM9 -S arm9_main.c -o arm9_main.S arm9
Rask,
On Thursday 08 June 2006 20:12, Rask Ingemann Lambertsen wrote:
> Also, undo the change to arm_legitimate_address_p() arm.c.
Hmmm
> arm-elf-gcc -g -mswp-byte-writes -Wall -O2 -fomit-frame-pointer
> -ffast-math -mthumb-interwork -isystem
> /usr/lib/devkitpro/libnds/include -mcpu=arm9td
On Tue, Jun 06, 2006 at 08:27:10PM +0200, Rask Ingemann Lambertsen wrote:
> On Tue, Jun 06, 2006 at 10:39:46AM +0100, Richard Sandiford wrote:
> > This is just a guess, but the insn above might be an output reload.
>
> It is, in a peculiar (and not useful) way. Diffing the greg dump against
> the
On Wed, 2006-06-07 at 06:22, Wolfgang Mües wrote:
> Rask,
>
> On Tuesday 06 June 2006 21:33, Rask Ingemann Lambertsen wrote:
> > > > + swp%?b\\t%1, %1, %0\;ldr%?b\\t%1, %0"
> > >
> > > You should get a price for cleverness here!
> >
> > Thanks! Indeed it looks good until you think of volatile va
Rask,
On Tuesday 06 June 2006 21:33, Rask Ingemann Lambertsen wrote:
> > > + swp%?b\\t%1, %1, %0\;ldr%?b\\t%1, %0"
> >
> > You should get a price for cleverness here!
>
> Thanks! Indeed it looks good until you think of volatile variables.
Because volatile variables can change their values from
On Tue, Jun 06, 2006 at 07:42:20AM +0200, Wolfgang Mües wrote:
> Rask,
>
> On Monday 05 June 2006 16:16, Rask Ingemann Lambertsen wrote:
> > I think the comment in arm.h is wrong. The manual seems to agree with
> > the code.
>
> Just to make it easy for beginners...
In mainline GCC, it is defin
On Tue, Jun 06, 2006 at 10:39:46AM +0100, Richard Sandiford wrote:
> Wolfgang Mües <[EMAIL PROTECTED]> writes:
> >> ../../../gcc-4.0.2/gcc/unwind-dw2-fde.c: In function
> >> __register_frame_info_table_bases':
> >> ../../../gcc-4.0.2/gcc/unwind-dw2-fde.c:146: error: insn does not
> >> satisfy its
Wolfgang Mües <[EMAIL PROTECTED]> writes:
> On Sunday 04 June 2006 23:36, Rask Ingemann Lambertsen wrote:
>> On Wed, May 31, 2006 at 10:49:35PM +0200, Wolfgang Mües wrote:
>> > > (define_insn "*arm_movqi_insn"
>> > > [(set (match_operand:QI 0 "nonimmediate_operand" "=r,r,r,m")
>> > > (match_oper
1 - 100 of 144 matches
Mail list logo
