Re: gcc for syntax check only (C): need to read source from stdin

[Bernardo Innocenti]

Zack Weinberg wrote:
> "Dave Korn" <[EMAIL PROTECTED]> writes:
> 
> 
>>  No write perms mate!  However I'll check out HEAD and do a
>>before-and-after testsuite run overnight, and get back to you in the morning
>>with the results (UK time).  Will "--enable-languages=c,c++" be enough, or
>>do you want me to test against all default languages?
> 
> 
> For this, c/c++ should be fine.

Are you serious?  Such a dangerous patch surely ought
to be fully regtested with all languages enabled and
*at* *least* using:

 - a cc0 target
 - a big-endian target
 - a 64bit target
 - the mmix and vax backends
 - the new-ra branch
 - the POOMA testsuite

:-)


--- gcc.c.orig  2005-04-12 18:05:46.803428200 +0100
+++ gcc.c   2005-04-12 18:06:28.230338800 +0100
@@ -954,7 +954,7 @@ static const struct compiler default_com
cc1 %(cpp_unique_options) %(cc1_options)}}\
 %{!fsyntax-only:%(invoke_as)}}", 0, 1, 1},
   {"-",
-   "%{!E:%e-E required when input is from standard input}\
+   "%{!E:%e-E or -x required when input is from standard input}\
 %(trad_capable_cpp) %(cpp_options) %(cpp_debug_options)", 0, 0, 0},
   {".h", "@c-header", 0, 0, 0},
   {"@c-header",

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: GCC 4.0 RC2

[Bernardo Innocenti]

Joel Sherrill <[EMAIL PROTECTED]> wrote:
> I know I asked late in the process but this fix for a m68k/coldfire 
> failure just showed up:
> 
> [Bug target/18421] ICE in reload_cse_simplify_operands, at postreload.c:391
> 
> Any chance at it getting considered?

This patch was approved by Roger Sayle here:

  http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01519.html


However, when I tested a slightly modified version
of it (*) on m68k-linux, it seemed to cause a few
new regressions:

  http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02681.html

I still had no time to look into it.  Would you like
me to post diffs of the .sum and .log files?


(*) patch here: http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01480.html

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: Patches for coldfire v4e

[arcjai]

Hi,

> >   Attached are the patches for coldfire v4e. These
> > changes are originally contributed by Peter
> Barada. I
> > have migrated and tested these changes from gcc
> 3.04
> > to gcc 3.4 and now to mainline. 
> 
> Thank you for submitting this patch.  I've not yet
> had the time to perform a full review.  Maybe I'll
> be able to do some testing over the week-end.
> 
> I noticed a few things:
> 
>  - In many places code is mis-indented or has
>minor white-space glitches;

I will recheck all the formating issues and submit the
patches. 

 
>  - You don't seem to consistently patch both
> MOTOROLA
>and !MOTOROLA paths.  Is this intentional? 
> AFAIK,
>there are no ColdFire targets using the MIT
> syntax,
>but we need to be consistent;

I think it is only for the new patterns that these
paths are not followed. Do you want me to change them
as well?
 
>  - The patch isn't yet updated to the .opt
> conversion
>that occurred on mainline a few days ago. 
> Changing
>it should be trivial;

I will do that.  

> >   Since coldfire v4e has MMU we need to support
> > m68k-linux target for coldfire v4e. To support
> > m68k-linux for coldfire v4e I need to modify
> t-linux.
> > But I suppose this is not desirable. In that case
> we
> > might have to create another target, maybe
> > coldfire-linux. Please give your
> comments/suggestions
> > on this. Is it ok to modify t-linux or
> coldfire-linux
> > should be created.
> 
> What are the changes you need to apply?

> Would plain 68020 code run on v4e processor?  As far
> as I can see, m68k-linux isn't a multilib target.

Problem occurs mainly due to restricted addressing
modes in v4e. For ex v4e supports only 16-bit
displacements. So all crt* files needs to be build for
v4e. Also v4e does not have extended floating point
instructions (XF mode) so we may have to modify t-*
for fpgnulib.c. 


> -- 
>   // Bernardo Innocenti - Develer S.r.l., R&D dept.
> \X/  http://www.develer.com/
> 
> 

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Patches for coldfire v4e

[Bernardo Innocenti]

[EMAIL PROTECTED] wrote:

>> - You don't seem to consistently patch both
>>MOTOROLA and !MOTOROLA paths.
>> Is this intentional?   AFAIK, there are no
>> ColdFire targets using the MIT syntax,
>> but we need to be consistent;
> 
> I think it is only for the new patterns that these
> paths are not followed. Do you want me to change them
> as well?

Since it noticeably increases the complexity of the
m68k backend, I personally believe the MIT syntax
should go away as soon as m68k-openbsd moves on to
a version of GAS released in this decade.

However, letting MOTOROLA and MIT code diverge makes
it hard to understand what the code is supposed to
do, so we should keep them in sync as much as
possible.


>>What are the changes you need to apply?
>>
>>Would plain 68020 code run on v4e processor?  As far
>>as I can see, m68k-linux isn't a multilib target.
> 
> 
> Problem occurs mainly due to restricted addressing
> modes in v4e. For ex v4e supports only 16-bit
> displacements. So all crt* files needs to be build for
> v4e. Also v4e does not have extended floating point
> instructions (XF mode) so we may have to modify t-*
> for fpgnulib.c. 

So it seems adding coldfire-linux is the only way
to address this...

I'm afraid you'll also have to patch binutils, gdb,
newlib and libstdc++ to get "coldfire-" to mean the
same of "m68k-".

Before you go on, you'll need to submit a new target
tuple to the config project:

  http://savannah.gnu.org/projects/config/

Once it's done, let me know and I'll import the new
version in GCC.

I'm sorry it can't be made simpler than this.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Help me about C language Specification

[thanh tuan]

  Hello,
I am a student, and I am studying to build an ANSI C compiler into
ASM. The things I need now are the ANSI C specification ( or something
about  the state machine, automata to do lexeme and syntax...)
Please tell me where I can get this. Thank you very much!

Best regards!

-- 
Come as you are

Re: Help me about C language Specification

[Jonathan Wakely]

On Wed, Apr 13, 2005 at 03:30:31PM +0700, thanh tuan wrote:

>   Hello,
> I am a student, and I am studying to build an ANSI C compiler into
> ASM. The things I need now are the ANSI C specification ( or something
> about  the state machine, automata to do lexeme and syntax...)
> Please tell me where I can get this. Thank you very much!

Hi,

you can buy a PDF online from ANSI's web store 
or you can buy a book published in the UK by Wiley, ISBN 0470845732.
There might be other ways to buy it from your national standards body.

regards,

jon

Re: GCC 4.0 RC1 Available

[Andrew Haley]

Per Bothner writes:
 > Per Bothner wrote:
 > > However, the Kawa testsuite fails, raising a ClassNotFoundException.
 > > I'm looking into it.
 > 
 > Hm.  This fails, with or without the patch:
 >clas = Class.forName(cname);
 > This works:
 >clas = Class.forName(cname, true, getClass().getClassLoader());

Okay, a stack trace failure.  And a new one, despite the fact that the
release branch still has the unchanged old stack trace machinery.

 > This is with make all && make install in the libjav directory.
 > I'm doing a 'cvs update' and rebuild from a clean tree in case the
 > problem is an artifact of the way I just rebuilt part of the tree.
 > 
 > BTW, I've always though we should have the compiler rewrite:
 >Class.forName(NAME)
 > to:
 >Class.forName(NAME, true, getClass().getClassLoader())
 > to avoid the fragility and ugliness and performance lossage
 > of doing the stack trace ...

I started to do this, but there are quite a few places that need it:
it's not just Class.forName().

Andrew.

GCC Cross Compilation

[Vishal Kothari]

Hi,

Can someone tell me how do I use GCC to build for ARM target?

-- 
Regards,
Vishal Kothari.

Re: GCC 4.0 RC2

[Jason Merrill]

On Tue, 12 Apr 2005 10:59:42 -0700, Mark Mitchell <[EMAIL PROTECTED]> wrote:

> Sadly, it's become clear there's going to have to be a second release
> candidate.  In particular, there are some wrong-code bugs that are popping
> up on real packages on primary platforms.  Jason Merill is looking into
> some of the C++ issues, but he's in Lillehammer this week for the ISO
> meeting.

Actually, I'm not.  I don't think these are C++ front end bugs, though they
are showing up with C++ packages.  I'd take a look if there were a
manageable testcase for me to look at, but I don't have time to learn my
way around KDE and openoffice in order to find the bugs.

I think other people are working on tracking these down, though.

The relevant PRs seem to be 20949 and 20973; there's also some (off-topic)
discussion in 19317.

Jason

Re: GCC 4.0 RC1 Available

[Andrew Pinski]

On Apr 13, 2005, at 1:41 AM, Ranjit Mathew wrote:
Exception in thread "main" java.lang.RuntimeException: test failed:5
<>
FAIL: Array_3 -O3 execution - bytecode->native test
This one is expected I think, though not XFAILed (it
fails only at -O3).
BTW, you keep getting "<>"
everywhere - is addr2line from binutils not present
somewhere in your default executable search path?
On darwin, addr2line does not exist, yes I know this
is weird but binutils is not ported really to mach-o.
If anyone wants to do it, go for it.
-- Pinski

Re: GCC 4.0 RC2

[Jakub Jelinek]

On Tue, Apr 12, 2005 at 10:59:42AM -0700, Mark Mitchell wrote:
> I don't have a date for RC2 yet; that will depend in part on when Jason 
> is able to fix the C++ issues.  However, I would certainly hope that we 
> could get it done shortly.

FYI, I have bootstrapped/regtested 4.0 RC1 with:

> Here are the patches approved thus far for RC2:
> 
> * http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01036.html
> 
>   GLIBC does not compile on S390.
> 
> * http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01015.html
> 
>   Fortran fix.
> 
> * http://gcc.gnu.org/ml/java-patches/2005-q2/msg00088.html
> 
>   Java library patch.

Plus from the patches still in consideration for 4.0 also:

http://gcc.gnu.org/ml/gcc-patches/2005-04/msg00321.html

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20929

http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01421.html

on {i386,x86_64,ia64,ppc,ppc64,s390,s390x}-linux, no regressions.

Jakub

RE: gcc for syntax check only (C): need to read source from stdin

[Dave Korn]

Original Message
>From: Bernardo Innocenti
>Sent: 13 April 2005 08:05

> Zack Weinberg wrote:
>> "Dave Korn" writes:
>> 
>> 
>>>  No write perms mate!  However I'll check out HEAD and do a
>>> before-and-after testsuite run overnight, and get back to you in the
>>> morning with the results (UK time).  Will "--enable-languages=c,c++" be
>>> enough, or do you want me to test against all default languages?
>> 
>> 
>> For this, c/c++ should be fine.
> 
> Are you serious?  Such a dangerous patch surely ought
> to be fully regtested with all languages enabled and
> *at* *least* using:
> 
>  - a cc0 target
>  - a big-endian target
>  - a 64bit target
>  - the mmix and vax backends
>  - the new-ra branch
>  - the POOMA testsuite
> 
> :-)


  Oh yes, indeed!  I'm also testing with both Fortrans, Cobol, Java, and
Ada, and liasing with the gcl and LLVM folks, to make sure it doesn't break
their stuff, and I heard about a bloke in Outer Mongolia who has a custom
port of gcc to a gnu-yurt-yak-abacus target, and I'm quite worried about
breaking his backend... (those Yaks can give you one hell of a kick!)


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Haifa scheduler question: the purpose of move_insn??

[Steven Bosscher]

Hi,

We have this charming move_insn function in haifa-sched.c:

/* Move INSN.  Reemit notes if needed.

   Return the last insn emitted by the scheduler, which is the
   return value from the first call to reemit_notes.  */

static rtx
move_insn (rtx insn, rtx last)
{
  rtx retval = NULL;

  move_insn1 (insn, last);

  /* If this is the first call to reemit_notes, then record
 its return value.  */
  if (retval == NULL_RTX)
retval = reemit_notes (insn, insn);
  else
reemit_notes (insn, insn);

  SCHED_GROUP_P (insn) = 0;

  return retval;
}


First of all, move_insn1 should really be replaced with reorder_insns,
but OK, whatever, this code is older.

But what is this weird thing move_insn is doing with retval?  It is
pretty obvious that retval is NULL_RTX in "if (retval == NULL_RTX)",
so I wonder what the purpose was of this code.  Archeology hasn't
helped me much.  retval was introduced in revision 1.8 by Jeff:

1.1   law   6501: 
6502: static rtx
6503: move_insn (insn, last)
6504:  rtx insn, last;
6505: {
1.8  |law   6506:   rtx retval = NULL;
1.1   law   6507: 
1.8  |law   6508:   /* If INSN has SCHED_GROUP_P set, then issue it 
and any other
 |  6509:  insns with SCHED_GROUP_P set first.  */
1.1   law   6510:   while (SCHED_GROUP_P (insn))
6511: {
6512:   rtx prev = PREV_INSN (insn);
1.8  |law   6513: 
 |  6514:   /* Move a SCHED_GROUP_P insn.  */
1.1   law   6515:   move_insn1 (insn, last);
1.8  |law   6516:   /* If this is the first call to 
reemit_notes, then record
 |  6517: its return value.  */
 |  6518:   if (retval == NULL_RTX)
 |  6519:retval = reemit_notes (insn, insn);
 |  6520:   else
 |  6521:reemit_notes (insn, insn);
1.1   law   6522:   insn = prev;
6523: }
6524: 
1.8  |law   6525:   /* Now move the first non SCHED_GROUP_P insn.  
*/
1.1   law   6526:   move_insn1 (insn, last);
1.8  |law   6527: 
 |  6528:   /* If this is the first call to reemit_notes, 
then record
 |  6529:  its return value.  */
 |  6530:   if (retval == NULL_RTX)
 |  6531: retval = reemit_notes (insn, insn);
 |  6532:   else
 |  6533: reemit_notes (insn, insn);
 |  6534: 
 |  6535:   return retval;
1.1   law   6536: }


But in revision 1.215, the itanium-sched-branch was merged and the
function was simplified to:

law   1765: 
1766: static rtx
1767: move_insn (insn, last)
1768:  rtx insn, last;
1769: {
1.8   law   1770:   rtx retval = NULL;
1.1   law   1771: 
1.8   law   1772:   /* Now move the first non SCHED_GROUP_P insn.  
*/
1.1   law   1773:   move_insn1 (insn, last);
1.8   law   1774: 
1775:   /* If this is the first call to reemit_notes, 
then record
1776:  its return value.  */
1777:   if (retval == NULL_RTX)
1778: retval = reemit_notes (insn, insn);
1779:   else
1780: reemit_notes (insn, insn);
1781: 
1.215|vmakarov  1782:   SCHED_GROUP_P (insn) = 0;
 |  1783: 
1.8   law   1784:   return retval;
1.1   law   1785: }


The only ChangeLog entry I can find for this change is:

* sched-rgn.c (init_ready_list, can_schedule_ready_p,
add_branch_dependences): Ignore schedule groups.

* sched-ebb.c (init_ready_list): Ditto.

* (move_insn, set_priorities): Ditto.

Vlad, can you explain this change?  Can I safely clean up this function,
or should we still avoid calling reemit_notes more than once for each
insn???

Gr.
Steven

exceptions with longjmp (perhaps i am too stupid)

[Georg Steffers]

Hi,
i am working on a lib that should implement OO methods in C. I tried to  
build up an exception system using longjmp and ran into a problem. I am  
searching for an answer a month now and am actually not bit farther  
than at the beginning. Actually i am not sure if it is an issue with  
gcc or i did not understand correctly how longjmp should work. Perhaps  
anyone here can help.

The problem is that if i make two longjmp, the second returning to the  
function that issued the first, than my stack seems to be corrupted (or  
something similar) I made a more or less simple example that did not  
use any other part of my the OO lib nor did any dynamic memory stuff,  
just a few functions that demonstates the problem.

Output I expected from the program:
---
In try block
In catch block (1 | TESTMESSAGE)
resume--->
und wieder im try block
output I got:
-
In try block
In catch block (1 | TESTMESSAGE)
resume--->
compiler: gcc 3.3.4
code:
-
#include 
#include 
#include 
#define MAXESTACK100
#define MAXEENV  100
#define FALSE0
#define TRUE 1
enum Bool_t {false=FALSE, true};
struct exception {
  int errNum;
  char* errMsg;
  jmp_buf resume;
};
struct excenv {
  jmp_buf excJmp;
  struct exception excStack[MAXESTACK];
  int excStackInd;
  enum Bool_t inCatch;
};
static struct excenv excEnv[MAXEENV];
static int excEnvInd = -1;
void NewExcEnv(void) {
  excEnv[++excEnvInd].excStackInd = -1;
  excEnv[excEnvInd].inCatch = false;
}
#define TRY \
  NewExcEnv(); \
  if(setjmp(excEnv[excEnvInd].excJmp) == 0) {
struct exception* CatchExc(void) {
  struct excenv* ee = &excEnv[excEnvInd];
  ee->inCatch = true;
  return (ee->excStackInd>=0)?&ee->excStack[(ee->excStackInd)--]:0;
}
#define CATCH(e) }\
  else while(e=CatchExc()) {
void DelExcEnv(void) {
  excEnvInd--;
}
#define ENDTRY excEnv[excEnvInd].inCatch = false; }\
  DelExcEnv();
void ThrowExc(int en, const char* const em) {
  struct excenv* ee;
  int eei = excEnv[excEnvInd].inCatch?excEnvInd-1:excEnvInd;
  struct exception* e;
  assert(eei >= 0);
  ee = &excEnv[eei];
  e = &(ee->excStack[++(ee->excStackInd)]);
  e->errNum = en;
  e->errMsg = (char*)calloc(strlen(em)+1, sizeof(char));
  strcpy(e->errMsg, em);
  if(setjmp(e->resume) == 0)
 longjmp(ee->excJmp, 1);
  else
 puts("resume--->");
  return;
}
#define THROW(en, em) ThrowExc(en, em);
void resumeAfterExc(void) {
}
#define RESUME(e) excEnv[excEnvInd].inCatch = false; \
  longjmp(e->resume, 1);
#define FORWARD
int main(void) {
  struct exception* e;
  NewExcEnv();
  if(setjmp (excEnv[excEnvInd].excJmp) == 0) {
 puts("In try block");
 ThrowExc(1, "TESTMESSAGE");
 puts("und wieder im try block");
  } else
 while(e=CatchExc()) {
printf("In catch block (%d | %s)\n", e->errNum, e->errMsg);
excEnv[excEnvInd].inCatch = false;
longjmp(e->resume, 1);
excEnv[excEnvInd].inCatch = false;
 }
  DelExcEnv();
/*   TRY
 puts("In try block");
 THROW(1, "TESTMESSAGE")
 puts("und wieder im try block");
  CATCH(e)
 printf("In catch block (%d | %s)\n", e->errNum, e->errMsg);
 RESUME(e)
  ENDTRY*/
  return 0;
}


pgplRm1V4EdpH.pgp
Description: PGP signature

Re: exceptions with longjmp (perhaps i am too stupid)

[Andrew Haley]

Georg Steffers writes:
 > Hi,
 > 
 > i am working on a lib that should implement OO methods in C. I tried to  
 > build up an exception system using longjmp and ran into a problem. I am  
 > searching for an answer a month now and am actually not bit farther  
 > than at the beginning. Actually i am not sure if it is an issue with  
 > gcc or i did not understand correctly how longjmp should work. Perhaps  
 > anyone here can help.
 > 
 > The problem is that if i make two longjmp, the second returning to the  
 > function that issued the first, than my stack seems to be corrupted (or  
 > something similar) I made a more or less simple example that did not  
 > use any other part of my the OO lib nor did any dynamic memory stuff,  
 > just a few functions that demonstates the problem.

See ISO C, Section 7.13.2,1 Para 2 on Page 244, particularly footnote
210.

Redirected to gcc-help.

Andrew.

Re: GCC 4.0 RC1 Available

[Andrew Haley]

Andrew Haley writes:
 > Eric Botcazou writes:
 >  > > which I see you've already committed a patch for, and a large number
 >  > > of Java failures.
 >  > >
 >  > > 
 >  > >
 >  > > for 4.0.0-20050410.
 >  > 
 >  > Same failure as on Solaris.
 >  > 
 >  > Andrew, do you have a Darwin machine at hand?
 > 
 > Surprisingly enough, yes.  But I'm having trouble finding a compiler
 > binary for it.

It's now building.  I don't have a very fast Darwin box, so it
probably won't get fixed today.

Andrew.

Re: Haifa scheduler question: the purpose of move_insn??

[Vladimir N. Makarov]

Steven Bosscher wrote:
Hi,
We have this charming move_insn function in haifa-sched.c:
/* Move INSN.  Reemit notes if needed.
  Return the last insn emitted by the scheduler, which is the
  return value from the first call to reemit_notes.  */
static rtx
move_insn (rtx insn, rtx last)
{
 rtx retval = NULL;
 move_insn1 (insn, last);
 /* If this is the first call to reemit_notes, then record
its return value.  */
 if (retval == NULL_RTX)
   retval = reemit_notes (insn, insn);
 else
   reemit_notes (insn, insn);
 SCHED_GROUP_P (insn) = 0;
 return retval;
}
First of all, move_insn1 should really be replaced with reorder_insns,
but OK, whatever, this code is older.
But what is this weird thing move_insn is doing with retval?  It is
pretty obvious that retval is NULL_RTX in "if (retval == NULL_RTX)",
so I wonder what the purpose was of this code.  Archeology hasn't
helped me much.  retval was introduced in revision 1.8 by Jeff:
1.1   law   6501: 
   6502: static rtx
   6503: move_insn (insn, last)
   6504:  rtx insn, last;
   6505: {
1.8  |law   6506:   rtx retval = NULL;
1.1   law   6507: 
1.8  |law   6508:   /* If INSN has SCHED_GROUP_P set, then issue it and any other
|  6509:  insns with SCHED_GROUP_P set first.  */
1.1   law   6510:   while (SCHED_GROUP_P (insn))
   6511: {
   6512:   rtx prev = PREV_INSN (insn);
1.8  |law   6513: 
|  6514:   /* Move a SCHED_GROUP_P insn.  */
1.1   law   6515:   move_insn1 (insn, last);
1.8  |law   6516:   /* If this is the first call to reemit_notes, then record
|  6517: its return value.  */
|  6518:   if (retval == NULL_RTX)
|  6519:retval = reemit_notes (insn, insn);
|  6520:   else
|  6521:reemit_notes (insn, insn);
1.1   law   6522:   insn = prev;
   6523: }
   6524: 
1.8  |law   6525:   /* Now move the first non SCHED_GROUP_P insn.  */
1.1   law   6526:   move_insn1 (insn, last);
1.8  |law   6527: 
|  6528:   /* If this is the first call to reemit_notes, then record
|  6529:  its return value.  */
|  6530:   if (retval == NULL_RTX)
|  6531: retval = reemit_notes (insn, insn);
|  6532:   else
|  6533: reemit_notes (insn, insn);
|  6534: 
|  6535:   return retval;
1.1   law   6536: }

But in revision 1.215, the itanium-sched-branch was merged and the
function was simplified to:
   law   1765: 
   1766: static rtx
   1767: move_insn (insn, last)
   1768:  rtx insn, last;
   1769: {
1.8   law   1770:   rtx retval = NULL;
1.1   law   1771: 
1.8   law   1772:   /* Now move the first non SCHED_GROUP_P insn.  */
1.1   law   1773:   move_insn1 (insn, last);
1.8   law   1774: 
   1775:   /* If this is the first call to reemit_notes, then record
   1776:  its return value.  */
   1777:   if (retval == NULL_RTX)
   1778: retval = reemit_notes (insn, insn);
   1779:   else
   1780: reemit_notes (insn, insn);
   1781: 
1.215|vmakarov  1782:   SCHED_GROUP_P (insn) = 0;
|  1783: 
1.8   law   1784:   return retval;
1.1   law   1785: }

The only ChangeLog entry I can find for this change is:
   * sched-rgn.c (init_ready_list, can_schedule_ready_p,
   add_branch_dependences): Ignore schedule groups.
   * sched-ebb.c (init_ready_list): Ditto.
   * (move_insn, set_priorities): Ditto.
Vlad, can you explain this change?  Can I safely clean up this function,
or should we still avoid calling reemit_notes more than once for each
insn???
 

Early move_insn function emitted several insns (belonging to a sched 
group).  The sched group was considered as one insn.  Now move_insn can 
issue only one insn and the sched group is considered as several insns 
making dfa state more accurate then before.  SCHED_GROUP is used only 
for issue insns in the group in right order without intermixing with 
insns out of the sched group.

You can safely cleanup this function.  The dead else branch is garbage 
and consequence of not full clean up the function after making it moving 
only one insn.  Sorry, my fault.

The cleanup could be even more for move_insn an

Re: GCC 4.0 RC1 Available

[Andrew Haley]

My Darwin build of 4.0 failed in libstdc++:

ibsupc++convenience.a -lm -lm   -lc  -Wl,-single_module -Wl,-flat_namespace 
-install_name  /Users/aph/gcc/install/lib/libstdc++.6.dylib 
-compatibility_version 7 -current_version 7.4
ld: .libs/mt_allocator.o malformed object, illegal reference for -dynamic code 
(reference to a coalesced section (__TEXT,__textcoal_nt) from section 
(__TEXT,__eh_frame) relocation entry (4))
ld: .libs/mt_allocator.o malformed object, illegal reference for -dynamic code 
(reference to a coalesced section (__TEXT,__textcoal_nt) from section 
(__TEXT,__eh_frame) relocation entry (8))
ld: .libs/mt_allocator.o malformed object, illegal reference for -dynamic code 
(reference to a coalesced section (__TEXT,__textcoal_nt) from section 
(__TEXT,__eh_frame) relocation entry (12))

This is with a fresh download of Xcode.

Andrew.

Re: GCC 4.0 RC2

[Ian Lance Taylor]

Richard Sandiford <[EMAIL PROTECTED]> writes:

> Ian Lance Taylor  writes:
> > Richard Sandiford <[EMAIL PROTECTED]> writes:
> >> Huh.  For the record: it can't.  get_attr_length() returns 0
> >> for ADDR_VECs regardless of JUMP_IN_TEXT_SECTION.  I'll update
> >> the comment when applying the bug-fix patch to mainline.
> >
> > shorten_branches handles JUMP_TABLES_IN_TEXT_SECTION correctly.  You
> > don't need ADJUST_INSN_LENGTHS unless you need to call get_attr_length
> > somewhere else.
> 
> The code I mentioned isn't related to ADJUST_INSN_LENGTHS.
> It's a subroutine of the mips16 constant layout code.
> 
> As far as shorten_branches() goes: I realise that it handles text jump
> tables correctly, but the mips16 layout code runs in reorg, before
> shorten_branches() has been called.
> 
> I suppose we could call shorten_branches() from the mips16 layout
> code, but I don't like the idea of relying on the cached results of
> shorten_branches() in a pass that is specifically supposed to
> _increase_ the distance between things.

Sorry, I did misunderstand.  I thought that bit of code was
implementing ADJUST_INSN_LENGTH.

I think this is a good reason to move the length calculation out of
shorten_branches and into get_attr_length.  Except one would have to
be careful with CASE_VECTOR_SHORTEN_MODE.

Ian

Re: Haifa scheduler question: the purpose of move_insn??

[Steven Bosscher]

On Wednesday 13 April 2005 15:21, Vladimir N. Makarov wrote:
> The cleanup could be even more for move_insn and reemit_notes because
> now they return always insn.

Actually, move_insn always returns NULL_RTX.  Probably the
function should be something like,

static rtx
move_insn (rtx insn, rtx last)
{
  reorder_insns (insn, insn, last);
  SCHED_GROUP_P (insn) = 0;
  return reemit_notes (insn, insn);
}

I'll give it a look.

Gr.
Steven

Re: GCC 4.0 RC1 Available

[Andrew Haley]

Andrew Haley writes:
 > My Darwin build of 4.0 failed in libstdc++:
 > 
 > ibsupc++convenience.a -lm -lm   -lc  -Wl,-single_module -Wl,-flat_namespace 
 > -install_name  /Users/aph/gcc/install/lib/libstdc++.6.dylib 
 > -compatibility_version 7 -current_version 7.4
 > ld: .libs/mt_allocator.o malformed object, illegal reference for -dynamic 
 > code (reference to a coalesced section (__TEXT,__textcoal_nt) from section 
 > (__TEXT,__eh_frame) relocation entry (4))
 > ld: .libs/mt_allocator.o malformed object, illegal reference for -dynamic 
 > code (reference to a coalesced section (__TEXT,__textcoal_nt) from section 
 > (__TEXT,__eh_frame) relocation entry (8))
 > ld: .libs/mt_allocator.o malformed object, illegal reference for -dynamic 
 > code (reference to a coalesced section (__TEXT,__textcoal_nt) from section 
 > (__TEXT,__eh_frame) relocation entry (12))
 > 
 > This is with a fresh download of Xcode.

which didn't contain cctools-528.5.  Continuing.

Andrew.

-finstrument-functions and C++ exceptions

[Chris Kirby]

We are trying to use -finstrument-functions to do some custom profiling on x86 
and ppc.  

For normal code execution, it works fine, calling our entry and exit methods as 
expected.

Unfortunately, we are running into problems related to exceptions.  If we exit 
a function because of an exception, no exit method is called.  This greatly 
diminishes the usefulness of the instrumentation since we are no longer 
guaranteed to get matching entry and exit calls.

It seems to me that if function instrumentation is enabled, then the compiler 
should guarantee that exit (or perhaps a exit_throw?) is called, even if the 
function is exited because of an exception.

I can see where the current instrumentation is added in gcc/function.c.  Is 
there some easy way to add some cleanup code that guarantees exit will be 
called?  Are there any documents on how RTL works?

Another possible place I see to hook it in is unwind.inc, but that does not 
have access to the current function tree, so we can't tell if instrumentation 
is enabled or not.

Thank you,

- Chris Kirby

Re: -finstrument-functions and C++ exceptions

[Andrew Pinski]

On Apr 13, 2005, at 10:06 AM, Chris Kirby wrote:
We are trying to use -finstrument-functions to do some custom 
profiling on x86 and ppc.

For normal code execution, it works fine, calling our entry and exit 
methods as expected.

Unfortunately, we are running into problems related to exceptions.  If 
we exit a function because of an exception, no exit method is called.  
This greatly diminishes the usefulness of the instrumentation since we 
are no longer guaranteed to get matching entry and exit calls.
It works the way you want to for the 4.0 release.
-- Pinski

Re: Basic block reordering algorithm

[Steven Bosscher]

On Wednesday 13 April 2005 00:18, Pat Haugen wrote:
> When we have a test block gating whether a loop should be
> entered, the new block frequency check causes the code to pick the non-loop
> path as the next block to add to the trace since the loop header block has
> a higher frequency, and hence the loop gets moved out of line.

Have you tried with the patch to re-enable the loop header copying
predictor: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02577.html?
It sounds like you might want to try that first...

Gr.
Steven

Re: GCC Cross Compilation

[E. Weddington]

Vishal Kothari wrote:
Hi,
Can someone tell me how do I use GCC to build for ARM target?
 

See Dan Kegel's crosstool:

And questions regarding building cross-toolchains are better off posted 
on the crossgcc list:


Eric

Re: Patches for coldfire v4e

[Daniel Jacobowitz]

On Wed, Apr 13, 2005 at 10:10:39AM +0200, Bernardo Innocenti wrote:
> >>What are the changes you need to apply?
> >>
> >>Would plain 68020 code run on v4e processor?  As far
> >>as I can see, m68k-linux isn't a multilib target.
> > 
> > 
> > Problem occurs mainly due to restricted addressing
> > modes in v4e. For ex v4e supports only 16-bit
> > displacements. So all crt* files needs to be build for
> > v4e. Also v4e does not have extended floating point
> > instructions (XF mode) so we may have to modify t-*
> > for fpgnulib.c. 
> 
> So it seems adding coldfire-linux is the only way
> to address this...

Why?  Adding support (if it isn't already there) for something like
--with-arch=coldfire should work just as well.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: -finstrument-functions and C++ exceptions

[Chris Kirby]

At 10:08 AM 4/13/2005 -0400, Andrew Pinski wrote:

>On Apr 13, 2005, at 10:06 AM, Chris Kirby wrote:
>
>>We are trying to use -finstrument-functions to do some custom profiling on 
>>x86 and ppc.
>>
>>For normal code execution, it works fine, calling our entry and exit methods 
>>as expected.
>>
>>Unfortunately, we are running into problems related to exceptions.  If we 
>>exit a function because of an exception, no exit method is called.  
>>This greatly diminishes the usefulness of the instrumentation since we are no 
>>longer guaranteed to get matching entry and exit calls.
>
>It works the way you want to for the 4.0 release.

Unfortunately our next release will be using gcc 3.4.2.

Looking at the 4.0 code, I can see that the exit instrumentation is done by 
wrapping a try finally around the entire function.  Backporting this to 3.4.2 
isn't as straightforward as I hoped.  I think something similar could be done 
in tree-optimize.c's tree_rest_of_compilation() but it looks like some of the 
tree/RTL methods have changed in 4.0.

Are there any examples of wrapping a method with a try finally clause and 
calling a given method compatible with 3.4.2?

- Chris

FW: GNU Mailing Lists Question #1

[Chris Miller]

Hi.  I'm hoping you can help me with the questions in this e-mail and the
one that follows.  I'd sent each originally to [EMAIL PROTECTED], thinking
that that person would be the best one to answer questions about GNU mailing
lists, but James Blair responded by recommending that I look at the site
(which I already have) or contact you.

Thanks,

Chris Miller
LynuxWorks Tech Pubs

-Original Message-
From:   Chris Miller [mailto:[EMAIL PROTECTED]
Sent:   Tuesday, April 12, 2005 5:08 PM
To: [EMAIL PROTECTED]
Cc: Cmiller (E-mail)
Subject:GNU Mailing Lists Question #1

Hi.
I'm working on a LynuxWorks doc about GNU CC that was published in 8/00.
The actual GNU CC that it documents isn't being updated, but, as I found
earlier this year when I exchanged e-mail with Ian Lance Taylor and Paolo
Carlini, some of its information about contacting the GNU organization has
become out of date.  Specifically, Ian and Carlo both told me that all bugs
should be reported through the bugzilla database
(http://gcc.gnu.org/bugzilla/).
I'm sending this e-mail to you because our existing doc also says: "Both the
bug-gcc and bug-g++ mailing lists have newsgroups which serve as repeaters:
gnu.gcc.bug and gnu.g++.bug."  These mailing lists aren't listed in the list
of GNU mailing lists on your site (http://lists.gnu.org/mailman/listinfo/),
although you do have one list called "Bug-gplusplus."
* For the "bug-g++" reference, should I correct our reference to replace
"bug-g++" with "Bug-gplusplus"  or something else?  Would the reference at
the end of the sentence then change from "gnu.g++.bug" to
"gnu.gplusplus.bug" or something else?
* For the "bug-gcc" reference, should I correct our reference to name a
different mailing list?  Would the reference at the end of the sentence then
change from "gnu.gcc.bug" to something else?
* Also concerning "bug-gcc," another part of our existing doc tells the user
to "send suggested fixes to the bug report mailing list:
[EMAIL PROTECTED]"  Is there somewhere else I should tell the user to
send suggested fixes, or is there another method now for providing info
about suggested fixes to you?

Thanks for your help,
Chris Miller

FW: [gnu.org #232014] GNU Mailing Lists Question #1

[Chris Miller]

Hi.  I just sent you two e-mails in which I said James Blair recommended that I 
do so.  I'm forwarding this response to you to clarify that the recommendation 
came to me from someone who was "acting on behalf" of James Blair.

Thanks,

Chris Miller
LynuxWorks Tech Pubs

-Original Message-
From: www-data [mailto:[EMAIL PROTECTED] Behalf Of James Blair via RT
Sent: Wednesday, April 13, 2005 8:27 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [gnu.org #232014] GNU Mailing Lists Question #1 

Most gcc information can be found at http://gcc.gnu.org/>.  You may
be able to find the answers to most of your questions there.  Otherwise,
I suggest you contact [EMAIL PROTECTED] or [EMAIL PROTECTED] for further 
information.

FW: GNU Mailing Lists Question #2

[Chris Miller]

Hi.  Here's the second e-mail my previous message referred to.  As that
e-mail explained, I'd sent my questions originally to [EMAIL PROTECTED],
thinking that that person would be the best one to answer questions about
GNU mailing lists, but James Blair responded by recommending that I look at
the site (which I already have) or contact you.

Thanks,

Chris Miller
LynuxWorks Tech Pubs

-Original Message-
From:   Chris Miller [mailto:[EMAIL PROTECTED]
Sent:   Tuesday, April 12, 2005 5:09 PM
To: [EMAIL PROTECTED]
Cc: Cmiller (E-mail)
Subject:GNU Mailing Lists Question #2

Hi.
I'm working on a LynuxWorks doc about GNU CC that was published in 8/00 and
just sent you a question about updating info our doc supplies about GNU
mailing lists.
Our existing doc also tells the user that if he or she needs help installing
to "send a message to a suitable network mailing list. First try
[EMAIL PROTECTED] If that brings no response, try
[EMAIL PROTECTED]"  Neither of these mailing lists is listed in the
list of GNU mailing lists on your site
(http://lists.gnu.org/mailman/listinfo/).
My previsou e-mail already asked about the "bug-gcc."  For "help-gcc," is
there a  newer mailing list name?
Is there another preferred method now for obtaining help related to
installation?
Thanks for your help,
Chris Miller

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

[Andi Kleen]

> Thanks.  I was under the impression that 2.4 doesn't build with GCC
> HEAD, anyway - I saw some patches pile up and not get applied.

AFAIK some gcc 4.0 patches went in. I assume it will build eventually
at least once 4.0 is released.

> Does 2.6 still use the option?

No.

However the change needed for that is really too big to backport, so 
I would prefer not to.

-Andi

Re: Basic block reordering algorithm

[Pat Haugen]

Steven Bosscher <[EMAIL PROTECTED]> wrote on 04/13/2005 09:39:55 AM:

> On Wednesday 13 April 2005 00:18, Pat Haugen wrote:
> > When we have a test block gating whether a loop should be
> > entered, the new block frequency check causes the code to pick the
non-loop
> > path as the next block to add to the trace since the loop header block
has
> > a higher frequency, and hence the loop gets moved out of line.
>
> Have you tried with the patch to re-enable the loop header copying
> predictor: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02577.html?
> It sounds like you might want to try that first...

That does indeed fix the case when there is no profile data present. But if
we have real profile data which presents a 50/50 probability on the gating
block then we're back to the same situation of moving the loop out of line
(although I guess one can always come up with scenarios to cause heuristics
to look bad, which many times may not be worth worrying about).

Re: Basic block reordering algorithm

[Steven Bosscher]

On Wednesday 13 April 2005 20:46, Pat Haugen wrote:
> Steven Bosscher <[EMAIL PROTECTED]> wrote on 04/13/2005 09:39:55 AM:
> > On Wednesday 13 April 2005 00:18, Pat Haugen wrote:
> > > When we have a test block gating whether a loop should be
> > > entered, the new block frequency check causes the code to pick the
>
> non-loop
>
> > > path as the next block to add to the trace since the loop header block
>
> has
>
> > > a higher frequency, and hence the loop gets moved out of line.
> >
> > Have you tried with the patch to re-enable the loop header copying
> > predictor: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02577.html?
> > It sounds like you might want to try that first...
>
> That does indeed fix the case when there is no profile data present. But if
> we have real profile data which presents a 50/50 probability on the gating
> block then we're back to the same situation of moving the loop out of line
> (although I guess one can always come up with scenarios to cause heuristics
> to look bad, which many times may not be worth worrying about).

Well, if there is a 50/50 probability, does it matter if the
loop is moved out of line?  There is a 50/50 chance that you
will not enter the loop, so moving it inline hurts the other,
equally likely path.

The problem with your original proposal is that computing
post-dominance information really is expensive.  Depending
on how often this 50/50 case happens, in a real profile, it
may or may not be worth the cost do as you suggested.  My
guess is that it doesn't happen very often and it isn't worth
it.  Maybe it is, you'd have to try.

With some luck we will have the infrastructure in place RSN
to preserve loop information over passes (at the very least
as a "loop region"). When that stuff is available, we could
teach bb-reorder to use that information to solve your problem
properly (and fix the find_traces_1_round hack you noted).

Gr.
Steven

Re: [PATCH] Cleanup fold_rtx, 1/n

[Roger Sayle]

On Wed, 13 Apr 2005, Steven Bosscher wrote:
> My gcov attachment to PR19721 shows that the code does not
> trigger on amd64 either.

Hi Paolo and Steven,

I'm still reading through the patch, but I think the wider issue
of using profiling to determine which of GCC's transformations are
worthwhile and which are not deserves some broader discussion.

I admit that fold_rtx is perhaps a special case, as we're trying
to eliminate/reduce the significant amount of compile-time spent
in CSE.  More generally, I'm uncomfortable with using profile
techniques that determine whether a piece of code ever triggers
to decide whether it has benefit or not.  Such protocols are
inherently dependent upon the source code corpus being used.
In this case the comments in PR19271, suggest that you're using
571 source files from GCC's own cc1.

I suspect that in this entire "coverage suite", there isn't a
single "complex" or "vector" operation, and the total number of
floating point operations is severely under-represented compared
to SPECfp for example.  We know that cc1 doesn't link against
the host's libm, for example, so none of GCC's math builtins
would be triggered.

A slightly better approach would be to include the dejagnu
testsuite in the coverage analysis, as the preferred policy of
adding a new testcase to trigger each transformation/optimization
might help here.  Of course, this policy isn't rigorously enforced,
so I'd still be uncomfortable removing code based simply on the
fact that we couldn't get it to trigger.


Of course, there are no clear black-and-whites in such arguments
and everything is a compromise.  For example, even if well-written
pattern matching code should take little extra time if they never
match (e.g. unreachable cases in switch statements), the additional
code leads to larger/slower binaries and presents a maintenance
overhead.  Alternatively, code that never triggers can't cause
any bugs (but may bit-rot until it does trigger at some point in
the future).


My personal preference remains that these RTL optimizations should
be moved from fold_rtx to simplify_rtx when possible, and those that
depend upon the CSE'ing different functional forms are left.  For
example, one of the "???" comments in your patch recommends that that
transformation be moved to combine.c, which is probably as true today
as it was when it was first written.


Thoughts?  Opinions?


I'm not trying to be a road block on the path of progress, but I'd
just like to get a feel for where we intend to draw the line with
these protocols.  If taken to extremes, these policies can clearly
be dangerous (if none of these cc1 files contains K&R prototypes,
perhaps we could drop parser support for pre-ANSI C, etc...).

Roger
--
Roger Sayle, E-mail: [EMAIL PROTECTED]
OpenEye Scientific Software, WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road, Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507. Fax: (+1) 505-473-0833

Re: -finstrument-functions and C++ exceptions

[Andrew Pinski]

On Apr 13, 2005, at 12:18 PM, Chris Kirby wrote:
Are there any examples of wrapping a method with a try finally clause 
and calling a given method compatible with 3.4.2?
Not that I know of, and when I asked RTH about this when he wrote the 
4.0 code,
he said there is no way.

Anyways 4.0.0 has improved code generation for C++.
-- Pinski

Re: gcc for syntax check only (C): need to read source from stdin

[James E Wilson]

Dave Korn wrote:
[EMAIL PROTECTED] /gnu/testing/obj-HEAD> make check 2>&1 | tee check.log
Always use "make -k check".  Some testsuites exit with an error if one 
or more tests failed, and because this is the normal situation for 
almost all testsuites, this means the only way to get meaningful results 
is to use -k.

You will still get a failure for the fixincludes testsuite, but it will 
be ignored, and the other testsuites will work.

Or alternatively, run the ones you care about individually, e.g. "make 
check-target-libstdc++-v3" which will run only the libstdc++-v3 
testsuite.  Or alternatively, you can cd into the directories you care 
about, e.g. "cd gcc; make check-g++" which will run just the gcc C++ 
testsuite.  Etc.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: [PATCH] Cleanup fold_rtx, 1/n

[Steven Bosscher]

On Wednesday 13 April 2005 21:19, Roger Sayle wrote:
> A slightly better approach would be to include the dejagnu
> testsuite in the coverage analysis, as the preferred policy of
> adding a new testcase to trigger each transformation/optimization
> might help here.

We can do that kind of testing (I have merged coverage data for cse.c
from bootstraps on five different targets, and redoing that with the
test suite is just a matter of burning cycles), although I think you
are putting the bar quite high.  But that's only fair.

> Of course, this policy isn't rigorously enforced, 

This is not a problem someone willing to do the dirty cleanup work
can do anything about.  IMHO it is just unfair to make that a problem
now for people who have good arguments and sufficient evidence to show
that a piece of code is almost certainly dead.

If there is reason to believe some code is dead, and it does not or
almost not trigger in the test suite (on, say, three targets, to raise
the bar even further but still keep it doable?) then we should be able
to say that the code is really dead.

Otherwise we might as well stop right now and just not remove anything
in the RTL path.  Falsifying the assertion "this code is not dead" is
impossible ;-)

> I'd still be uncomfortable removing code based simply on the
> fact that we couldn't get it to trigger.

So you're saying there is no such thing as "enough evidence" for you
to feel comfortable about removing subsumed optimizations?

We're doomed :-)

Why is removing $random_hack so much harder than adding $random_hack?
Because it is there and has been there for such a long time?  That is
not a valid reason.  The code has to be there for a reason.  If nobody
knows or can show why the code is there, and it is safe to clean it up,
then by all means, let's clean it up!

> My personal preference remains that these RTL optimizations should
> be moved from fold_rtx to simplify_rtx when possible,

Of course.  I think Paolo did a pretty good job at that already.

> and those that 
> depend upon the CSE'ing different functional forms are left.  For
> example, one of the "???" comments in your patch recommends that that
> transformation be moved to combine.c, which is probably as true today
> as it was when it was first written.

That bit was added in revision 1.280 by you, when you yourself commited
a patch to catch this case by Paolo Bonzini!
So you are oposing the removal of code that he contributed himself ;-)
See http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cse.c?annotate=1.280
The case Paolo wanted to catch back then is now optimized in the tree
optimizers, so there should be no need to move it to combine.  

> Thoughts?  Opinions?

I think you're being too conservative.  Conservatism is a virtue for
a compiler writer, but you have to be realistic too: there is a reason
why we have a new optimization framework.  Parts of the RTL path _are_
just dead code now.  That was the whole point IIUC.

> I'm not trying to be a road block on the path of progress, but I'd
> just like to get a feel for where we intend to draw the line with
> these protocols.  If taken to extremes, these policies can clearly
> be dangerous (if none of these cc1 files contains K&R prototypes,
> perhaps we could drop parser support for pre-ANSI C, etc...).

That is something completely different.  It is not even in the same
category, you're comparing breaking standard conformance with removing
dead code.

Gr.
Steven

Re: Basic block reordering algorithm

[Pat Haugen]

Steven Bosscher <[EMAIL PROTECTED]> wrote on 04/13/2005 02:10:07 PM:

>
> The problem with your original proposal is that computing
> post-dominance information really is expensive.  Depending
> on how often this 50/50 case happens, in a real profile, it
> may or may not be worth the cost do as you suggested.  My
> guess is that it doesn't happen very often and it isn't worth
> it.  Maybe it is, you'd have to try.

My intuition was that the cost is probably not worth it, which was why I
asked first.

Back to the original problem with the algorithm using edge frequency vs.
block frequency.  Would you agree that the correct thing to do is fix the
code so that it uses block frequency, especially since the patch of
Zdenek's you referenced takes care of the original problem I saw when doing
so?

-Pat

Re: internal compiler error at dwarf2out.c:8362

[James E Wilson]

Martin Koegler wrote:
  tree type = TREE_TYPE (*node);
  tree attr = tree_cons (name, args, TYPE_ATTRIBUTES (type));
  tree newtype = build_type_attribute_variant (type, attr);
  TYPE_MAIN_VARIANT (newtype) = TYPE_MAIN_VARIANT (type);
  TREE_TYPE (*node) = newtype;
You shouldn't be trying to build your own types in a machine dependent 
attribute handler function.  The compiler's type system is determined by 
front-ends mainly, and some middle-end infrastructure, and isn't your 
domain to mess with.  This stuff is subject to change, at which point 
your code may break.

The sensible thing here would be to give an error message if an 
attribute is misused.

There are a number of subtleties in the type system relating to arrays, 
so it isn't surprising that you are having trouble with them.  For 
instance, you can't apply some kinds of type modifiers to array types, 
they have to be applied to the array element types instead.

I think the problem with your code is that you are setting 
TYPE_MAIN_VARIANT to point at the original type.  TYPE_MAIN_VARIANT is 
only supposed to be used in the presence of type qualifiers like const 
and volatile, to point at the unqualified type.  But you have no type 
qualifiers here, and hence TYPE_MAIN_VARIANT should point at itself.

See the gcc internals docs for TYPE_MAIN_VARIANT which specifically 
mentions type qualifiers.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Tree-ssa dead store elimination

[Pat Haugen]

Sorry if there is an obvious answer for this, but I'm not to familiar with
the tree-ssa phase.

My question is, why doesn't tree-ssa-dse.c do anything to the following
code?

int i,j,k,l;

void p1() {

i = 1;  /* Dead store */
j = 2;
i = k;  /* Dead store after copy prop */
if (i == 1)
  l = 999;
i = 0;
junk();

}


Here's the t65.dse2 output:

p1 ()
{
  int i.1;
  int k.0;

:
  i = 1;
  j = 2;
  k.0_6 = k;
  i = k.0_6;
  if (k.0_6 == 1) goto ; else goto ;

:;
  l = 999;

:;
  i = 0;
  junk ();
  return;

}



The first store does finally get elminated by the rtl lifetime analysis but
the second store remains.

-Pat

Re: Tree-ssa dead store elimination

[Andrew Pinski]

On Apr 13, 2005, at 5:12 PM, Pat Haugen wrote:
Sorry if there is an obvious answer for this, but I'm not to familiar 
with
the tree-ssa phase.

My question is, why doesn't tree-ssa-dse.c do anything to the following
code?
Because it does not understand V_MUST_DEF, see PR 18880 for a patch and 
more
information on the problem.

-- Pinski

Re: FW: GNU Mailing Lists Question #1

[James E Wilson]

Chris Miller wrote:
Hi.  I'm hoping you can help me with the questions in this e-mail and the
one that follows. 
Bugs should be reported into bugzilla.  Period.  The old info is 
obsolete and should be ignored.  See
http://gcc.gnu.org/bugs.html

Mailing list info can be found here:
http://gcc.gnu.org/lists.html
The old info is obsolete and should be ignored.
We aren't interested in bug reports against gcc releases older than 
gcc-3.3.  Any such bugs will be closed without further comment if the 
problem is already fixed in current releases.

We are especially not interested in bug reports against proprietary gcc 
releases, where proprietary means any release not made by the FSF.  If 
you have made any modifications to the gcc sources you are releasing, 
then we don't want the bug reports.  Any such bugs will be closed with a 
comment telling the reporter to contact the vendor that produced their 
gcc release.  See the tenth bullet at
http://gcc.gnu.org/bugs.html#dontwant

If you are making a proprietary release, there are a few things you 
should do to the gcc sources.  I don't think we have a documented list 
of them, but I think there are only two main ones:
a) Change the version number to indicate where it came from, e.g. 
something like "gcc 2.95 (lnxw)" instead of just "gcc 2.95".  Try "gcc 
-v" on most any linux system for comparison.
b) Change the message printed when an internal error is detected. 
Instead of mentioning the gcc.gnu.org address, it should point at an 
address inside lnxw.com.  Where this message exists depends on the gcc 
version you have, which you didn't mention.  Look at GCCBUGURL in 
system.h in gcc-2.95, look at bug_report_url in version.c in current 
releases.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: GCC 4.0 RC1 Available

[Paul Jarc]

gcc/doc/install.texi still mentions gcc 3.5 in a few places.


paul

Re: GCC 4.0 RC1 Available

[Andrew Haley]

Ranjit Mathew writes:
 > Geoffrey Keating wrote:
 > [...]
 > > which I see you've already committed a patch for, and a large number
 > > of Java failures.
 > > 
 > > You can see full test results at
 > [...]
 > > 
 > > 
 > > 
 > > for 4.0.0-20050410.
 > 
 > It might be helpful to put your "libjava.log" somewhere
 > or if all the Java failures seem similar, to post
 > the error messages around the "FAIL" lines from your
 > libjava.log.

My results:

FAIL: Array_3 -O3 execution - bytecode->native test
FAIL: LargeFile execution - source compiled test
FAIL: LargeFile execution - bytecode->native test
FAIL: LargeFile -O3 execution - source compiled test
FAIL: LargeFile -O3 execution - bytecode->native test

=== libjava Summary ===

# of expected passes3062
# of unexpected failures5
# of expected failures  14
# of untested testcases 23

Array_3 is extected to fail at -O3.  LargeFile fails if it can't
create a huge file.

powerpc-apple-darwin7.8.0
dejagnu HEAD

So, this is unrepro, as far as I can see.

Andrew.

Re: Basic block reordering algorithm

[Steven Bosscher]

On Wednesday 13 April 2005 22:52, Pat Haugen wrote:
> Back to the original problem with the algorithm using edge frequency vs.
> block frequency.  Would you agree that the correct thing to do is fix the
> code so that it uses block frequency, especially since the patch of
> Zdenek's you referenced takes care of the original problem I saw when doing
> so?

My understanding of what you propose is that you want to use the dest
block frequency as the tie-breaker in the case that both edges have
the same probability.  Right?  I think this would be reasonable.  Not
my decision to make, though ;-)

Gr.
Steven

P.S.  I wonder why the code for the best edge in tracer.c:better_p is
not the same as the code in bb-reorder -- or why we have two trace
finding algorithms in one compiler...  Honza?? 

Re: 2 suggestions

[Gerald Pfeifer]

On Thu, 7 Apr 2005, Kaveh R. Ghazi wrote:
>>> Not necessary.  If people would simply follow the directions here:
>>>  by setting
> Also, when I click on the link above, it doesn't follow down the page
> to the anchor.  I'm not sure why that is.  Gerald?

Just a few days ago I learned that this is a "feature" in current
versions of texinfo: apparently XHTML disallows characters like "*"
at the beginning of an anchor, so makeinfo now prepends some magic
string.

I'm afraid we'll have to rename all of these in some way, either
by replacing "*" by "x" or by prepending some string.  I'm not too
fond of either, but just using "x" instead "*" might be less ugly.
Somewhat.

What do you think?

Gerald

gcc-3.3-20050413 is now available

[gccadmin]

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

This snapshot has been generated from the GCC 3.3 CVS branch
with the following options: -rgcc-ss-3_3-20050413 

You'll find:

gcc-3.3-20050413.tar.bz2  Complete GCC (includes all of below)

gcc-core-3.3-20050413.tar.bz2 C front end and core compiler

gcc-ada-3.3-20050413.tar.bz2  Ada front end and runtime

gcc-g++-3.3-20050413.tar.bz2  C++ front end and runtime

gcc-g77-3.3-20050413.tar.bz2  Fortran 77 front end and runtime

gcc-java-3.3-20050413.tar.bz2 Java front end and runtime

gcc-objc-3.3-20050413.tar.bz2 Objective-C front end and runtime

gcc-testsuite-3.3-20050413.tar.bz2The GCC testsuite

Diffs from 3.3-20050406 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-3.3
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: 2 suggestions

[Kaveh R. Ghazi]

 > I'm afraid we'll have to rename all of these in some way, either by
 > replacing "*" by "x" or by prepending some string.  I'm not too fond
 > of either, but just using "x" instead "*" might be less ugly.
 > Somewhat.
 > What do you think?
 > Gerald

I like prepending a string, for example target= or triplet=, etc.

--Kaveh
--
Kaveh R. Ghazi  [EMAIL PROTECTED]

Re: GCC 4.0 RC1 Available

[Tom Tromey]

Eric> Ugh.  Not very surprising, given that a jumbo patch landed by
Eric> that time:

Did this get resolved?

Eric> Tom, I presume there was a very good reason for installing such
Eric> a potentially destabilizing patch a few days before the
Eric> prerelease?  What amount of testing did it undergo before being
Eric> backported?

More than the usual; I ran the test suite on two architectures (x86
and ppc, the latter a multilib build), plus I tested it against
eclipse and jonas.

Tom

Re: 2 suggestions

[Georg Bauhaus]

Gerald Pfeifer wrote:
On Thu, 7 Apr 2005, Kaveh R. Ghazi wrote:
Not necessary.  If people would simply follow the directions here:
 by setting
Also, when I click on the link above, it doesn't follow down the page
to the anchor.  I'm not sure why that is.  Gerald?

Just a few days ago I learned that this is a "feature" in current
versions of texinfo: apparently XHTML disallows characters like "*"
at the beginning of an anchor, so makeinfo now prepends some magic
string.
If "*-*-solaris2*" should appear as/in the "name" attribute of an ,
prepending a name start character is not enough, because this attribute
is of type NMTOKEN. Therefore it cannot contain * at all.
If international character sets in XHTML are o.K., maybe there are
some letter sets to choose from. Here is a sample.

http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";>


No * in NMTOKEN


going to
bar
bar
bar
bar
gone to

bar-Ã
bar-Î
bar-Ï
bar-Ï


-- Georg

unreducable cp_tree_equal ICE in gcc-4.0.0-20050410

[Nick Rasmussen]

I'm running into an ICE in the prerelease, that is proving to be
very difficult in reducing to a small testcase.  If I preprocess
the source (via -E or -save-temps) the code successfully compiles.
 If I minimally change the source file in some ways(like adding a
static integer in the global scope) the code compiles.  I've been
able to delete some lines from the source file that's triggering
the bug, including some from within the function that is
triggering the ICE, but I'm down to a point where I can't easily
reduce it further, or even get it into a single source file.

Does this bug look familiar?  20629 is ICEing in the same spot, but
it looks like theirs was reproducible after preprocessing.  Is there
any more information that I provide that would be helpful?  I've
attached the command line, specs and a stacktrace from cc1plus.

-nick

/dept/rnd/vendor/gcc-4.0.0pre1-amd64/bin/g++ -fno-builtin -O2 -g -DHAVE_X86_64 
-DHAVE_LITTLE_ENDIAN -DHAVE_BYTESWAP_H -DHAVE_64BIT_POINTER -DHAVE_VA_COPY 
-DHAVE_XINERAMA -DPLATFORM_LINUX -D_FILE_OFFSET_BITS=64 -DHAVE_STL_LIMITS 
-DHAVE_IOS_BASE -Drestrict=__restrict__ -DPLATFORM_LINUX_AMD64 
-DPLATFORM=LINUX_AMD64 -DBUILD=LINUX_AMD64_GCC400pre1_OPT_DEBUG -DDISTRO_SUSE 
-DDISTRO=SUSE -DDISTRO_VERSION=91 -DNVIDIA_VERSION_6111 -DNVIDIA_VERSION=6111 
-DGCC_VERSION_400pre1 -DNDEBUG -I/usr/share/doc/NVIDIA_GLX-1.0/include -I. 
-I/dept/rnd/home/nick/work/build-zeno2/SUSE_AMD64_GCC400pre1_OPT_DEBUG/include 
-I/usr/X11R6/include -c bug.C -o /dev/null
bug.C: In member function 'void EzFleshMesh::buildNodeArrays()':
bug.C:411: internal compiler error: in cp_tree_equal, at cp/tree.c:1552
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

> /dept/rnd/vendor/gcc-4.0.0pre1-amd64/bin/g++ -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.0.0-20050410/configure --enable-languages=c,c++ 
--prefix=/dept/rnd/vendor/gcc-4.0.0-20050410-amd64 --enable-threads
Thread model: posix
gcc version 4.0.0 20050410 (prerelease)

#0  internal_error (msgid=0x847cb2 "in %s, at %s:%d") at 
../../gcc-4.0.0-20050410/gcc/diagnostic.c:496
#1  0x005640fc in fancy_abort (file=Variable "file" is not available.
) at ../../gcc-4.0.0-20050410/gcc/diagnostic.c:556
#2  0x00473171 in cp_tree_equal (t1=0x2a9a1c94b0, t2=0x2a9a1cbb90) at 
../../gcc-4.0.0-20050410/gcc/cp/tree.c:1552
#3  0x00473198 in cp_tree_equal (t1=0x2a9a013820, t2=0x2a9a031460) at 
../../gcc-4.0.0-20050410/gcc/cp/tree.c:1543
#4  0x004590b3 in comptypes (t1=0x2a9a00ea90, t2=0x2a9a02bdd0, 
strict=Variable "strict" is not available.
) at ../../gcc-4.0.0-20050410/gcc/cp/typeck.c:912
#5  0x00458ede in comptypes (t1=0x2a9a00ec30, t2=0x2a9a032000, 
strict=0) at ../../gcc-4.0.0-20050410/gcc/cp/typeck.c:1034
#6  0x0047b0b9 in cxx_types_compatible_p (x=0x2a9a00ec30, 
y=0x2a9a032000) at ../../gcc-4.0.0-20050410/gcc/cp/cp-objcp-common.c:173
#7  0x007776bd in expressions_equal_p (e1=0x2a9a1c9640, 
e2=0x2a9a1cbd20) at ../../gcc-4.0.0-20050410/gcc/tree-vn.c:127
#8  0x007776f7 in val_expr_pair_expr_eq (p1=0xc16b90, p2=0xcd25e0) at 
../../gcc-4.0.0-20050410/gcc/tree-vn.c:153
#9  0x007ffcba in htab_find_slot_with_hash (htab=0xca98a0, 
element=0x81c3b9, hash=8504885, insert=INSERT) at 
../../gcc-4.0.0-20050410/libiberty/hashtab.c:660
#10 0x0077794f in vn_add (expr=0x2a9a1cbd20, val=0x2a9a240330, 
vuses=0x0) at ../../gcc-4.0.0-20050410/gcc/tree-vn.c:199
#11 0x004e09c1 in execute_pre (do_fre=0 '\0') at 
../../gcc-4.0.0-20050410/gcc/tree-ssa-pre.c:1742
#12 0x004c0802 in execute_pass_list (pass=0xa10b80) at 
../../gcc-4.0.0-20050410/gcc/tree-optimize.c:533
#13 0x004c0825 in execute_pass_list (pass=0xa10700) at 
../../gcc-4.0.0-20050410/gcc/tree-optimize.c:571
#14 0x004c0a66 in tree_rest_of_compilation (fndecl=0x847cb2) at 
../../gcc-4.0.0-20050410/gcc/tree-optimize.c:668
#15 0x0046e690 in expand_body (fn=0x2a99e450d0) at 
../../gcc-4.0.0-20050410/gcc/cp/semantics.c:2981
#16 0x0076ce74 in cgraph_expand_function (node=0x2a9a032a90) at 
../../gcc-4.0.0-20050410/gcc/cgraphunit.c:835
#17 0x0076d0fa in cgraph_optimize () at 
../../gcc-4.0.0-20050410/gcc/cgraphunit.c:1706
#18 0x00441a15 in cp_finish_file () at 
../../gcc-4.0.0-20050410/gcc/cp/decl2.c:3053
#19 0x004a4f4a in c_common_parse_file (set_yydebug=Variable 
"set_yydebug" is not available.
) at ../../gcc-4.0.0-20050410/gcc/c-opts.c:1099
#20 0x0072fcc8 in toplev_main (argc=Variable "argc" is not available.
) at ../../gcc-4.0.0-20050410/gcc/toplev.c:998
#21 0x002a95688e5d in __libc_start_main () from /lib64/tls/libc.so.6
#22 0x0040258a in _start () at ../sysdeps/x86_64/elf/start.S:96

