RE: How to enable Mudflap in gcc 4.x?

[Deepen Mantri]

Frank Ch. Eigler <[EMAIL PROTECTED]> wrote:
>libmudflap needs to know the know the name of the entry point symbol,
>to enable one of its heuristics.  See the ENTRY_POINT area in
>configure.ac, and update it for your own runtime.  Be aware that
>libmduflap's libc-wrapper functions may need porting for your libc.

Thanks for the reply. 
When I try to build the libmudflap library separately for
(Renesas)sh-elf target after building the complete toolchain, it
automatically gets configured for i386-redhat-linux target. 
Is it the case that libmudflap only supports i386 target and not others?

Do I need to port it for sh-elf target?

 
Regards,
Deepen Mantri

KPIT Cummins InfoSystems Ltd.
Pune, India

~
Free download of GNU based tool-chains for Renesas' SH, H8, R8C, 
M16C and M32C Series. The following site also offers free technical 
support to its users. Visit http://www.kpitgnutools.com for details.
Latest versions of KPIT GNU tools were released on February 6, 07
~~

Re: How to enable Mudflap in gcc 4.x?

[Eric Christopher]

On Jun 4, 2007, at 12:09 AM, Deepen Mantri wrote:




Frank Ch. Eigler <[EMAIL PROTECTED]> wrote:

libmudflap needs to know the know the name of the entry point symbol,
to enable one of its heuristics.  See the ENTRY_POINT area in
configure.ac, and update it for your own runtime.  Be aware that
libmduflap's libc-wrapper functions may need porting for your libc.


Thanks for the reply.
When I try to build the libmudflap library separately for
(Renesas)sh-elf target after building the complete toolchain, it
automatically gets configured for i386-redhat-linux target.
Is it the case that libmudflap only supports i386 target and not  
others?


Do I need to port it for sh-elf target?



Perhaps, but you want to build it as part of your target libraries
using --enable-libmudflap. When you build it after you're not using
host and target and therefore it's being built for your machine (i386- 
redhat-linux).


-eric

RE: How to enable Mudflap in gcc 4.x?

[Deepen Mantri]

Eric Christopher wrote:

>Perhaps, but you want to build it as part of your target libraries
>using --enable-libmudflap. When you build it after you're not using
>host and target and therefore it's being built for your machine (i386- 
>redhat-linux).

Thanks for the reply.
I did remove --enable-libmudflap option from the build script and
followed following steps for libmudflap configuration:

I created a separate build folder and from there

a) [libmudflap source path]/configure --target=sh-elf --prefix=[My 
   prefix folder path]
b) make
c) make install

By this, libmudflap.a got created but for i386-redhat-linux target.


Regards,
Deepen Mantri

KPIT Cummins InfoSystems Ltd.
Pune, India

~
Free download of GNU based tool-chains for Renesas' SH, H8, R8C, M16C 
and M32C Series. The following site also offers free technical support 
to its users. Visit http://www.kpitgnutools.com for details.
Latest versions of KPIT GNU tools were released on February 6, 07
~

question about switch table

[ligang]

Hi,

Now, i wanna generate a switch table just like ARM tbb instruction.
The switch table should be located at .rdata section, so I should use 
.L3-.L8_1, but not .L3-.L8.
How could i implement this? Any target macro can do it?

Please look at the following code fragment. (.L3-.L8_1)/2 is what i want, 
but not .L3-.L8.

  la  r7, $L8
  tbb [r7, r6]
  .L8_1
  .rdata
  .L8:
  .byte (.L3-.L8)/2 
  .byte (.L4-.L8)/2
  .byte (.L5-.L8)/2
  .byte (.L6-.L8)/2
  .byte (.L7-.L8)/2
  .text

Best regards
 Ligang

Re: How to enable Mudflap in gcc 4.x?

[Eric Christopher]

Thanks for the reply.
I did remove --enable-libmudflap option from the build script and
followed following steps for libmudflap configuration:



Why on earth would you do this?


I created a separate build folder and from there

