Re: basic VRP min/max range overflow question

[Paolo Bonzini]

Paul Schlie wrote:

Upon a potential integer overflow of either it's min or max range,
shouldn't the result be set to [min:type-min-value, max:type-max-value],
without the necessity of any further designations?


No.

[10, INT_MAX] + [ 1, 1 ] == [ 11, INT_MAX ] because of the famous signed 
int overflow definition in the C standard.


[10U, UINT_MAX] + [ 1U, 1U ] == ~[ 1U, 10U ]

Paolo

Re: basic VRP min/max range overflow question

[Paul Schlie]

> Paolo Bonsini wrote:
>> Upon a potential integer overflow of either it's min or max range,
>> shouldn't the result be set to [min:type-min-value, max:type-max-value],
>> without the necessity of any further designations?
>
> No.
> 
> [10, INT_MAX] + [ 1, 1 ] == [ 11, INT_MAX ] because of the famous signed
> int overflow definition in the C standard.
>
> [10U, UINT_MAX] + [ 1U, 1U ] == ~[ 1U, 10U ]

??? Do you mean:

H.2.2  Integer types

   [#1] The signed C integer types int,  long,  long  long  and  the
   corresponding  unsigned  types  are compatible with LIA-1.  If an
   implementation adds support  for  the  LIA-1  exceptional  values
   integer_overflow  and  undefined,  then  those  types  are  LIA-1
   conformant types.  C's unsigned integer types are "modulo" in the
   LIA-1  sense  in that overflows or out-of-bounds results silently
   wrap. An implementation that defines signed integer types as also
   being  modulo  need  not  detect integer overflow, in which case,
   only integer divide-by-zero need be detected.

Where in combination with:

5.1.2.3  Program execution

Examples 2.  In executing the fragment

 char c1, c2;
 /* ... */
 c1 = c1 + c2;

 the ``integer promotions'' require that  the  abstract
 machine promote the value of each variable to int size
 and then add  the  two  ints  and  truncate  the  sum.
 Provided the addition of two chars can be done without
 overflow,  or  with  overflow  wrapping  silently   to
 produce  the correct result, the actual execution need
 only produce the same result,  possibly  omitting  the
 promotions.

It seems pretty clear given that for all practical purposes all typical
machines do silently wrap integer overflow, they all correspondingly yield:

  [10, INT_MAX] + [ 1, 1 ] == [INT_MIN, INT_MAX ]

  [10U, UINT_MAX] + [ 1U, 1U ] == [UINT_MIN, UINT_MAX]

or more generally: [_MIN, _MAX] upon overflow.

building 3.4.x with in-tree binutils 2.16.*

[Jan Beulich]

These patches

http://gcc.gnu.org/ml/gcc-patches/2004-03/msg02319.html 
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg00466.html 

are needed (the former in at least a rudimentary backport form) in order to be 
able to build a 3.4.x tree with an overlaid binutils 2.16 or newer tree. Are 
there any plans to backport these?

Jan

Re: Bootstrap Failure (i686-pc-linux-gnu, --with-arch=pentium4)

[Volker Reichelt]

> Hi,
> 
>   For two consecutive days, I have been unable to
> build GCC mainline on i686-pc-linux-gnu:

> /home/ranmath/src/gcc/gcc-20050617/gcc/config/i386/i386.c: In function
> 'ix86_expand_vector_init':
> /home/ranmath/src/gcc/gcc-20050617/gcc/config/i386/i386.c:17080:
> error: insn does not satisfy its constraints:
> (insn 367 343 378 4
> /home/ranmath/src/gcc/gcc-20050617/gcc/config/i386/i386.c:17047 (set
> (reg:QI 138)
> (const_int 0 [0x0])) 45 {*movqi_1} (nil)
> (expr_list:REG_EQUIV (const_int 0 [0x0])
> (nil)))
> /home/ranmath/src/gcc/gcc-20050617/gcc/config/i386/i386.c:17080:
> internal compiler error: in reload_cse_simplify_operands, at
> postreload.c:391
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See http://gcc.gnu.org/bugs.html> for instructions.
> - 8<
> -
> 
> I build with "--with-arch=pentium4 --disable-checking" and that
> might explain why no one has apparently reported it yet. 

It has already been reported, it's PR22089 ;-)
http://gcc.gnu.org/PR22089

Nobody patches reload without causing regressions.
Sometimes even looking hard at the code can cause failures. ;-)

> Thanks,
> Ranjit.

Regards,
Volker