Re: Help me about C language Specification

[Mike Stump]

On Apr 13, 2005, at 1:30 AM, thanh tuan wrote:
I am a student, and I am studying to build an ANSI C compiler into
ASM.
I know, you can download gcc and then do configure && make CFLAGS=- 
save-temps.  This will give you asm for an ANSI C compiler.  :-)

[ wrong list, please use gcc-help instead. ]

Re: unreducable cp_tree_equal ICE in gcc-4.0.0-20050410

[Michael Matz]

Hi,

On Wed, 13 Apr 2005, Nick Rasmussen wrote:

> I'm running into an ICE in the prerelease, that is proving to be
> very difficult in reducing to a small testcase.  If I preprocess
> the source (via -E or -save-temps) the code successfully compiles.
>  If I minimally change the source file in some ways(like adding a
> static integer in the global scope) the code compiles.  I've been
> able to delete some lines from the source file that's triggering
> the bug, including some from within the function that is
> triggering the ICE, but I'm down to a point where I can't easily
> reduce it further, or even get it into a single source file.

If possible you could tar eveything needed together with a small Makefile, 
for others to look at.  Otherwise it's will be difficult.  You can also 
compile cc1plus with debugging (just do a "make CFLAGS=-g" after 
configuring gcc, no bootstrap), and try to come up with some more info 
yourself.  For instance by printing the two trees which are impossible, by 
going to the cp_tree_equal frame and doing
  (gdb) p debug_tree(t1)