a) [libmudflap source path]/configure --target=sh-elf --prefix=[My
  prefix folder path]
b) make
c) make install

By this, libmudflap.a got created but for i386-redhat-linux target.


No, at the toplevel (just like your normal build of the compiler and  
target libraries):


configure --enable-languages=c --disable-multilib --enable-libmudflap  
--target=sh-elf ; make -j8 all-gcc all-target


and you'll get this:

configure: error: none of the known symbol names works
make: *** [configure-target-libmudflap] Error 1

which means that libmudflap needs to be ported to sh-elf.

-eric

Re: [OT] Re: Git repository with full GCC history

[David Woodhouse]

On Sun, 2007-06-03 at 19:57 -0700, Harvey Harrison wrote:
> If I can reproduce it I'll see if I can find some webspace.

If you mail me a SSH public key you can also put it on
git.infradead.org.

-- 
dwmw2

Re: [OT] Re: Git repository with full GCC history

[Bernardo Innocenti]

David Woodhouse wrote:

On Sun, 2007-06-03 at 19:57 -0700, Harvey Harrison wrote:

If I can reproduce it I'll see if I can find some webspace.


If you mail me a SSH public key you can also put it on
git.infradead.org.


Come visit git.infradead.org and its GCC development fork.

--
  // Bernardo Innocenti
\X/  http://www.codewiz.org/

Re: Help in understanding ccp propagator

[Revital1 Eres]

> > I will greatly appreciate any suggestions regarding the following
> > problem I have with the ccp propagator. I am testing the new store
> > ccp patch which propagates constants by walking the virtual use-def
> > chain (http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00055.html) and I
> > encountered the following problem while testing tree_join.cc file which
> > is under libstdc++-v3 testsuite:
>
>
> BTW, a lot of these will be caught with the new VN i posted, whicih
> should be reviewed and go in soon.

Thanks, should it handle cases like the one in the following example -
http://gcc.gnu.org/ml/gcc-patches/2007-03/txt00081.txt?  I tried it with
the VN patch but it seems to not caught it...

> > The final propagator replaces the right operand (D.65705_98) in the
> > following if condition with a constant zero which causes the program to
be
> > aborted as i0_62 is not always zero:
> >
> >   # i0_62 = PHI 
> > :;
> >   D.61410.first = i0_62;
> > ...
> >D.65705_98 = D.61410.first;
> > -  if (D.65704_96 >= 0)
> > +  if (D.65704_96 >= D.65705_98)
> >  goto ;
> >else
> >  goto ;
> >
> > Tracing the execution of the propagator it seems that the if statement
> > is first been propogated with zero after simulating the execution; but
not
> > updated after the lattice value of the variables it depends on changed.
>
> Does your store CPP properly say the vdefs have changed when a
> statement's lattice value changes?

I am not sure I understand.  The new patch uses the infrastructure of
the propagator and I do not see an indication in the dumps for vdefs
update after the lattice value is changed:

19930
19931 Visiting statement:
19932 D.61410.first = i0_62;
19933
19934 Lattice value changed to CONSTANT 0.  Adding SSA edges to worklist.
19935

Thanks again fo your help,
Revital

RE: How to enable Mudflap in gcc 4.x?

[Deepen Mantri]

Eric Christopher wrote:

>No, at the toplevel (just like your normal build of the compiler and  
>target libraries):
>configure --enable-languages=c --disable-multilib --enable-libmudflap  
>--target=sh-elf ; make -j8 all-gcc all-target

>and you'll get this:
>configure: error: none of the known symbol names works
>make: *** [configure-target-libmudflap] Error 1

>which means that libmudflap needs to be ported to sh-elf.

How should I start the porting? Do you have any document related to such
porting? I would really appreciate your help if you could guide me in
this. 

Re: How to enable Mudflap in gcc 4.x?

[Frank Ch. Eigler]

Hi -

> >which means that libmudflap needs to be ported to sh-elf.
> 
> How should I start the porting? Do you have any document related to such
> porting? [...]

