hello all,
Depending on the machine mode the compiler will generate automatically
the offset required for the stack operation i.e for a machine with
word size is 32, for char type the offset is 1, for int type the
offset is 2 and so on..
Is there a way to control this ? i mean say for long long
You want more bugs fixed, it would seem a better way would be to build
a better sense of community (Have bugfix-only days, etc) and encourage
it through good behavior, not through negative reinforcement.
I do agree with that in a general way, but I think there should also
be a real effort done b
2007/4/16, Mohamed Shafi <[EMAIL PROTECTED]>:
hello all,
Depending on the machine mode the compiler will generate automatically
the offset required for the stack operation i.e for a machine with
word size is 32, for char type the offset is 1, for int type the
offset is 2 and so on..
Is there a
Installed.
Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.607
diff -u -3 -p -r1.607 index.html
--- index.html 23 Mar 2007 08:31:00 - 1.607
+++ index.html 16 Apr 2007 08:51:28 -000
2007/4/16, François-Xavier Coudert <[EMAIL PROTECTED]> wrote:
> You want more bugs fixed, it would seem a better way would be to build
> a better sense of community (Have bugfix-only days, etc) and encourage
> it through good behavior, not through negative reinforcement.
I do agree with that in
On 4/16/07, J.C. Pizarro <[EMAIL PROTECTED]> wrote:
2007/4/16, Mohamed Shafi <[EMAIL PROTECTED]>:
> hello all,
>
> Depending on the machine mode the compiler will generate automatically
> the offset required for the stack operation i.e for a machine with
> word size is 32, for char type the offse
The "mea culpa" is to permit for long time to modify "configure" instead of
"configure.ac" or "configure.in" that is used by "autoconf" and/or "automake".
[...]
I'm sorry, but I don't understand at all what you propose, what your
proposal is supposed to fix or how that is related to the mail yo
On 4/16/07, J.C. Pizarro <[EMAIL PROTECTED]> wrote:
The "mea culpa" is to permit for long time to modify "configure" instead of
"configure.ac" or "configure.in" that is used by "autoconf" and/or "automake".
Another "mea culpa" is don't update the autoconf/automake versions when
the GCC''s script
2007/4/16, François-Xavier Coudert <[EMAIL PROTECTED]> wrote:
> The "mea culpa" is to permit for long time to modify "configure" instead of
> "configure.ac" or "configure.in" that is used by "autoconf" and/or "automake".
>
> [...]
I'm sorry, but I don't understand at all what you propose, what y
libdecnumber/aclocal.m4:# generated automatically by aclocal 1.9.5 -*-
Autoconf -*-
That's a problem in the last regeneration of this file. I'm CCing M.
Meissner, H. J. Lu and M. Cornea, since they appear to have last
changed this file, although there's no ChangeLog entry for it in their
commit.
2007/4/16, Andrew Pinski <[EMAIL PROTECTED]> wrote:
On 4/16/07, J.C. Pizarro <[EMAIL PROTECTED]> wrote:
> The "mea culpa" is to permit for long time to modify "configure" instead of
> "configure.ac" or "configure.in" that is used by "autoconf" and/or "automake".
>
> Another "mea culpa" is don't u
2007/4/16, François-Xavier Coudert <[EMAIL PROTECTED]> wrote:
> 1) To update the generated configure scripts of the tarball before
> than distributing it.
It could be done, but there's the risk that an automated process like
that might introduce problems. I'd be more in favour of a nightly
teste
On 16 April 2007 10:56, J.C. Pizarro wrote:
> The GCC scripts use autotools but the site don't use autotools because
> it says which is inconvenient. What???
Why don't you ever go and actually *find something out* about what
you're talking about before you spout nonsense all over the list?
2007/4/16, Mohamed Shafi <[EMAIL PROTECTED]> wrote:
> > Depending on the machine mode the compiler will generate automatically
> > the offset required for the stack operation i.e for a machine with
> > word size is 32, for char type the offset is 1, for int type the
> > offset is 2 and so on..
2007/4/16, Dave Korn <[EMAIL PROTECTED]> wrote:
On 16 April 2007 10:56, J.C. Pizarro wrote:
> The GCC scripts use autotools but the site don't use autotools because
> it says which is inconvenient. What???
Why don't you ever go and actually *find something out* about what
you're talking ab
On 4/16/07, J.C. Pizarro <[EMAIL PROTECTED]> wrote:
what is the matter if the generated files aren't updated?
The users will say many times broken situations like bootstrap doesn't
work or else.
99.9% of bootstrap failures are not related to generated files full stop.
Sounds like you are mixing
On 16 April 2007 11:17, J.C. Pizarro wrote:
> I follow,
No, not very well.
> The end-users who just want to compile gcc from a tarball do not
> have to have autoconf installed, because we supply all the generated files
> for them in the tarball. <- Well,
>
> what is the matter if the generate
On 4/16/07, J.C. Pizarro <[EMAIL PROTECTED]> wrote:
2007/4/16, Mohamed Shafi <[EMAIL PROTECTED]> wrote:
> > > Depending on the machine mode the compiler will generate automatically
> > > the offset required for the stack operation i.e for a machine with
> > > word size is 32, for char type the of
2007/4/16, Dave Korn <[EMAIL PROTECTED]> wrote:
On 16 April 2007 11:17, J.C. Pizarro wrote:
> I follow,
No, not very well.
> The end-users who just want to compile gcc from a tarball do not
> have to have autoconf installed, because we supply all the generated files
> for them in the tarball
> Also, beyond that, I would strongly suspect that these PRs haven't been
> fixed in large part because they're difficult to track down, and
> possibly if we knew what commit had introduced them, we'd be a good bit
> farther along in fixing them, even without having the help of whoever
> introd
Hello all,
Is that any reference (paper, guide, whatever,) on how gcc is handling
exceptions in intermediate code? Is it based on a known (published)
method? Is it intuitive and explained somewhere?
I've looked at internal docs but it is not really explicit how it
works. I'm having a hard time u
Hello all,
I ran a sample program with gcc 3.4.6 and gcc 4.1.1 compiler. I need
some clarifications regarding the DWARFinfo generated by these 2
compilers.
Sample Program:
#include
int fun(const char*, ...);
/* Variadic function */
int fun(const char *raj,...)
{
return 9;
}
int main()
{
f
Windows XP Pro/SP2 cygwin Pentium M processor 2.13GHz system with packages:
binutils 20060817-1 2.17.50 20060817
bison2.3-1 2.3
cygwin 1.5.24-2 (with Dave Korn's stdio.h patch in
newlib cvs)
dejagnu 20021217-2 1.4.2.x
e
Hello all,
I'm doing in my IPA pass:
for(node = cgraph_nodes; node; node = node->next) {
reg_cgraph_node(IDENTIFIER_POINTER(DECL_ASSEMBLER_NAME(node->decl)));
}
to get all the function names in the cgraph. I'm adding them to a list
and I'm assuming that two nodes do not have the same
DECL_ASS
Hi!
Initially I meant to optimize GCC, that includes runtime and memory
usage, of course.
Sure. I meant that we have testcases that are good to test your work
on. Profile GCC running them and fix the hotspots: this may show
quadratic algorithms, and the like.
For example, see the patch
Hello all,
I'm going through the bodies of all user-defined functions. I'm using
as user-defined function as one that:
DECL_BUILT_IN(node) == 0.
Problem is that for a function (derived from a C++ file) whose output
from my pass is (output is self-explanatory, I think):
Registering cgraph node:
Hi,
> Hello all,
>
> I'm doing in my IPA pass:
> for(node = cgraph_nodes; node; node = node->next) {
>reg_cgraph_node(IDENTIFIER_POINTER(DECL_ASSEMBLER_NAME(node->decl)));
> }
>
> to get all the function names in the cgraph. I'm adding them to a list
> and I'm assuming that two nodes do not h
On Mon, Apr 16, 2007 at 05:04:05PM +0100, Paulo J. Matos wrote:
> _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
> [operator<<]... SUCCESSFUL
> Well, this is definitely builtin but DECL_BUILT_IN == 0, which means
> that when I do FOR_EACH_BB_FN, I'm getting a segmentation fault.
>
> I wo
On 4/16/07, Paulo J. Matos <[EMAIL PROTECTED]> wrote:
Hello all,
I'm going through the bodies of all user-defined functions. I'm using
as user-defined function as one that:
DECL_BUILT_IN(node) == 0.
Problem is that for a function (derived from a C++ file) whose output
from my pass is (outpu
On 4/16/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
29841 [4.2/4.3 regression] ICE with scheduling and __builtin_trap
Honza, PING!
31360 [4.2/4.3 Regression] rtl loop invariant is broken
Zdenek, PING!
The broader question of why there are so many 124 P3 or higher
regressions against 4.
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
> Depending on the machine mode the compiler will generate automatically
> the offset required for the stack operation i.e for a machine with
> word size is 32, for char type the offset is 1, for int type the
> offset is 2 and so on..
>
> Is there a way
On 4/16/07, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
On Mon, Apr 16, 2007 at 05:04:05PM +0100, Paulo J. Matos wrote:
> _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
> [operator<<]... SUCCESSFUL
> Well, this is definitely builtin but DECL_BUILT_IN == 0, which means
> that when I do
On 4/16/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
First, it's not built in, because it's defined in a source file.
Builtin functions are those defined by the compiler.
Second, we should make FOR_EACH_BB_FN never crash on empty tree functions.
It seems really rude to do otherwise.
Just becaus
> On 4/16/07, Paulo J. Matos <[EMAIL PROTECTED]> wrote:
> >Hello all,
> >
> >I'm going through the bodies of all user-defined functions. I'm using
> >as user-defined function as one that:
> >DECL_BUILT_IN(node) == 0.
>
> >
> >Problem is that for a function (derived from a C++ file) whose output
>
> On 4/16/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> >
> >First, it's not built in, because it's defined in a source file.
> >Builtin functions are those defined by the compiler.
> >
> >Second, we should make FOR_EACH_BB_FN never crash on empty tree functions.
> >It seems really rude to do othe
On 4/16/07, Jan Hubicka <[EMAIL PROTECTED]> wrote:
Hi,
> Hello all,
>
> I'm doing in my IPA pass:
> for(node = cgraph_nodes; node; node = node->next) {
>reg_cgraph_node(IDENTIFIER_POINTER(DECL_ASSEMBLER_NAME(node->decl)));
> }
>
> to get all the function names in the cgraph. I'm adding them t
On 16 April 2007 17:31, Daniel Jacobowitz wrote:
> On Mon, Apr 16, 2007 at 05:04:05PM +0100, Paulo J. Matos wrote:
>> _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
>> [operator<<]... SUCCESSFUL
>
>> Well, this is definitely builtin but DECL_BUILT_IN == 0, which means
>> that when I do F
> On 4/16/07, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> >Hi,
> >> Hello all,
> >>
> >> I'm doing in my IPA pass:
> >> for(node = cgraph_nodes; node; node = node->next) {
> >>reg_cgraph_node(IDENTIFIER_POINTER(DECL_ASSEMBLER_NAME(node->decl)));
> >> }
> >>
> >> to get all the function names in th
"Paulo J. Matos" <[EMAIL PROTECTED]> writes:
> Is that any reference (paper, guide, whatever,) on how gcc is handling
> exceptions in intermediate code? Is it based on a known (published)
> method? Is it intuitive and explained somewhere?
I doubt it. But if you pull together some information, it
The piece of code attached to this mail does not compile with 4.3.0 20070113
(sorry this is rather old, but that's what I had available). The
architecture (although not relevant IMHO)
is i686-pc-linux-gnu.
[ Even though this is not relevant here, a similar error happens with
the redhat version
"Rohit Arul Raj" <[EMAIL PROTECTED]> writes:
> 1. In DIE for fun, with 3.4.6, the frame base is taken in terms of
> Frame Pointer (DW_OP_reg14), where is in 4.1.1, it is taken in terms
> of Stack Pointer (DW_OP_reg15).
>
> (For my backend, reg-no 14 is Frame Pointer and reg-no 15 is Stack Pointer
On 4/16/07, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> On 4/16/07, Paulo J. Matos <[EMAIL PROTECTED]> wrote:
> >Hello all,
> >
> >I'm going through the bodies of all user-defined functions. I'm using
> >as user-defined function as one that:
> >DECL_BUILT_IN(node) == 0.
>
> >
> >Problem is that for
On Mon, Apr 16, 2007 at 05:51:17PM +0100, Dave Korn wrote:
> Perhaps Paulo wants to know if the definition originated in a system header
> file?
Yes, this is more likely to be useful.
--
Daniel Jacobowitz
CodeSourcery
On Monday 16 April 2007 20:02:33 Theodore Papadopoulo wrote:
> The piece of code attached to this mail does not compile with 4.3.0
> 20070113 (sorry this is rather old, but that's what I had available). The
> architecture (although not relevant IMHO)
> is i686-pc-linux-gnu.
>
> [ Even though this i
>
> If you just want to scan every function you have around, the obvious
> way to do it is
>
> For each function
> FOR_EACH_BB_FN (function).
>
> This is probably slightly slower than
>
> For each function
> if cgraph_function_body_availability != NOT_AVAILABLE
>FOR_EACH_BB_FN (function)
On Mon, Apr 16, 2007 at 12:40:17PM +0100, Paulo J. Matos wrote:
> Hello all,
>
> Is that any reference (paper, guide, whatever,) on how gcc is handling
> exceptions in intermediate code? Is it based on a known (published)
> method? Is it intuitive and explained somewhere?
See
http://www.codesour
On Mon, Apr 16, 2007 at 10:25:34AM -0700, Joe Buck wrote:
> See
>
> http://www.codesourcery.com/cxx-abi/abi-eh.html
>
> Despite the fact that this document is called "Itanium C++ ABI", g++ uses
> this approach on most platforms, including x86 (there is another
> implementation supported by GCC, "
On Mon, Apr 16, 2007 at 06:36:07PM +0200, Steven Bosscher wrote:
> * Very few people know how to use Janis' scripts, so to encourage
> people to use them, the release manager could write a wiki page with a
> HOWTO for these scripts (or ask someone to do it). Regression hunting
> should only be eas
Janis Johnson wrote:
> On Mon, Apr 16, 2007 at 06:36:07PM +0200, Steven Bosscher wrote:
>> * Very few people know how to use Janis' scripts, so to encourage
>> people to use them, the release manager could write a wiki page with a
>> HOWTO for these scripts (or ask someone to do it). Regression hu
> "ChJ" == Christian Joensson <[EMAIL PROTECTED]> writes:
ChJ> In file included from
../../../gcc/libjava/classpath/native/fdlibm/fdlibm.h:29,
ChJ> from ../../../gcc/libjava/java/lang/natVMDouble.cc:27:
ChJ> ../../../gcc/libjava/classpath/native/fdlibm/mprec.h:297:1: error:
C
On Mon, Apr 16, 2007 at 10:58:13AM -0700, Mark Mitchell wrote:
> Janis Johnson wrote:
> > On Mon, Apr 16, 2007 at 06:36:07PM +0200, Steven Bosscher wrote:
> >> * Very few people know how to use Janis' scripts, so to encourage
> >> people to use them, the release manager could write a wiki page with
Janis Johnson wrote:
>>> The RM can encourage me to do this; I've already been meaning to for a
>>> long time now.
>> You may certainly consider yourself encouraged. :-)
>
> Gosh, thanks!
:-)
> I have IBM permission to contribute them to GCC. An earlier version for
> CVS is in contrib/reghunt
On 16 April 2007 18:49, [EMAIL PROTECTED] wrote:
>> "ChJ" == Christian Joensson <[EMAIL PROTECTED]> writes:
>
> ChJ> In file included from
> ../../../gcc/libjava/classpath/native/fdlibm/fdlibm.h:29, ChJ>
> from ../../../gcc/libjava/java/lang/natVMDouble.cc:27:
> ChJ> ../../../gc
> "Janis" == Janis Johnson <[EMAIL PROTECTED]> writes:
>> * Very few people know how to use Janis' scripts, so to encourage
>> people to use them, the release manager could write a wiki page with a
>> HOWTO for these scripts (or ask someone to do it). Regression hunting
>> should only be easi
> "Ian" == Ian Lance Taylor <[EMAIL PROTECTED]> writes:
>> "Paulo J. Matos" <[EMAIL PROTECTED]> writes:
>> Is that any reference (paper, guide, whatever,) on how gcc is handling
>> exceptions in intermediate code? Is it based on a known (published)
>> method? Is it intuitive and explained some
> "Steven" == Steven Bosscher <[EMAIL PROTECTED]> writes:
Steven> * Maintainers of certain areas of the compiler may not be
Steven> sufficiently aware of some bug in their part of the
Steven> compiler. For example, only one of the three preprocessor bugs
Steven> is assigned to a preprocessor m
On 4/16/07, Janis Johnson <[EMAIL PROTECTED]> wrote:
I'd like at least two volunteers to help me with this cleanup and
documentation effort by using my current scripts on regressions for
open PRs and finding the places that are specific to my environment.
Since I brought this up, I guess I'm on
On Mon, 16 Apr 2007, Tom Tromey wrote:
> Long term I'd like us to go a step further and use documentation
> comments in the source, and extract those into the manual.
This will need FSF approval first for copying text between GPL code and
GFDL manuals, and FSF instructions on what wording to put
Hi!
It's a pity that the application process has finished for some days... I
was very motivated and have really good skills regarding efficient
algorithms, complexity theory and compiler construction, but with not
being accepted I would not have enough time for working on GCC since I
have to
30786 is ICE-on-invalid. 30805 is ICE-on-unspecified.
I don't like ICEs but these don't seem like release-blockers to me.
Anyway I attached prototype patches for these. I don't have resources
to test them for three weeks, so if anybody can beat me to it...
Paolo
Tom Tromey wrote:
> That is new to me, but then I don't build on Cygwin.
> Where does /usr/include/_ansi.h come from?
>
> Anyway, try adding a "#undef _EXFUN" in the appropriate place in
> mprec.h. If that works for you, send it to me and I will check it in.
Are you sure forcibly redefining _EXF
On 16 April 2007 20:49, Charles Wilson wrote:
> Or , should libjava avoid the reserved name '_EXFUN' for its
> macro, and use some other macro for this purpose?
The definition of _EXFUN in mprec.h is unconditionally:
#define _EXFUN(name, proto) name proto
This looks like some
We're a bit "short" on the current CompileFarm machines,
we have 5x16GB + 4x32GB (and as shown below it tends to
be used, I have to ping users from time to time to get GB
back :).
There is enough cpu power in the farm to build and check a version for
each commit (all languages including Ada) on up
Dennis Weyland <[EMAIL PROTECTED]> writes:
> It's a pity that the application process has finished for some
> days... I was very motivated and have really good skills regarding
> efficient algorithms, complexity theory and compiler construction, but
> with not being accepted I would not have enoug
Snapshot gcc-4.1-20070416 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070416/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Hi!
That means GOOGLE did not approve my application? I thought it was GCC.
How can I get to know why they did not approve me? As far as i know, the
mentors can select which projects they want and which not, and not
google itsel. but it seems that i was wrong.
Well, I already completed one SoC s
> "Dave" == Dave Korn <[EMAIL PROTECTED]> writes:
Dave> The definition of _EXFUN in mprec.h is unconditionally:
Dave> #define _EXFUN(name, proto) name proto
libjava, and subsequently Classpath, imported an old version of this
code, which was then hacked over randomly.
Dave> How
[ I sent this reply before I realized that Dennis also send the note
to [EMAIL PROTECTED] Dennis, sorry for the repeat. ]
Dennis Weyland <[EMAIL PROTECTED]> writes:
> That means GOOGLE did not approve my application? I thought it was
> GCC. How can I get to know why they did not approve me? As
I've been converting the Blackfin port to take advantage of the new
lower-subreg pass, which fortunately involves little more than deleting
a few patterns.
One problem is that without an anddi3 expander, we generate poor initial
RTL. optabs knows it can do the operation piecewise, so it could
I suppose we could add a target macro to let individual ports turn off
REG_NO_CONFLICT generation? Any other ideas?
A pass to reorder insns so that live ranges are shortened and register
pressure is relieved.
Could be something like
for each bb
for each insn
for each active insn
I was a little bit disappointed that the first reply on this newsgroup
took so long. I just wanted to know which problems can be tackled and
completed in the SoC timeframe...
And i wonder why i only got 2 responses in the last two weeks in
contrast with todays conversation with more than 2 respons
Bernd Schmidt <[EMAIL PROTECTED]> writes:
> It would be nice to eliminate REG_NO_CONFLICT altogether, but a quick
> experiment with the i386 port showed that this idea is a non-starter
> for now (i386 still has insns operating on DImode, hence in some
> functions not all DImode registers get lower
On 4/16/07, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> I suppose we could add a target macro to let individual ports turn off
> REG_NO_CONFLICT generation? Any other ideas?
A pass to reorder insns so that live ranges are shortened and register
pressure is relieved.
I think Daniel Berlin had
Paolo Bonzini <[EMAIL PROTECTED]> writes:
> > I suppose we could add a target macro to let individual ports turn
> > off REG_NO_CONFLICT generation? Any other ideas?
>
> A pass to reorder insns so that live ranges are shortened and register
> pressure is relieved.
I think you could do this with
Dennis Weyland <[EMAIL PROTECTED]> writes:
> I was a little bit disappointed that the first reply on this newsgroup
> took so long. I just wanted to know which problems can be tackled and
> completed in the SoC timeframe...
> And i wonder why i only got 2 responses in the last two weeks in
> contr
Dennis Weyland <[EMAIL PROTECTED]> writes:
> I was a little bit disappointed that the first reply on this newsgroup
> took so long. I just wanted to know which problems can be tackled and
> completed in the SoC timeframe...
> And i wonder why i only got 2 responses in the last two weeks in
> contr
Ian Lance Taylor wrote:
Paolo Bonzini <[EMAIL PROTECTED]> writes:
I suppose we could add a target macro to let individual ports turn
off REG_NO_CONFLICT generation? Any other ideas?
A pass to reorder insns so that live ranges are shortened and register
pressure is relieved.
I think you coul
Steven Bosscher wrote:
On 4/16/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
29841 [4.2/4.3 regression] ICE with scheduling and __builtin_trap
Honza, PING!
There is a patch for this PR29841 in
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01134.html . The problem
is that I don't really know
On 4/17/07, Maxim Kuvyrkov <[EMAIL PROTECTED]> wrote:
There is a patch for this PR29841 in
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01134.html . The problem
is that I don't really know which maintainer ask to review it :(
I think this patch needs re-testing (because of my cfglayout changes
79 matches
Mail list logo