in gdb (and for t2).

> /dept/rnd/vendor/gcc-4.0.0pre1-amd64/bin/g++ -fno-builtin -O2 -g 
> -DHAVE_X86_64 -DHAVE_LITTLE_ENDIAN -DHAVE_BYTESWAP_H -DHAVE_64BIT_POINTER 
> -DHAVE_VA_COPY -DHAVE_XINERAMA -DPLATFORM_LINUX -D_FILE_OFFSET_BITS=64 
> -DHAVE_STL_LIMITS -DHAVE_IOS_BASE -Drestrict=__restrict__ 
> -DPLATFORM_LINUX_AMD64 -DPLATFORM=LINUX_AMD64 
> -DBUILD=LINUX_AMD64_GCC400pre1_OPT_DEBUG -DDISTRO_SUSE -DDISTRO=SUSE 
> -DDISTRO_VERSION=91 -DNVIDIA_VERSION_6111 -DNVIDIA_VERSION=6111 
> -DGCC_VERSION_400pre1 -DNDEBUG -I/usr/share/doc/NVIDIA_GLX-1.0/include -I. 
> -I/dept/rnd/home/nick/work/build-zeno2/SUSE_AMD64_GCC400pre1_OPT_DEBUG/include
>  -I/usr/X11R6/include -c bug.C -o /dev/null
> bug.C: In member function 'void EzFleshMesh::buildNodeArrays()':
> bug.C:411: internal compiler error: in cp_tree_equal, at cp/tree.c:1552