First thing is to get past that autoconf error.  Check your linker
script for the default entry point symbol's name, and give it to
libmudflap/configure.ac (then regenerate configure).

Next, overcome build problems (if any) to the extent that a
libmudflap.a gets compiled.

Then, start running the test suite.  It does not cover all the libc
function wrappers, so at this point you might as well start compiling
your own smaller code with -fmudflap and see what happens.

It may be reassuring that it is not sh-elf per se that needs porting,
but rather your runtime C library.  There is little to no
architecture-specific code in there.

- FChE

current gcc trunk testsuite failure on cygwin: Assembler messages: Warning: end of file in string; '"' inserted: Warning: .stabs: missing comma

[Christian Joensson]

phew, a few of the cygwin failures show up like this:

Executing on host: /usr/local/src/trunk/objdir/gcc/xgcc
-B/usr/local/src/trunk/objdir/gcc/   -O3 -g  -w -fno-show-column -c
-o 20001226-1.o
/usr/local/src/trunk/gcc/gcc/testsuite/gcc.c-torture/compile/20001226-1.c
  (timeout = 300)
spawn /usr/local/src/trunk/objdir/gcc/xgcc
-B/usr/local/src/trunk/objdir/gcc/ -O3 -g -w -fno-show-column -c -o
20001226-1.o 
/usr/local/src/trunk/gcc/gcc/testsuite/gcc.c-torture/compile/20001226-1.c
/cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cc2eakcj.s: Assembler messages:
/cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cc2eakcj.s:0: Warning: end of
file in string; '"' inserted
/cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cc2eakcj.s:18: Warning: .stabs:
missing comma
output is:
/cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cc2eakcj.s: Assembler messages:
/cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cc2eakcj.s:0: Warning: end of
file in string; '"' inserted
/cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cc2eakcj.s:18: Warning: .stabs:
missing comma

FAIL: gcc.c-torture/compile/20001226-1.c (test for excess errors)
Excess errors:
/cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cc2eakcj.s:0: Warning: end of
file in string; '"' inserted
/cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cc2eakcj.s:18: Warning: .stabs:
missing comma

and

Executing on host: /usr/local/src/trunk/objdir/gcc/xgcc
-B/usr/local/src/trunk/objdir/gcc/   -O3 -g  -w -fno-show-column -c
-o limits-declparen.o
/usr/local/src/trunk/gcc/gcc/testsuite/gcc.c-torture/compile/limits-declparen.c
  (timeout = 300)
spawn /usr/local/src/trunk/objdir/gcc/xgcc
-B/usr/local/src/trunk/objdir/gcc/ -O3 -g -w -fno-show-column -c -o
limits-declparen.o
/usr/local/src/trunk/gcc/gcc/testsuite/gcc.c-torture/compile/limits-declparen.c
/cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cckgb6Xp.s: Assembler messages:
/cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cckgb6Xp.s:0: Warning: end of
file in string; '"' inserted
/cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cckgb6Xp.s:18: Warning: .stabs:
missing comma
output is:
/cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cckgb6Xp.s: Assembler messages:
/cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cckgb6Xp.s:0: Warning: end of
file in string; '"' inserted
/cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cckgb6Xp.s:18: Warning: .stabs:
missing comma

FAIL: gcc.c-torture/compile/limits-declparen.c (test for excess errors)
Excess errors:
/cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cckgb6Xp.s:0: Warning: end of
file in string; '"' inserted
/cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cckgb6Xp.s:18: Warning: .stabs:
missing comma

and

Executing on host: /usr/local/src/trunk/objdir/gcc/xgcc
-B/usr/local/src/trunk/objdir/gcc/   -O3 -g  -w -fno-show-column -c
-o limits-exprparen.o
/usr/local/src/trunk/gcc/gcc/testsuite/gcc.c-torture/compile/limits-exprparen.c
  (timeout = 300)
spawn /usr/local/src/trunk/objdir/gcc/xgcc
-B/usr/local/src/trunk/objdir/gcc/ -O3 -g -w -fno-show-column -c -o
limits-exprparen.o
/usr/local/src/trunk/gcc/gcc/testsuite/gcc.c-torture/compile/limits-exprparen.c
/cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/ccxSOljv.s: Assembler messages:
/cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/ccxSOljv.s:0: Warning: end of
file in string; '"' inserted
/cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/ccxSOljv.s:18: Warning: .stabs:
missing comma
output is:
/cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/ccxSOljv.s: Assembler messages:
/cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/ccxSOljv.s:0: Warning: end of
file in string; '"' inserted
/cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/ccxSOljv.s:18: Warning: .stabs:
missing comma

FAIL: gcc.c-torture/compile/limits-exprparen.c (test for excess errors)
Excess errors:
/cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/ccxSOljv.s:0: Warning: end of
file in string; '"' inserted
/cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/ccxSOljv.s:18: Warning: .stabs:
missing comma

and

Executing on host: /usr/local/src/trunk/objdir/gcc/xgcc
-B/usr/local/src/trunk/objdir/gcc/   -O3 -g  -w -fno-show-column -c
-o limits-pointer.o
/usr/local/src/trunk/gcc/gcc/testsuite/gcc.c-torture/compile/limits-pointer.c
  (timeout = 300)
spawn /usr/local/src/trunk/objdir/gcc/xgcc
-B/usr/local/src/trunk/objdir/gcc/ -O3 -g -w -fno-show-column -c -o
limits-pointer.o
/usr/local/src/trunk/gcc/gcc/testsuite/gcc.c-torture/compile/limits-pointer.c
/cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/ccuaOzHS.s: Assembler messages:
/cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/ccuaOzHS.s:0: Warning: end of
file in string; '"' inserted
/cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/ccuaOzHS.s:18: Warning: .stabs:
missing comma
output is:
/cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/ccuaOzHS.s: Assembler messages:
/cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/ccuaOzHS.s:0: Warning: end of
file in string; '"' inserted
/cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/ccuaOzHS.s:18: Warning: .stabs:
missing comma

FAIL: gcc.c-torture/compile/limits-pointer.c (test for excess errors)
Excess errors:
/cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/ccuaOzHS.s:0: Warning: end of
file in string; '"' inserted
/cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/ccuaOzHS.s:18: Warning: .stabs:
mi

Re: [OT] Re: Git repository with full GCC history

[Jan-Benedict Glaw]

On Mon, 2007-06-04 05:17:17 -0400, Bernardo Innocenti <[EMAIL PROTECTED]> wrote:
> David Woodhouse wrote:
> > On Sun, 2007-06-03 at 19:57 -0700, Harvey Harrison wrote:
> > > If I can reproduce it I'll see if I can find some webspace.
> >
> > If you mail me a SSH public key you can also put it on
> > git.infradead.org.
> 
> Come visit git.infradead.org and its GCC development fork.

*cough* No reason to fork.  At least I'm just too used to GIT these
days and like it quite a lot, that's why I work on getting the
toolchain repos converted (and kept up-to-date!) somewhere as GIT
repos.

This just eases the pain keeping those patches up-to-date in some
branches, that aren't yet ready for merging.

MfG, JBG

-- 
  Jan-Benedict Glaw  [EMAIL PROTECTED]  +49-172-7608481
 Signature of:  http://perl.plover.com/Questions.html
 the second  :


signature.asc
Description: Digital signature

Re: What is purpose of numbered variables??

[Diego Novillo]

On 6/1/07 3:45 PM, Seema S. Ravandale wrote:

> int b; //local variable
> 
> array[b] = c
> 
> will be translated to
> b.0 = b;
> array[b.0] = c
> 
> anything to do with SSA?

Is 'b' an addressable variable or is it a regular local stack variable?
If the latter, then this is a buglet in the conversion to GIMPLE form.
We should probably check whether the array index is already a gimple
register before creating b.0.

