> I would be interested in looking at the data sheet for this chip. I
> didn't see which chip it was. The thing that has me curious is the
> negative shift counts. Can a right shift of a negative count (of
> some type (rotate?)) substitute for a left shift when the shift is
> greater than 16?
On Jan 11, 2006, at 10:11 PM, Ian Lance Taylor wrote:
DJ Delorie <[EMAIL PROTECTED]> writes:
I don't know whether any other chip has this particular limitation,
but it's not hard to handle. ashlsi3 and friends should be a
define_expand which turn an overly large CONST_INT into two shifts,
lo
On Jan 10, 2006, at 9:46 PM, David Edelsohn wrote:
Perry Smith writes:
Perry> The call to _restf14 is not explicit so I assume the
compiler is
Perry> generating it for some reason.
Yes, because one of the exception handling support functions can
clobber all registers, but also can
Perry Smith <[EMAIL PROTECTED]> writes:
> The problem: In the particular build I am trying to do, when
> libgcc2.c is compled with -DL_floatdidf, instead of defining a
> routine called _floatdidf or __floatdidf, it creates a routine called
> __floattidf which references __floatdidf.
...
> This i
DJ Delorie <[EMAIL PROTECTED]> writes:
> > I don't know whether any other chip has this particular limitation,
> > but it's not hard to handle. ashlsi3 and friends should be a
> > define_expand which turn an overly large CONST_INT into two shifts,
> > load the shift count into a register, whichev
On Thu, 2006-01-12 at 00:55 +0100, Bernd Schmidt wrote:
> Daniel Berlin wrote:
> > On Wed, 11 Jan 2006, Bernd Schmidt wrote:
> >> The merge script relies only on the svnmerge-integrated property, not
> >> on the commit messages?
> >
> >
> > Right.
> >
> > It's just trying to generate a nice mes
I'm not sure how to present all this so bear with me:
The problem: In the particular build I am trying to do, when
libgcc2.c is compled with -DL_floatdidf, instead of defining a
routine called _floatdidf or __floatdidf, it creates a routine called
__floattidf which references __floatdidf.
> I don't know whether any other chip has this particular limitation,
> but it's not hard to handle. ashlsi3 and friends should be a
> define_expand which turn an overly large CONST_INT into two shifts,
> load the shift count into a register, whichever is likely to be
> better. The MIPS16 does t
DJ Delorie <[EMAIL PROTECTED]> writes:
> > I have observed the following behavior while using "float" and
> > "double" data types for m16c target. Any computation involving a
> > "float" or a "double" data type does not work on the m16c hardware.
> > However, the correct values can be observed usi
Eric Christopher <[EMAIL PROTECTED]> writes:
| So, for calls in c++ we're warning unconditionally on something like:
|
| int bar (int a, int b);
|
| int main (void)
| {
|float foo = 5.0;
|float baz = 10.0;
|
|bar (foo, baz);
|
|return 0;
| }
|
| int bar (int a, int b)
| {
|
So, for calls in c++ we're warning unconditionally on something like:
int bar (int a, int b);
int main (void)
{
float foo = 5.0;
float baz = 10.0;
bar (foo, baz);
return 0;
}
int bar (int a, int b)
{
return a + b;
}
whereas in C we're warning depending on Wtraditional or Wconversio
Ron McCall <[EMAIL PROTECTED]> writes:
> On Wed, Jan 11, 2006 at 12:03:42PM -0600, Perry Smith wrote:
> > Is there a way to get some type of debugging output that tells me
> > what line of C code produced what lines of asm code?
>
> How about $TARGET-objdump --disassemble --source?
That's tota
Daniel Berlin wrote:
On Wed, 11 Jan 2006, Bernd Schmidt wrote:
The merge script relies only on the svnmerge-integrated property, not
on the commit messages?
Right.
It's just trying to generate a nice message for you, but in our world,
the messages are so huge as to be useless.
I've fixed
On 1/11/06, Perry Smith <[EMAIL PROTECTED]> wrote:
> Is there a way to get some type of debugging output that tells me
> what line of C code produced what lines of asm code?
Do the .loc directives in the .s files produced by gcc -S work for
you? The arguments to .loc are the file number, line num
On Wed, 11 Jan 2006, Bernd Schmidt wrote:
Joern RENNECKE wrote:
Your merges are spamming the bugzilla database and anybody who is on the CC
list of the affected bugs.
both 20470 and 19199 got 1.2 Megabytes of ChangeLog.
Argh. That's a side effect of the merge script I wasn't expecting. Wh
On Wed, 11 Jan 2006, Bernd Schmidt wrote:
Giovanni Bajo wrote:
Bernd Schmidt <[EMAIL PROTECTED]> wrote:
Your merges are spamming the bugzilla database and anybody who is on
the CC list of the affected bugs.
both 20470 and 19199 got 1.2 Megabytes of ChangeLog.
Argh. That's a side effect
On Wed, Jan 11, 2006 at 12:03:42PM -0600, Perry Smith wrote:
> Is there a way to get some type of debugging output that tells me
> what line of C code produced what lines of asm code?
How about $TARGET-objdump --disassemble --source?
Ron
On Wednesday 11 January 2006 13:03, Perry Smith wrote:
> Is there a way to get some type of debugging output that tells me
> what line of C code produced what lines of asm code?
>
$ gcc -Wa,-ahlsdn -gstabs
Steven, actually the last piece of mail I sent you was a lie.
The bug I fixed is different.
The problem is that between the time that I check my code in an now,
someone changed the representation of BASIC_BLOCK.
lorien:~/gccDFTest/gcc(27) diff basic-block.h ../../gccBaseline/gcc
370c370
<
On Wed, Jan 11, 2006 at 12:10:32PM +0100, Leif Ekblad wrote:
> In configure script, line 2580, there is a link test which checks if
> an executable can be generated. The config.log file emits the
> following errors:
>
> /usr/local/bin/rdos-ld: unrecognised emulation mode: -o
> Supported emulations
Hi Andreas,
/cvs/gcc-svn/trunk/gcc/df-core.c: In function ‘df_compact_blocks’:
/cvs/gcc-svn/trunk/gcc/df-core.c:795: error: invalid lvalue in assignment
/cvs/gcc-svn/trunk/gcc/df-core.c:803: error: invalid lvalue in assignment
/cvs/gcc-svn/trunk/gcc/df-core.c: In function ‘df_bb_replace’:
/cvs/g
Steven Bosscher wrote:
Hi,
I can't build the trunk today:
gcc -c -O0 -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
-Wold-style-definition -Wmissing-format-attribute-DHAVE_CONFIG_H -I. -I.
-I../../trunk/gcc
Hi,
I can't build the trunk today:
gcc -c -O0 -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
-Wold-style-definition -Wmissing-format-attribute-DHAVE_CONFIG_H -I. -I.
-I../../trunk/gcc -I../../trunk/gcc/. -I../
On Wednesday 11 January 2006 21:44, Steven Bosscher wrote:
> Hi,
>
> I can't build the trunk today:
>
> gcc -c -O0 -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
> -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
> -Wold-style-definition -Wmissing-format-attribute
Bootstrap now fails for me with:
/cvs/gcc-svn/trunk/gcc/df-core.c: In function ‘df_compact_blocks’:
/cvs/gcc-svn/trunk/gcc/df-core.c:795: error: invalid lvalue in assignment
/cvs/gcc-svn/trunk/gcc/df-core.c:803: error: invalid lvalue in assignment
/cvs/gcc-svn/trunk/gcc/df-core.c: In function ‘df
> I have observed the following behavior while using "float" and
> "double" data types for m16c target. Any computation involving a
> "float" or a "double" data type does not work on the m16c hardware.
> However, the correct values can be observed using GDB simulator.
I figured out what the root
Is there a way to get some type of debugging output that tells me
what line of C code produced what lines of asm code?
Thank you,
Perry
By adding the 'ULL' prefix I was able to get rid of the warning.
Thanks,
Steve Heck
--
View this message in context:
http://www.nabble.com/ggc-3.3.2-on-aix-5.2-long-long-type--t890504.html#a2324330
Sent from the gcc - Dev forum at Nabble.com.
David Edelsohn wrote:
"Joel Sherrill writes:
Joel> With code updated this morning, powerpc-rtems fails to build. I am
Joel> using binutils 2.16.1 with just a couple of patches.
Joel> Is this a gcc or binutils error? Is there a known fix?
This is not a known problem. There have b
The general problem is probably the same as PR 13358 (one that I've wished was
fixed for a while, myself). Unfortunately there is no way as of now to disable
this warning, short of disabling warnings entirely.
-Jack
On Tue, Jan 10, 2006 at 01:18:11PM -0800, sabreman (sent by Nabble.com) wrote:
>
> "Joel Sherrill writes:
Joel> With code updated this morning, powerpc-rtems fails to build. I am
Joel> using binutils 2.16.1 with just a couple of patches.
Joel> Is this a gcc or binutils error? Is there a known fix?
This is not a known problem. There have been a lot of patches
With code updated this morning, powerpc-rtems fails to build. I am
using binutils 2.16.1 with just a couple of patches.
Is this a gcc or binutils error? Is there a known fix?
==
/home/joel/gcc-work/head/b-powerpc-rtems4.7/./gcc/xgc
Hello,
> > > > http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00670.html
> > > > -- a patch to make dumps in several loop optimization passes
> > > > (ivopts, vectorizer, ...) easier to read, by having scev & data
> > > > dependence analysis dumps disabled by default
> > >
> > > Not completely OK.
Hello,
> [ Moved from gcc-patches ]
>
> On Tuesday 10 January 2006 11:26, Zdenek Dvorak wrote:
>
> > > > http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00670.html
> > > > -- a patch to make dumps in several loop optimization passes
> > > > (ivopts, vectorizer, ...) easier to read, by having scev
[ Moved from gcc-patches ]
On Tuesday 10 January 2006 11:26, Zdenek Dvorak wrote:
> > > http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00670.html
> > > -- a patch to make dumps in several loop optimization passes
> > > (ivopts, vectorizer, ...) easier to read, by having scev & data
> > > depende
On 10 Jan 2006, Jonathan Wakely uttered the following:
> I can't help to put the 3.4.5 docs there, but the 3.4.4 docs are
> available, just change the 5 in the broken URLs to a 4.
>
> I don't know for certain, but I doubt the changes were very significant.
A brief `svn diff' shows that there were
Beg your pardon, I lost the CC.
regards.
- Forwarded message from [EMAIL PROTECTED] -
Date: Wed, 11 Jan 2006 02:16:10 -0600
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: Re: matrix linking
To: Sean Callanan <[EMAIL PROTECTED]>
Dear Sean.
Thank you very much
In configure script, line 2580, there is a link test which checks if
an executable can be generated. The config.log file emits the
following errors:
/usr/local/bin/rdos-ld: unrecognised emulation mode: -o
Supported emulations: elf_i386
collect2: ld returned status 1 exit status.
This error later
I am not sure, but it seems that this should have been sent to
[EMAIL PROTECTED] (it seems to be off-topic).
Is this scsi_buf.h a system header file?
Is it enough to have an empty c file with a single
#include
to trigger the warning?
>From an experience I had 2 weeks ago with gcc+aix, gcc can
39 matches
Mail list logo