And give the context of that line.  Although it more seems like 
overwriting memory inside the compiler or something like this, as 
otherwise it would be more deterministic.

> #2  0x00473171 in cp_tree_equal (t1=0x2a9a1c94b0, t2=0x2a9a1cbb90) at 
> ../../gcc-4.0.0-20050410/gcc/cp/tree.c:1552
> #3  0x00473198 in cp_tree_equal (t1=0x2a9a013820, t2=0x2a9a031460) at 
> ../../gcc-4.0.0-20050410/gcc/cp/tree.c:1543
> #4  0x004590b3 in comptypes (t1=0x2a9a00ea90, t2=0x2a9a02bdd0, 
> strict=Variable "strict" is not available.
> ) at ../../gcc-4.0.0-20050410/gcc/cp/typeck.c:912
> #5  0x00458ede in comptypes (t1=0x2a9a00ec30, t2=0x2a9a032000, 
> strict=0) at ../../gcc-4.0.0-20050410/gcc/cp/typeck.c:1034
> #6  0x0047b0b9 in cxx_types_compatible_p (x=0x2a9a00ec30, 
> y=0x2a9a032000) at ../../gcc-4.0.0-20050410/gcc/cp/cp-objcp-common.c:173
> #7  0x007776bd in expressions_equal_p (e1=0x2a9a1c9640, 
> e2=0x2a9a1cbd20) at ../../gcc-4.0.0-20050410/gcc/tree-vn.c:127
> #8  0x007776f7 in val_expr_pair_expr_eq (p1=0xc16b90, p2=0xcd25e0) at 
> ../../gcc-4.0.0-20050410/gcc/tree-vn.c:153
> #9  0x007ffcba in htab_find_slot_with_hash (htab=0xca98a0, 
> element=0x81c3b9, hash=8504885, insert=INSERT) at 
> ../../gcc-4.0.0-20050410/libiberty/hashtab.c:660
> #10 0x0077794f in vn_add (expr=0x2a9a1cbd20, val=0x2a9a240330, 
> vuses=0x0) at ../../gcc-4.0.0-20050410/gcc/tree-vn.c:199
> #11 0x004e09c1 in execute_pre (do_fre=0 '\0') at 
> ../../gcc-4.0.0-20050410/gcc/tree-ssa-pre.c:1742