Re: basic VRP min/max range overflow question

[Paolo Bonzini]

  [#1] The signed C integer types int,  long,  long  long  and  the
  corresponding  unsigned  types  are compatible with LIA-1.  If an
  implementation adds support  for  the  LIA-1  exceptional  values
  integer_overflow  and  undefined,  then  those  types  are  LIA-1
  conformant types.
 

They need not wrap around.  People that are actually on the C standards 
committee have told you this multiple times.



  C's unsigned integer types are "modulo" in the
  LIA-1  sense  in that overflows or out-of-bounds results silently
  wrap. An implementation that defines signed integer types as also
  being  modulo  need  not  detect integer overflow, in which case,
  only integer divide-by-zero need be detected.
 


This is different from signed types.  Actually I was wrong,

  [10U, UINT_MAX] + [ 1U, 1U ] == ~[ UINT_MIN + 1, 10U ]

Paolo

Re: Major regression in 4.1.

[sjhill]

> Does this look familiar to anyone?  It certainly was happening
> a few days ago.  Shouldn't a bootstrap and regression of all
> frontend be required before someone checks in a patch to the
> back-end?
> 
Indeed. The last working GCC-4.1 compiler for both MIPS and i686
was back on 20050604. The bug biting me is 22014 which is another
ICE in the tree-ssa-structalias.c file. Right now the backend is
hosed and unusable.

-Steve

Re: basic VRP min/max range overflow question

[Diego Novillo]

On Fri, Jun 17, 2005 at 12:27:55AM -0400, Paul Schlie wrote:

> Upon a potential integer overflow of either it's min or max range,
> shouldn't the result be set to [min:type-min-value, max:type-max-value],
> without the necessity of any further designations?
> 
If you want this behaviour, use -fwrapv.


Diego.

Re: GCC 3.3.1 -O2 problem with sqrt.c

[Sanjiv Kumar Gupta]

--- Ian Lance Taylor  wrote:

> Sanjiv Kumar Gupta <[EMAIL PROTECTED]> writes:
> 
> > >>I couldn't understand why the insns 620 and 621
> are
> > >>being generated here as DI moves.
> > > I'm not sure specifically why it got a DI move
> here, but it doesn't
> > > look wrong.  It's treating the struct named
> parts as DImode.
> > >
> > >>This is creating problem since insn 621 gets
> splitted
> > >>after reload into two SI moves,i.e. @(r21, -8)
> and
> > >>@(r21, -4).
> > >>This renders insns 619 as dead and hence insns
> 618 and
> > >>insn 429 as dead, which are eliminated by flow2.
> > > It does look rather suspicious, but it's hard to
> know whether it is
> > > wrong without seeing the value in r1.
> > >
> > r1 looks unrelated to struct members, and is being
> used by the
> > ifcvt pass to expand some comparison insns.
> 
> In your .23 file, this is insn 431:
> 
> (insn 431 430 432 39 0x1002f420 (set (subreg:SI
> (reg/v:DI 153) 0)
> (reg/v:SI 77)) 6 {*movsi} (insn_list 429
> (nil))
> (expr_list:REG_DEAD (reg/v:SI 77)
> (nil)))
> 
> So it is setting the first SI subreg of a DI value. 
> reload decides to
> do an output reload for register 153.  Since
> register 153 is DImode,
> it does a DImode reload.
> 
> It winds up copying the DImode value to r2, and then
> writing r2 to
> memory.  The double move is because there is a
> secondary reload
> involved.  That implies that
> SECONDARY_OUTPUT_RELOAD_CLASS is defined
> and is returning something other than NO_REGS for
> this case.
> 
> I see that insn 429 is setting the high part of
> register 153.  Insn
> 429 looks like this:
> 
> (insn 429 428 430 39 0x1002f420 (set (subreg:SI
> (reg/v:DI 153) 4)
> (plus:SI (reg/v:SI 79)
> (reg/v:SI 82))) 12 {addsi3} (insn_list
> 422 (nil))
> (expr_list:REG_DEAD (reg/v:SI 82)
> (expr_list:REG_DEAD (reg/v:SI 79)
> (nil
> 
> But note that a set to a subreg is explicitly
> defined to set the other
> parts of the register to garbage.  Therefore the
> value set by insn 429
> is destroyed by insn 431.
> 
> I would guess that you need a strict_low_part in
> insns 429 and 431.
> See the RTL documentation.
> 
> Ian
> 
Thanks Ian for your inputs. The problem got solved.
There was no intermediate reg needed for this reload.
But I still feel that a strict_low_part would be
needed as you suggested.

Thanks again.

Sanjiv

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

Re: Bootstrap Failure (i686-pc-linux-gnu, --with-arch=pentium4)

[Ranjit Mathew]

On 6/17/05, Volker Reichelt <[EMAIL PROTECTED]> wrote:
> >
> >   For two consecutive days, I have been unable to
> > build GCC mainline on i686-pc-linux-gnu:

[...]

> > I build with "--with-arch=pentium4 --disable-checking" and that
> > might explain why no one has apparently reported it yet.
> 
> It has already been reported, it's PR22089 ;-)
> http://gcc.gnu.org/PR22089

FWIW, RTH's patch in:

  http://gcc.gnu.org/ml/gcc-patches/2005-06/msg01487.html

allows me to complete bootstrap (c,c++,java) as well as
run the libjava testsuite successfully. (Except for the
"Divide_1" testcase that has started failing recently
due to another as-yet-unknown-but-introduced-this-week
back-end bug:

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


> Nobody patches reload without causing regressions.
> Sometimes even looking hard at the code can cause failures. ;-)

:-)

http://gcc.gnu.org/wiki/reload seems to indicate something
similar.

Thanks,
Ranjit.

-- 
Ranjit Mathew  Email: rmathew AT gmail DOT com

Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/

Re: Major regression in 4.1.

[Daniel Berlin]

On Fri, 17 Jun 2005 [EMAIL PROTECTED] wrote:


Does this look familiar to anyone?  It certainly was happening
a few days ago.  Shouldn't a bootstrap and regression of all
frontend be required before someone checks in a patch to the
back-end?


Indeed. The last working GCC-4.1 compiler for both MIPS and i686
was back on 20050604. The bug biting me is 22014 which is another
ICE in the tree-ssa-structalias.c file.


Except that doesn't block bootstrap, except for Ada.
I tested it on 3 platforms before committing it :)

I'm also working on these regressions, i've just been away this week.

Expect to see them solved by sunday.

Keysigning at GCC summit

[Matthew Wilcox]

I'm running the keysigning again at GCC Summit this year.  Please check
the signup sheet [1] to see if you're on it.  I added people to it
if they filled in their key details on the registration form.  I also
added Mark and Gaby [2].  If you want to participate and aren't currently
listed, please send your fingerprint to keys -at- gccsummit.org as soon
as possible, certainly by Monday.

[1] http://www.parisc-linux.org/~willy/wot/gcc2005/party.html
[2] http://gcc.gnu.org/ml/gcc/2005-05/msg01514.html

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

PowerPC small data sections.

[Sergei Organov]

Hi,

The gcc-2.95.x seems to be the last GCC version that have usable support
for small data sections (.sdata & .sdata2) on PowerPC, see PRs 9571,
17337(resolved), and finally 21571.

As my embedded project heavily relies on the advantages of using small
data sections, it makes it impossible for me to switch to a newer gcc
version. Each time I try, the result is yet another PR. I'd like to
invest some of my time to investigate the problem in more details to try
to resolve the issue.

The first thing I'd like to get some advice on is which codebase do I
use, gcc-4_0-branch?

In addition, any comments, thoughts, and info about current status would
be greatly appreciated.

-- 
Sergei.

Re: basic VRP min/max range overflow question

[Paul Schlie]

> They need not wrap around.  People that are actually on the C standards
> committee have told you this multiple times.

Yes, and may clearly produce erroneous results if the value ranges
are not consistent with the factual behavior of an implementation, i.e.:

 int x;
 volatile int v;

 x = (v ? 0 : INT_MAX) + 1;  // [1, INT_MAX] (without -fwrapv)

 if (x <= 0) // Which may be erroneously
  printf("%i is <= 0.", x);  // optimized away, with this.
 else
  printf("%i is > 0.", x);   // Leaving only this in error.

As regardless of the value of x produced by an implementation, it's wrong
to presume a result which is not consistent with the factual behavior of
that implementation.  Therefore -fwrapv must be presumed for all targets
which effectively wrap signed integer overflows, as otherwise non-
conformant behaviors may result. (i.e. effectively all present targets)

As I doubt "-2147483648 > 0" or "0 > 0" (as may otherwise result from
typical 2's or 1's complement implementations which silently wrap
overflows), can be justified as being a valid conforming result in any
circumstance. (and confess that I have nothing more to add if not obvious).

Re: basic VRP min/max range overflow question

[Paolo Bonzini]

Paul Schlie wrote:


They need not wrap around.  People that are actually on the C standards
committee have told you this multiple times.
   



Yes, and may clearly produce erroneous results if the value ranges
are not consistent with the factual behavior of an implementation, i.e.:
 

Are you listening or not??? This is *not* meant to be inconsistent with 
"the factual behavior of an implementation".  It is simply not 
specified.  It is not portable.  It should not be done.  Period.


On many embedded machines, dereferencing a NULL pointer is perfectly 
ok.  To avoid problems with C optimizations where dereferencing a NULL 
pointer is consider to have unspecified behavior, code is usually put 
there.  Does this make it "non-conformant" to optimize away this if?


  char *a, b;
  a = NULL;
  b = *a;
  if (a == NULL)
abort ();

Well, according to zillions of embedded C developers, it is not.

A similar case of unspecified behavior that "just works" is this.  On 
the i386, passing variadic arguments to a function without a prototype 
usually just works.  On other machines it may not because the ellipsis 
has a different calling conventions.  It is not specified.  It is not 
portable.  It should not be done.  Period.


Read the standard, *understand* what it says, then come back.  Or anyway 
do not complain here, propose a DR on the C standard committee and wait 
for it to be rejected.


I *know* I'm being rude, but I'm also fed up by this utter waste of time 
and bandwidth, and am not going to spend more time on this.


Paolo

Re: basic VRP min/max range overflow question

[Diego Novillo]

On Fri, Jun 17, 2005 at 02:28:58PM -0400, Paul Schlie wrote:

>  int x;
>  volatile int v;
> 
>  x = (v ? 0 : INT_MAX) + 1;  // [1, INT_MAX] (without -fwrapv)
> 
>  if (x <= 0) // Which may be erroneously
>   printf("%i is <= 0.", x);  // optimized away, with this.
>  else
>   printf("%i is > 0.", x);   // Leaving only this in error.
> 
You want to file a DR with the language standards.  This is now
wasting everybody's time.

The compiler is perfectly free to fold that if() away.  The fact
that it doesn't do it now is actually a missed optimization
opportunity (a PHI node with all arguments > 0 could produce the
range [1, +INF]).


Diego.

GCC 4.0.1 RC2

[Mark Mitchell]

GCC 4.0.1 RC2 is now available here:

  ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.1-20050616

This version has the libstdc++ versioning changes, and most of the PO 
file updates.  The PO file that Joseph checked in today is not included, 
but will be in the final release.


Please test this version and report problems in Bugzilla, with a Cc: to 
me.  I'd also appreciate explicit confirmation from a representative of 
the libstdc++ team that this version as packaged still has the desired 
behavior, just to catch any packaging snafus.


With luck, I'll announce the final release during the summit next week...

Thanks,

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

Your rtti.c changes broke some obj-c++ tests

[Giovanni Bajo]

Nathan,

I see some failures in the testsuite which appear to be related by your recent
changes to rtti.c (VECification). For instance:

FAIL: obj-c++.dg/basic.mm (test for excess errors)
Excess errors:/home/rasky/gcc/mainline/gcc/libstdc++-v3/libsupc++/exception:55:
internal compiler error: vector VEC(tinfo_s,base) index domain error, in
get_tinfo_decl at cp/rtti.c:373

Would you please check and possibly fix this?

Thanks,
Giovanni Bajo

Re: basic VRP min/max range overflow question

[Paul Schlie]

> From: Diego Novillo <[EMAIL PROTECTED]>
> On Fri, Jun 17, 2005 at 02:28:58PM -0400, Paul Schlie wrote:
> 
>>  int x;
>>  volatile int v;
>> 
>>  x = (v ? 0 : INT_MAX) + 1;  // [1, INT_MAX] (without -fwrapv)
>> 
>>  if (x <= 0) // Which may be erroneously
>>   printf("%i is <= 0.", x);  // optimized away, with this.
>>  else
>>   printf("%i is > 0.", x);   // Leaving only this in error.
>> 
> You want to file a DR with the language standards.

- There's nothing wrong with the standard, just it's implementation.

  (As there's nothing in the standard which enables an implementation
  to subsequently disregard the resulting value of an implementation
  specific operation from the best I can tell; although would welcome
  someone pointing out where specifically it's allowed.  As unless
  it is, an undefined result is specific to the just that operation.
  It does not magically alter the semantics well defined operations
  which may utilize that result, regardless of it's value.)

  ["undefined" only provides liberties within the constrains of what
  is specifically specified as being undefined, but none beyond that.]

Re: basic VRP min/max range overflow question

[Andrew Pinski]

On Jun 17, 2005, at 8:20 PM, Paul Schlie wrote:


  ["undefined" only provides liberties within the constrains of what
  is specifically specified as being undefined, but none beyond that.]


That is not true.  Undefined means it can run "rm /" if you ever invoke
the undefined code.

Thanks,
Andrew Pinski

Re: basic VRP min/max range overflow question

[Paul Schlie]

> From: Andrew Pinski <[EMAIL PROTECTED]>
> On Jun 17, 2005, at 8:20 PM, Paul Schlie wrote:
> 
>>   ["undefined" only provides liberties within the constrains of what
>>   is specifically specified as being undefined, but none beyond that.]
> 
> That is not true.  Undefined means it can run "rm /" if you ever invoke
> the undefined code.

- If the semantics of an operation are "undefined", I'd agree; but if
  control is returned to the program, the program's remaining specified
  semantics must be correspondingly obeyed, including the those which
  may utilize the resulting value of the "undefined" operation.

- If the result value is "undefined", just the value is undefined.

(Unless one advocates that any undefined result implies undefined semantics,
which enables anything to occur, including the arbitrary corruption of
the remaining program's otherwise well defined semantics; in which case any
invocation of implementation specific behavior may then validly result in
arbitrary remaining program behavior.)

Which I'd hope isn't advocated.

Re: basic VRP min/max range overflow question

[Dale Johannesen]

On Jun 17, 2005, at 5:59 PM, Paul Schlie wrote:


From: Andrew Pinski <[EMAIL PROTECTED]>
On Jun 17, 2005, at 8:20 PM, Paul Schlie wrote:


  ["undefined" only provides liberties within the constrains of what
  is specifically specified as being undefined, but none beyond 
that.]


That is not true.  Undefined means it can run "rm /" if you ever 
invoke

the undefined code.


- If the semantics of an operation are "undefined", I'd agree; but if
  control is returned to the program, the program's remaining specified
  semantics must be correspondingly obeyed, including the those which
  may utilize the resulting value of the "undefined" operation.

- If the result value is "undefined", just the value is undefined.

(Unless one advocates that any undefined result implies undefined 
semantics,

which enables anything to occur, including the arbitrary corruption of
the remaining program's otherwise well defined semantics; in which 
case any
invocation of implementation specific behavior may then validly result 
in

arbitrary remaining program behavior.)

Which I'd hope isn't advocated.


You are wrong, and this really isn't a matter of opinion.  The standard 
defines exactly

what it means by "undefined behavior":

3.4.3 1 undefined behavior
behavior, upon use of a nonportable or erroneous program construct or 
of erroneous data,

 for which this International Standard imposes no requirements
2 NOTE  Possible undefined behavior ranges from ignoring the situation 
completely with
unpredictable results, to behaving during translation or program 
execution in a documented
manner characteristic of the environment (with or without the issuance 
of a diagnostic message),
to terminating a translation or execution (with the issuance of a 
diagnostic message).

Re: basic VRP min/max range overflow question

[Robert Dewar]

Paul Schlie wrote:


  (As there's nothing in the standard which enables an implementation
  to subsequently disregard the resulting value of an implementation
  specific operation from the best I can tell; although would welcome
  someone pointing out where specifically it's allowed.  As unless
  it is, an undefined result is specific to the just that operation.
  It does not magically alter the semantics well defined operations
  which may utilize that result, regardless of it's value.)

  ["undefined" only provides liberties within the constrains of what
  is specifically specified as being undefined, but none beyond that.]


You are forgetting the "as if" semantics that is always inherent in
the standard. So after an operation with an undefined result, we can
do anything we like with the value, since it is "as if" the operation
had produced that value. So for example, if we skip an operation because
we know it will overflow, and end up using uninitialized junk in a register,
it is "as if" that undefined operation produced the particular uninitialized
junk value that we ended up with.

So the above is inventive but wrong.

Re: Visual C++ style inline asms

[Michael Meissner]

On Tue, Jun 14, 2005 at 10:08:16PM -0700, Richard Henderson wrote:
> I suspect that one could get quite a lot of milage out of parsing
> the assembly code and turning most of it into straight GIMPLE, rather
> than into ASM_EXPRs.  A great many examples of VC++ inline asms that
> I've seen were completely and utterly trivial; the compiler could have
> done a better job.  Of course there will be cases that you either
> can't understand, or use instructions that don't map to an EXPR or a
> builtin.  But I expect that more often than not, you can reduce the
> inline asm block to one such insn, and expose all the rest of the
> data movement to the compiler.

My previous employer (Metrowerks) did this when parsing GCC style asm
instructions, and it caused lots of complaints from users.  The main complaint
is users did not want the compiler mucking about with their precious hand
scheduled insns, and made it much harder to debug.

Another problem is when things like status registers or flags fields aren't
adequately handled by the compiler.  For example on the x86, if you change the
rounding mode, we currently don't have a (USE) of the flags field, so the
compiler doesn't know that it can't move the set rounding mode instruction
before other floating point instructions.  Obviously, the right solution is the
encode all of this hidden state information into the RTL, GIMPLE, etc. but it
is a large and mind numbing process.

Finally, for the x86/x86_64, there are a lot of instructions that need to be
handled, and it is an ongoing maintenance problem in that you now need to
modify GCC as well as binutils to add new instructions.

-- 
Michael Meissner
email: [EMAIL PROTECTED]

Re: PowerPC small data sections.

[Mike Stump]

On Friday, June 17, 2005, at 07:13  AM, Sergei Organov wrote:

The first thing I'd like to get some advice on is which codebase do I
use, gcc-4_0-branch?


No, mainline.  If it doesn't work there, is won't work anyplace else.  
:-(  Once you get it working there, you can then ask for the patches, 
if safe enough, to go into the release branches.

Re: basic VRP min/max range overflow question

[Mike Stump]

On Friday, June 17, 2005, at 05:59  PM, Paul Schlie wrote:

- If the semantics of an operation are "undefined", I'd agree; but if
  control is returned to the program, the program's remaining specified
  semantics must be correspondingly obeyed, including the those which
  may utilize the resulting value of the "undefined" operation.


I am sorry the standard disagrees with you:

   [#3] A  program  that  is  correct  in  all  other  aspects,
   operating  on  correct data, containing unspecified behavior
   shall be a  correct  program  and  act  in  accordance  with
   5.1.2.3.

:-(  Maybe you just mean that you'd like it if the compiler should 
follow the remaining semantics as best it can, on that point, I'd agree.

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Mike Stump]

On Thursday, June 16, 2005, at 10:26  AM, Roberto Bagnara wrote:

OK, you did not have time to check the standard... perhaps it is the
word "bugmaster" that generates unreasonable expectations.


Think of them as BugMonkeys if it helps.  :-)

Re: The tree API

[Mike Stump]

On Thursday, June 16, 2005, at 03:16  AM, [EMAIL PROTECTED] wrote:

I'm a new guy in gcc mailing list I've been studying gcc for 2 months.


Why?


My problem is there are so much symbol/function/API in gcc.


You have two choices ignore what you aren't interested in learning, or 
learn it all.  Your choice.  I'd recommend the former.



This approach is not effective.


Ok.  Without knowing what you're doing and why you're doing it and how 
you're doing it, we can't give you any more help at being effective.



If there is a way to learn the gcc internal APIs "systematically"?


Why?

Sounds like you're going about things the wrong way.


General hint, no one is likely to answer your question and give you the 
help you need, as we don't know what answer would help you.  Compare 
the needs of a person that is new to gcc in implementing a language 
front-end for Cobol versus a person that wants to implement a tree 
optimizer for autovectorization.  The answers for each are going to be 
slightly different.  I can't actually tell which of these you are 
doing, or if it is something else.  If you want help, you have to give 
us all the information about what you want to learn, why you want to 
learn it, and what we are going to get back from you for giving you the 
information.  Are we going a port, a new optimizer, a new language 
front end, or just the satisfaction knowing that you got an A on your 
homework?


In general, we can't teach you the code, the code is there for you to 
read and understand and teach yourself.  We can only help with a few of 
the fringes, like, do I need to recompute the cfg after I do X.  Is 
there a function I can call to do this?  Notice that this style of 
question has a few more details about what one is doing, and what 
specifically one needs help on.


Try writing a question that is 4x the size of this (non-)answer.

http://www.catb.org/~esr/faqs/smart-questions.html is a curious 
reference that comes to mind that we just saw go by...

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-16 17:54:03 -0400, Robert Dewar wrote:
> As you well know, not everyone agrees this is a bug, and this does
> not have to do with performance. Saying over and over again that you
> think it is a bug does not make it so.

I haven't seen any correct argument why it could not be a bug.
Saying that the x86 processor is buggy is just completely silly.
Only some gcc developers think so.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA