Hi.
I'm just asking if this is a known bug. If not I'll prepare a bug report,
with bzipped preprocessed source.
I'm seeing this:
hpm05fuvec0.cpp:5538: internal compiler error: Floating point exception
Please submit a full bug report,
quite often when compiling large chunks of machine-generated C++
hi,
i am using the arm-elf-gcc compiler to generate the assembly code
arm-elf-gcc -mthumb -S new.c
after this i use the arm-elf-as for genrating machine code
arm-elf-as new.s
it produces one a.out file..
arm-elf-ld a.out
produces error like
arm-elf-ld: warning: cannot find entry sym
John Vickers <[EMAIL PROTECTED]> wrote:
> I can have another go without the "--disable-checking" if that's
> likely to help. Anything else you'd like in the bug report ?
Please submit the smallest preprocessed source you can machine-generate which
shows the bug.
Thanks!
Giovanni Bajo
Hi Aram,
i am using the arm-elf-gcc compiler to generate the assembly code
arm-elf-gcc -mthumb -S new.c
after this i use the arm-elf-as for genrating machine code
arm-elf-as new.s
Note - these two steps could be combined into one by using the -c switch
instead of the -S switch:
arm-elf-gcc -
James E Wilson <[EMAIL PROTECTED]> wrote on 18/03/2005 07:43:55:
>
> You either have to keep all REG_NOTES up to date, or call code that will
> recompute them. You can recompute REG_DEAD/REG_UNUSED notes by calling
> back into flow. This is presumably what happens when you mark the block
>
BTW, if anybody replies, could you keep me in the CC: header?
I do read this list, but it won't be convenient in the next few days.
Thanks,
-Miles
--
.Numeric stability is probably not all that important when you're guessing.
Robert Dewar wrote:
Joern RENNECKE wrote:
You need to be able to set the value of a parameter over a widely
varying range, what makes you think you can pick two values that
will cover all cases, or 4 or 6 for that matter.
It will likely cover most, but not all cases. With 12 values, you can cover
Joern RENNECKE wrote:
You need to be able to set the value of a parameter over a widely
varying range, what makes you think you can pick two values that
will cover all cases, or 4 or 6 for that matter.
In order to allow to specify the exact size of the pool, you can provide
the
source of the lib
Hi,
I did merge to tree profiling yesterday and committing to the tree
didn't went correctly, so tree was messed up till today. So if
something breaks for you, please just update and hopefully everything
will be OK now.
Honza
Starting around 2005-03-17, I haven't been able to compile
several SPEC tests with mainline. Has there been any change in
the pre-processor that might explain these errors?
I'm pretty sure my installation is correct because this worked
until 2005-03-15, the system header files are all there and I
Hi,
On Fri, 18 Mar 2005, Diego Novillo wrote:
> Starting around 2005-03-17, I haven't been able to compile
> several SPEC tests with mainline. Has there been any change in
> the pre-processor that might explain these errors?
>
> I'm pretty sure my installation is correct because this worked
> u
Hi All!
I have converted the AVR port from CC0 to CCmode.
But may be I have converted the port in wrong way.
(It's because I was interested in *this* way.)
I have used CCmode register and havn't added the
'(clobber (reg:QI CC_REGNUM))' to any insn that really clobber the
CC_REGNUM just because AV
Aurora SPARC Linux release 2.0 (Kashmir FC3) UltraSparc IIi (Sabre) sun4u:
binutils-2.15.94.0.2-1.sparc
bison-1.875c-2.sparc
dejagnu-1.4.4-2.noarch
expect-5.42.1-1.sparc
gcc-3.4.2-6.fc3.sparc
gcc4-4.0.0-0.8sparc.sparc
glibc-2.3.3-99.sparcv9
glibc-2.3.3-99.sparc64
glibc-devel-2.3.3-99.sparc64
glibc
--enable-languages=c,ada,c++
Thread model: posix
gcc version 4.0.0 20050318 (prerelease)
/usr/local/src/branch/objdir32/gcc/cc1 -E -quiet -v -iprefix
/usr/local/src/branch/objdir32/gcc/../lib/gcc/sparc-linux/4.0.0/
-isystem /usr/local/src/branch/objdir32/gcc/include
/usr/local/src/branch/gcc/gcc/
I'm sitting here analyzing a regression with some pending jump threading
changes and I've stumbled upon this quirk in IV opts which, if nothing
else, makes it very difficult to evaluate the jump threading changes.
Specifically, the set of IVs selected for a loop changes when the
version #s of ob
> Denis wrote:
> I have converted the AVR port from CC0 to CCmode.
> But may be I have converted the port in wrong way.
> (It's because I was interested in *this* way.)
>
> I have used CCmode register and havn't added the
> '(clobber (reg:QI CC_REGNUM))' to any insn that really clobber the
> CC_RE
Hello,
> Which appears to walk down the array and try and choose better IV sets.
> Since it walks down the IV array, which is in SSA_NAME_VERSION order.
> Thus two loops which are equivalent in all ways except that they use
> different SSA_NAME_VERSIONs can get different IV sets.
>
> Anyway, the
Jeffrey A Law wrote:
On Fri, 2005-01-21 at 17:50 +0100, Giovanni Bajo wrote:
Why not putting it on a branch? If you are going to finish and submit it for
4.1, it might be easier to use CVS.
It might also be easier for those of us who want to play with the code,
without having to find a suitable syn
On Thursday, March 17, 2005, at 11:37 AM, Mike Stump wrote:
So, I've been working on mudflap for darwin8, and these are the
results I get... I know what you're thinking, it's impossible to get
it working because it doesn't have --wrap and friends.. well, I
pulled some magic pixie dust out and
On Fri, Mar 18, 2005 at 03:02:53PM +0100, Michael Matz wrote:
> Hi,
>
> On Fri, 18 Mar 2005, Diego Novillo wrote:
>
> > Starting around 2005-03-17, I haven't been able to compile
> > several SPEC tests with mainline. Has there been any change in
> > the pre-processor that might explain these err
> Steven Bosscher wrote:
>> Mostafa Hagog <[EMAIL PROTECTED]> wrote:
>> This is interesting, so there could be cases were want to copy CC
>> register when doing SMS. what happens if we want to move the set
>> of a CC to another iteration of the loop ? or the use of the CC ? but
>> usually this is
Paul Schlie <[EMAIL PROTECTED]> writes:
> > Denis wrote:
> > I have converted the AVR port from CC0 to CCmode.
> > But may be I have converted the port in wrong way.
> > (It's because I was interested in *this* way.)
> >
> > I have used CCmode register and havn't added the
> > '(clobber (reg:QI C
mrs wrote:
> [...] The question is, how decent are the results and can you spot
> any systematic wrongs that appear and/or can you identify any
> non-portableness to darwin of mudflap? I started from 89
> passes... > :-) [...]
Most of the FAILs are "output pattern test" failures, related to so
I have a function F written in IA64 assembly language function. This
function is invoked from a C program P. If I compile P with gcc (version
3.2.3) under Linux, and with no optimization options, the resulting
executable runs flawlessly. If I compile P with -O then the resulting executable
fails.
Is it possible with gcc to specify that a portion of code should be
compiled without any optimizations, overriding the -O option given in
the command line? The solution consisting of isolating that portion of
code, and placing it in a separate file is not what I am looking for.
On Fri, Mar 18, 2005 at 02:46:30PM -0800, JCA wrote:
>Is it possible with gcc to specify that a portion of code should be
> compiled without any optimizations, overriding the -O option given in
> the command line? The solution consisting of isolating that portion of
> code, and placing it in a
JCA <[EMAIL PROTECTED]> writes:
> It would be useful if somebody knowledgeable could tell me what
> IA64 registers does gcc expect to be preserved on return of function
> calls; I am familiar with the convention for IA64 assembly language
> and C, but I do not know what gcc assumes in this respe
> From: Denis Chertykov <[EMAIL PROTECTED]>
>> Paul Schlie <[EMAIL PROTECTED]> writes:
>>> Denis wrote:
>>> I have converted the AVR port from CC0 to CCmode.
>>> But may be I have converted the port in wrong way.
>>> (It's because I was interested in *this* way.)
>>>
>>> I have used CCmode registe
Denis Chertykov wrote:
I have converted the AVR port from CC0 to CCmode.
That's indeed very good news. Incidentally, CC0
conversion of the AVR target was being discussed
in an off-list thread with Andy Hutchinson.
But may be I have converted the port in wrong way.
(It's because I was interested i
Snapshot gcc-3.4-20050318 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20050318/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.4 CVS branch
with the following options: -rgcc-ss-3_4-20050318
You'll
VIEW_CONVERT_EXPR is tcc_reference, but we can have a statement like:
x = 22;
What ends up happening here is that find_interesting_uses_stmt calls
find_interesting_uses_address, which goes down the references and
runs into the constant, which it doesn't know how to handle. I think
the s
Bernd Schmidt wrote:
> I have created a new branch, "reload-branch", on which I'm going to
> check in these changes.
Thanks!
With three changes described below, I'm able to bootstrap and test the
reload-branch on s390-ibm-linux and s390x-ibm-linux without regressions
against head (except two ad
Bernd Schmidt <[EMAIL PROTECTED]> wrote:
>>> It might also be easier for those of us who want to play with the
>>> code, without having to find a suitable sync point between the
>>> patch and
>>> mainline sources.
>>
>> I have created a new branch, "reload-branch", on which I'm going to
>> check i
Giovanni Bajo wrote:
What is your plan for this branch? Is there more code refactoring/rewriting
planned, or are you just going to give it a wider testing and fix fallout bugs,
in preparation for a merge?
There's one known design flaw wrt. to enble_optional/disable_optional,
and I think autoinc re
I'm running into a bug with gcc 3.4.3:
I've got syscall code for user-land to our kernel that trashes r14/lr.
The code is inlined, and works find in ARM mode. When compiling in thumb,
gcc does not preserve lr. With an older gcc 3.3.3, the code was not inlined,
but generated correctly.
L4_INLINE
35 matches
Mail list logo