So PRE is trying to compare two types, and they contains something which 
can't be handled.  Either because they were silently overwritten, or 
because of a logical error.


Ciao,
Michael.

Re: GCC 4.0 RC2

[Mark Mitchell]

Jason Merrill wrote:
On Tue, 12 Apr 2005 10:59:42 -0700, Mark Mitchell <[EMAIL PROTECTED]> wrote:

Sadly, it's become clear there's going to have to be a second release
candidate.  In particular, there are some wrong-code bugs that are popping
up on real packages on primary platforms.  Jason Merill is looking into
some of the C++ issues, but he's in Lillehammer this week for the ISO
meeting.

Actually, I'm not. 
My mistake; I misread your other message.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: GCC 4.0 RC1 Available

[Mark Mitchell]

Ian Lance Taylor wrote:
touch testsuite_wchar_t
Does anybody else see this?  I imagine this would be fairly annoying
for some people.
This actually relates to the same V3 testsuite stuff that I've been 
trying to solve on the mainline.  Fundamentally, this happens because 
test-related stuff is being done outside of DejaGNU.  In particular, 
"make install" depends on "make all" (Automake does that), and "make 
all" recursively does "make all" in the V3 testsuite directory, which 
ought to be a no-op (testsuite things should only happen with "make 
check"), but is not a no-op because the V3 testsuite wants libv3test.a, 
and that gets built as part of "make all", again via Automake.

We could, in theory, fix this, in that it's only testsuite stuff that 
would have to change, not code.  But, it's a big change, and not fully 
done or settled on mainline.  So, we'll fix it in 4.0.1, at the earliest.

--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

re: unreducable cp_tree_equal ICE in gcc-4.0.0-20050410

[Dan Kegel]

Nick Rasmussen <[EMAIL PROTECTED]> wrote:
I'm running into an ICE in the prerelease, that is proving to be
very difficult in reducing to a small testcase.  If I preprocess
the source (via -E or -save-temps) the code successfully compiles.
> ...
Does this bug look familiar?  20629 is ICEing in the same spot, but
it looks like theirs was reproducible after preprocessing. 
Comment #4 in http://gcc.gnu.org/PR20629
makes it looks like they had the same sort of trouble
reproducing from preprocessed source:
"I'm still seeing this, but some info...
a) I'm only seeing this with LANG=C, export LANG=en_US.UTF-8 and there is no 
crash
b) compiling the dumped proprocessed code isn't crashing in either LANG"
So maybe you are in fact running into the same issue.
- Dan
--
Trying to get a job as a c++ developer?  See 
http://kegel.com/academy/getting-hired.html

Re: GCC 4.0 RC1 Available

[Eric Botcazou]

> Did this get resolved?

We found that PowerPC/Darwin and SPARC/Solaris have regressed the same way. 
Andrew should be looking at the failures on the Darwin side.

> Eric> Tom, I presume there was a very good reason for installing such
> Eric> a potentially destabilizing patch a few days before the
> Eric> prerelease?  What amount of testing did it undergo before being
> Eric> backported?
>
> More than the usual; I ran the test suite on two architectures (x86
> and ppc, the latter a multilib build), plus I tested it against
> eclipse and jonas.

OK.  That doesn't cover many architectures/OSes though.

-- 
Eric Botcazou

Re: GCC 4.0 RC2

[Jakub Jelinek]

On Wed, Apr 13, 2005 at 12:37:00PM -0700, Mark Mitchell wrote:
> >>Sadly, it's become clear there's going to have to be a second release
> >>candidate.  In particular, there are some wrong-code bugs that are popping
> >>up on real packages on primary platforms.  Jason Merill is looking into
> >>some of the C++ issues, but he's in Lillehammer this week for the ISO
> >>meeting.

BTW, http://gcc.gnu.org/PR20991 looks like an important newly (mid March)
introduced regression, but unfortunately I'm travelling today and so won't
be able to look at it toda and not sure if tomorrow.
I think we haven't rebuilt all our distro packages after mid March with GCC 4
pre though, so it might very well happen in other packages too.

Jakub