It's not a big issue, though.  Copy propagation should get rid of that
very early on, but I agree that it would be worth fixing.

Re: Help in understanding ccp propagator

[Daniel Berlin]

On 6/4/07, Revital1 Eres <[EMAIL PROTECTED]> wrote:

> > I will greatly appreciate any suggestions regarding the following
> > problem I have with the ccp propagator. I am testing the new store
> > ccp patch which propagates constants by walking the virtual use-def
> > chain (http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00055.html) and I
> > encountered the following problem while testing tree_join.cc file which
> > is under libstdc++-v3 testsuite:
>
>
> BTW, a lot of these will be caught with the new VN i posted, whicih
> should be reviewed and go in soon.

Thanks, should it handle cases like the one in the following example -
http://gcc.gnu.org/ml/gcc-patches/2007-03/txt00081.txt?  I tried it with
the VN patch but it seems to not caught it...


I can modify it to catch it pretty easily, just walk back a few vuses
if the current set of vuses is defined by something that does not
actually touch our offset.
s?


I am not sure I understand.  The new patch uses the infrastructure of
the propagator and I do not see an indication in the dumps for vdefs
update after the lattice value is changed:

19930
19931 Visiting statement:
19932 D.61410.first = i0_62;
19933
19934 Lattice value changed to CONSTANT 0.  Adding SSA edges to worklist.
19935

Thanks again fo your help,
Revital


So uh, how do you expect the propagator to notice when the used
variables have changed if the things the vdefs produced by
D.61410.first are not marked as change (so that the immediate uses of
it get processed).

You will need to add this if it is not there already.


Normally, the propagator says "oh, the lattice value of D_64 changed,
let me mark all it's immediate uses for reprocessing". The only thing
that links memory defs to memory uses is the vdef/vuses, so you will
have to be able to process and mark those

testsuite trigraphs.c failure due to cygwin

[Timothy C Prince]

-Original Message-
From: "Timothy C Prince" <[EMAIL PROTECTED]>
To: gcc@gcc.gnu.org
Date: Mon, 04 Jun 2007 16:20:34 +

In the message
http://gcc.gnu.org/ml/gcc/2007-03/msg01088.html

Dave Korn wrote:

  So, am I correct to believe that we need to use plain 'inline' for c99 after 
gcc 4.4, and 'extern inline' before that?  That is, I think I need to write a 
test that looks like...


#if ((__GNUC__ > 4) || ((__GNUC__ == 4) && (__GNUC_MINOR__ >= 4))) \
&& defined (__STRICT_ANSI__) && (__STRICT_ANSI__ != 0) \
&& defined (__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L)
#define ELIDABLE_INLINE inline
#else
#define ELIDABLE_INLINE extern inline
#endif


  I'm not quite sure if I've got that right, though.  I don't know if I need to 
test __STRICT_ANSI__ or not.  I'm not sure if I should be testing for gnu99 
mode as well as std99 or not.  I want to match the exact conditions that are 
going to be tested to invoke the new standard behaviour; is this going to do it?
___
In gcc-4.3-20070601, a new problem came up. gcc.dg/cpp/trigraphs.c fails due to 
problems here in cygwin/newlib , even with the change suggested above.


Tim Prince


Tim Prince

Re: When was decimal floating point added to gcc?

[Janis Johnson]

On Sun, Jun 03, 2007 at 02:41:57PM +0200, Gerald Pfeifer wrote:
> On Sun, 3 Jun 2007, Ben Elliston wrote:
> >> Are they mentioned in any gcc changes.html?
> > No, they're not.  They probably should be.
> 
> Do you think we could talk the submitters/maintainers into donating a 
> patch? :-)

Support for the decimal floating point C extension could be mentioned
in the release notes for GCC 4.2, but there it's only supported for
powerpc*-linux and x86*-linux and only if requested at configure time.
The ABI for powerpc*-linux has changed since then, and the
representation will (has?) changed for x86*-linux.  Is this worth
documenting for 4.2?

Janis

Re: When was decimal floating point added to gcc?

