Another incidental observation from experiments with subversion: the
output from svn diff seems to be in a fairly random order (rather than
alphabetical order of filenames). Alphabetical order tends to be easier
to follow when checking svn diff output to see that the changes you're
about to co
Virender Kashyap wrote:
I have written a small structure (function_cfg_info) to hold CFG
information (defined in new file tree-cfg.h) and wanted to add this to
call graph node data structure (in cgraph.h).
This list isn't for people trying to learn how to write C code. It is
for people tryi
Christophe Jaillet wrote:
In loop.c, around line 8887, shouldn't the memory allocated by alloca be
'memseted' in some way ?
Look closer, and you will see that only array values that are set are used.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Daniel Berlin wrote:
> On Fri, 2005-02-11 at 15:29 +, Joern RENNECKE wrote:
> > Daniel Berlin wrote:
> >
> > >
> > >
> > >>Because svn keeps an extra pristine copy for checkouts, I'll have to use
> > >>svn export for
> > >>automatic regression tests.
> > >>
> > >>
> > >
> > >I don't
On Tue, 2005-02-15 at 00:55 +0100, Marcin Dalecki wrote:
> On 2005-02-14, at 19:47, Mike Stump wrote:
>
> > On Monday, February 14, 2005, at 04:04 AM, Richard Earnshaw wrote:
> >>> Fine, i'll just keep all the non-snapshot tags for now.
> >>
> >> There's no reason why we have to keep all the tags
On 2005-02-14, at 19:47, Mike Stump wrote:
On Monday, February 14, 2005, at 04:04 AM, Richard Earnshaw wrote:
Fine, i'll just keep all the non-snapshot tags for now.
There's no reason why we have to keep all the tags in one place.
Further, we can import them all, and then later remove, move or ren
On Mon, 2005-02-14 at 18:54 -0500, Daniel Berlin wrote:
> The SVN test repo has been updated. annotate should work at a reasonable
> speed (< 2 minutes for a file), *except* on the changelog. It spends a
> long time just groveling the file history. People who try to run
> annotate on the ChangeLog
The SVN test repo has been updated. annotate should work at a reasonable
speed (< 2 minutes for a file), *except* on the changelog. It spends a
long time just groveling the file history. People who try to run
annotate on the ChangeLog will be beaten severely.
I'm building a bdb test repo to see
Geoffrey Keating wrote:
Mark Mitchell <[EMAIL PROTECTED]> writes:
Steven Bosscher wrote:
Or should the development plan beupdated to reflect your new way of
working (ie. the projects info collecting thing) and the actual
development schedule that we seem to be working on.
It would probably be good
On Mon, 2005-02-14 at 15:20 -0800, Geoffrey Keating wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> > I also plan on excluding merge tags
>
> I'd really rather that you didn't. Those tags are useful when you're
> looking at some old change on a branch.
I meant for the test repo.
However,
Daniel Berlin <[EMAIL PROTECTED]> writes:
> I also plan on excluding merge tags
I'd really rather that you didn't. Those tags are useful when you're
looking at some old change on a branch.
Mark Mitchell <[EMAIL PROTECTED]> writes:
> Steven Bosscher wrote:
> > Or should the development plan beupdated to reflect your new way of
> > working (ie. the projects info collecting thing) and the actual
> > development schedule that we seem to be working on.
>
> It would probably be good if t
On Mon, 14 Feb 2005, Gabriel Dos Reis wrote:
> But the program at issue does not invoke anything having to do with
> POSIX, it makes no sense to pretend it has undefined behaviour.
The GNU C dialect, which is the default, includes various built-in
functions from POSIX as well as various other mi
Hi,
I'd like to discuss with you a topic related to a recent bootstrap failure of
a couple of smaller embedded targets. The origin of the failure could be
removed easily. In my opinion the question is simply, what is the best way to
implement it?
Root of the problem is that libgcc2 presently d
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
| On Mon, 14 Feb 2005, Matt Austern wrote:
|
| > What was the rationale behind issuing this warning? I find it rather
| > unfriendly. In this example, after all, the user isn't doing anything
wrong.
| > scalb is not defined in any standard that I c
Hi Chris,
On Mon, 2005-02-14 at 19:50 +, Chris Burdess wrote:
> What's the plan for auxiliary classpath modules such as inetlib and
> cp-tools? Are they still managed in the Savannah bug tracker?
The current plan is to also move them over and assign them separate
categories/modules in the ne
Hi,
Is GCC + gprof supposed to handle nested functions?
It looks like they are not properly reported.
The original problem was on Ada code with nested
functions. This is with HEAD and GNU gprof 2.15.91.0.2
on a SuSE 9.2 system.
Thanks in advance,
Laurent
$ cat cn.c
#define N 1000
static int
On Mon, 14 Feb 2005, Matt Austern wrote:
> What was the rationale behind issuing this warning? I find it rather
> unfriendly. In this example, after all, the user isn't doing anything wrong.
> scalb is not defined in any standard that I can see, and users have every
> right to declare a function
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mark Wielaard wrote:
If there are no objections we would like to close down the savannah bug
tracker for GNU Classpath and add a new "product" classpath in GCC
bugzilla which contains all the current bug reports. This new
'classpath' product shall be us
In the C front end, when diagnose_mismatched_decls sees a declaration
of a function whose name is the same as a builtin's but whose types are
different, we use the declaration we see but we issue a warning. For
example:
[isolde:tmp]$ cat foo.c
extern double scalb ( double, int );
[isolde:tmp]$
On Mon, 2005-02-14 at 10:47 -0800, Mike Stump wrote:
> On Monday, February 14, 2005, at 04:04 AM, Richard Earnshaw wrote:
> >> Fine, i'll just keep all the non-snapshot tags for now.
> >
> > There's no reason why we have to keep all the tags in one place.
>
> Further, we can import them all, and
Vivek,
GCC and the GNU project have nothing to do with SUIF. If you want to ask
questions about SUIF, you should do so on a more appropriate mailing list. I
suggest you look here: http://www-suif.stanford.edu/mailman/listinfo/suif-talk/
Good luck.
--Bob
On Monday, February 14, 2005, at 04:04 AM, Richard Earnshaw wrote:
Fine, i'll just keep all the non-snapshot tags for now.
There's no reason why we have to keep all the tags in one place.
Further, we can import them all, and then later remove, move or rename
them and these things seem to be versi
On Mon, 14 Feb 2005, Mark Wielaard wrote:
> I will send a proposal for the module names, standard bug mailinglist
> and version numbers to use for this new classpath product in the
> database to the classpath and libgcj development mailinglists soon. The
> current gcc modules AWT and SWING would a
On Mon, Feb 14, 2005 at 05:53:09PM +0100, Mark Wielaard wrote:
> This is a request for comments on moving the GNU Classpath bug reports
> (currently on savannah.gnu.org) into the gcc bugzilla database (as a
> separate project). This will ease sharing information between the GNU
> Classpath and GCC/
Hi GCC and GNU Classpath and libgcj hackers,
This is a request for comments on moving the GNU Classpath bug reports
(currently on savannah.gnu.org) into the gcc bugzilla database (as a
separate project). This will ease sharing information between the GNU
Classpath and GCC/GCJ hackers.
We have dis
> * Project Title
SMS (Modulo Scheduling) Improvements.
>
> * Project Contributors
Mostafa Hagog
>
> * Dependencies
No dependencies.
>
> * Delivery Date
Ready, currently committed to the autovect-branch.
>
> * Description
>
> Describe the project *in detail*.
>
> What will you be doing
Ignore this - happens only when building HEAD with some local patches.
Richard.
On Mon, 14 Feb 2005, Richard Guenther wrote:
> Hi!
>
> I get a strange ICE if building (not bootstrapping) mainline with
> current 3.4 branch with CFLAGS="-g":
>
> /tmp/gcc-obj-checking/gcc/xgcc -B/tmp/gcc-obj-checki
Richard Guenther <[EMAIL PROTECTED]> wrote:
> I get a strange ICE if building (not bootstrapping) mainline with
> current 3.4 branch with CFLAGS="-g":
>
> /tmp/gcc-obj-checking/gcc/xgcc -B/tmp/gcc-obj-checking/gcc/
> -B/i686-pc-linux-gnu/bin/ -B/i686-pc-linux-gnu/lib/ -isystem
> /i686-pc-linux-gnu
Hi!
I get a strange ICE if building (not bootstrapping) mainline with
current 3.4 branch with CFLAGS="-g":
/tmp/gcc-obj-checking/gcc/xgcc -B/tmp/gcc-obj-checking/gcc/
-B/i686-pc-linux-gnu/bin/ -B/i686-pc-linux-gnu/lib/ -isystem
/i686-pc-linux-gnu/include -isystem /i686-pc-linux-gnu/sys-include -c
On Feb 14, 2005, [EMAIL PROTECTED] (Jack Howarth) wrote:
> I am trying to find out if there has been some change to the
> internal symbol name associated with fprintf in libgcc of gcc 4.0
> compared to gcc 3.3.
There's no fprintf symbol in libgcc. fprintf is provided by the C
library of the syst
Jack Howarth wrote:
I am trying to find out if there has been some change to the
internal symbol name associated with fprintf in libgcc of gcc 4.0
compared to gcc 3.3. In particular, I am concerned about being
able to use the linker from gcc 4.0 to link in IBM Fortran XL code
with gcc 4.0 compil
I am trying to find out if there has been some change to the
internal symbol name associated with fprintf in libgcc of gcc 4.0
compared to gcc 3.3. In particular, I am concerned about being
able to use the linker from gcc 4.0 to link in IBM Fortran XL code
with gcc 4.0 compiled code using the li
In article <[EMAIL PROTECTED]> you write:
>Thanks Jon,
>
>Can anyone throw more light on this.
>
Stop telling us what you want to do, explain to us WHY you want to do
it.
There are lots of different reasons for which you might want to know
more about temporary object generation, and we can probab
Index: MAINTAINERS
===
RCS file: /cvs/gcc/gcc/MAINTAINERS,v
retrieving revision 1.394
diff -c -3 -p -r1.394 MAINTAINERS
*** MAINTAINERS 10 Feb 2005 23:29:41 - 1.394
--- MAINTAINERS 14 Feb 2005 11:19:52 -
*** Je
On Sat, 2005-02-12 at 02:53, Daniel Berlin wrote:
> On Fri, 2005-02-11 at 18:40 -0800, Mike Stump wrote:
> > On Friday, February 11, 2005, at 05:29 PM, Daniel Berlin wrote:
> > > I'll keep the last branchpoint of each branch for the initial import
> >
> > Won't work either... Sometimes we reuses
Thank you for the very clarifying text below. Some version of it would surely
be helpful in the gcc manual when introducing the -march and -mcpu/-mtune
flags.
Since I needed atomic read/writes of FP variables in a multi-threaded program,
I have no other option than using the slow fld/fst instr
38 matches
Mail list logo