[H. J. Lu]

On Mon, Jun 04, 2007 at 01:23:16PM -0700, Janis Johnson wrote:
> On Sun, Jun 03, 2007 at 02:41:57PM +0200, Gerald Pfeifer wrote:
> > On Sun, 3 Jun 2007, Ben Elliston wrote:
> > >> Are they mentioned in any gcc changes.html?
> > > No, they're not.  They probably should be.
> > 
> > Do you think we could talk the submitters/maintainers into donating a 
> > patch? :-)
> 
> Support for the decimal floating point C extension could be mentioned
> in the release notes for GCC 4.2, but there it's only supported for
> powerpc*-linux and x86*-linux and only if requested at configure time.
> The ABI for powerpc*-linux has changed since then, and the
> representation will (has?) changed for x86*-linux.  Is this worth
> documenting for 4.2?

DFP doesn't really work for x86*-linux unitl Uros fixed a bunch
of back-end/middle-end bugs in 4.3.


H.J.

gcc-4.1-20070604 is now available

[gccadmin]

Snapshot gcc-4.1-20070604 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070604/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch 
revision 125321

You'll find:

gcc-4.1-20070604.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.1-20070604.tar.bz2 C front end and core compiler

gcc-ada-4.1-20070604.tar.bz2  Ada front end and runtime

gcc-fortran-4.1-20070604.tar.bz2  Fortran front end and runtime

gcc-g++-4.1-20070604.tar.bz2  C++ front end and runtime

gcc-java-4.1-20070604.tar.bz2 Java front end and runtime

gcc-objc-4.1-20070604.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.1-20070604.tar.bz2The GCC testsuite

Diffs from 4.1-20070528 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.1
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: testsuite trigraphs.c failure due to cygwin

[Ian Lance Taylor]

"Timothy C Prince" <[EMAIL PROTECTED]> writes:

>   So, am I correct to believe that we need to use plain 'inline' for c99 
> after gcc 4.4, and 'extern inline' before that?  That is, I think I need to 
> write a test that looks like...
> 
> 
> #if ((__GNUC__ > 4) || ((__GNUC__ == 4) && (__GNUC_MINOR__ >= 4))) \
> && defined (__STRICT_ANSI__) && (__STRICT_ANSI__ != 0) \
> && defined (__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L)
> #define ELIDABLE_INLINE inline
> #else
> #define ELIDABLE_INLINE extern inline
> #endif

No, you shouldn't use anything along those lines.  You should check
for __GNUC_GNU_INLINE__ and __GNUC_STDC_INLINE__ as described in the
documentation.

In fact I mentioned this in my reply to the message you quote above:
http://gcc.gnu.org/ml/gcc/2007-03/msg01093.html

Ian

RE: Fixed-point branch?

[Fu, Chao-Ying]

> -Original Message-
> From: Mark Mitchell [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 31, 2007 9:05 AM
> To: Joseph S. Myers
> Cc: Fu, Chao-Ying; Richard Henderson; GCC
> Subject: Re: Fixed-point branch?
> 
> 
> Joseph S. Myers wrote:
> 
> > I haven't examined it.  When the branch maintainers 
> consider it ready to 
> > merge I hope a proposal along the lines of the DFP one 
> >  will be 
> posted (see also 
> > subsequent discussion in that thread, and on the submitted patches).
> 
> I would like to avoid the situation in which Chao-Ying et. 
> al. work hard
> to come up with a plan, factor the patches, etc., and then we decide
> that the code is not going to be ready for 4.3.  I had 
> originally pushed
> this work back to 4.4, but as 4.3's been delayed, perhaps there's an
> opportunity for it in 4.3.  If, however, the work isn't 
> ready, then I'd
> rather not take up a lot of Chao-Ying's time now; instead, we can just
> wait for 4.4 to get closer.
> 
> At the same time, of course, there's not much point in you 
> investing in
> looking at the branch if Chao-Ying doesn't think it's ready.
> 
> So, let's do this:
> 
> 1. Chao-Ying, would you please work on any remaining issues that you
> feel need resolution.  Then, post your merge plan, ala DFP.

  Yes.  We will work on remaining issues and post our merge plan.

> 
> 2. Joseph, at that point, would you please invest a a little 
> bit of time
> (a couple of hours) to look at the branch, and provide some feedback?
> Please provide comments to Chao-Ying, and also please let me know
> whether you think the work is nearly ready for inclusion?

  Maybe you could first check if new machine modes, new TREE structures
(a saturating bit, fixed-point type, fixed-point constant), 
new RTL structures (fixed-point constant and operators) are ok.

  Thanks a lot!

Regards,
Chao-ying

Re: current gcc trunk testsuite failure on cygwin: Assembler messages: Warning: end of file in string; '"' inserted: Warning: .stabs: missing comma

[Tim Prince]

[EMAIL PROTECTED] wrote:

phew, a few of the cygwin failures show up like this:

Executing on host: /usr/local/src/trunk/objdir/gcc/xgcc
-B/usr/local/src/trunk/objdir/gcc/   -O3 -g  -w -fno-show-column -c
-o 20001226-1.o
/usr/local/src/trunk/gcc/gcc/testsuite/gcc.c-torture/compile/20001226-1.c
  (timeout = 300)
spawn /usr/local/src/trunk/objdir/gcc/xgcc
-B/usr/local/src/trunk/objdir/gcc/ -O3 -g -w -fno-show-column -c -o
20001226-1.o 
/usr/local/src/trunk/gcc/gcc/testsuite/gcc.c-torture/compile/20001226-1.c

/cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cc2eakcj.s: Assembler messages:
/cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cc2eakcj.s:0: Warning: end of
file in string; '"' inserted
/cygdrive/c/DOCUME~1/chj/LOCALS~1/Temp/cc2eakcj.s:18: Warning: .stabs:
missing comma




Windows XP Pro/SP2 cygwin 
cygwin   1.5.24-2   (with D Korn's stdio.h patch to newlib)


trigraphs.c also failed for me for the first time, objecting to the 
patched version of stdio.h.

Re: [OT] Re: Git repository with full GCC history

[Bernardo Innocenti]

Jan-Benedict Glaw wrote:


Come visit git.infradead.org and its GCC development fork.


*cough* No reason to fork.  At least I'm just too used to GIT these
days and like it quite a lot, that's why I work on getting the
toolchain repos converted (and kept up-to-date!) somewhere as GIT
repos.


Err... Of course I was just joking.



This just eases the pain keeping those patches up-to-date in some
branches, that aren't yet ready for merging.


Indeed, but if we moved the git repository to gcc.gnu.org it
could also be used for pushing patches to the centralized
GCC repository.

For everyday development, I'd very much prefer using Git than
Subversion.

--
  // Bernardo Innocenti
\X/  http://www.codewiz.org/

Re: Comments for empty for-loop parts (was Re: xserver: Branch 'master' - 6 commits)

[Bernardo Innocenti]

Ian Romanick wrote:


Over the years, I have encountered *may* bugs like this.  One way to
help combat them is to have a policy that empty loop parts are
documented with a comment of /* empty */.  It makes it explicit to
people reading the code that the missing parts are intentionally
missing.  It also helps prevent deletion of the "stray" semicolon of an
empty loop body.


Some compilers have an option to warn on empty loop
and "if" bodies.  To shut it up, you can replace the
";" with an empty block instead: "{ }", which also
shows the intention more clearly to humans.

Surprisingly, gcc does not seem to support this
warning as of 4.1.

--
  // Bernardo Innocenti
\X/  http://www.codewiz.org/

libjava is a train wreck.

[Steve Kargl]

Can someone explain why libjava *must* commit binary files to the
repository?  A merge of trunk to the fortran-experiments branch
generated 70 conflicts that I need to resolve.  This is a complete
waste of time that would have been spent towards cutting a diff
of the branch against trunk for patch submission!

-- 
Steve