Richard Henderson wrote:
> A solution that comes to mind is to have the front-end add dummy
> TYPE_DECL nodes to the BLOCK_VARS list of the function's outer-most
> BLOCK. If the TYPE_DECL node were marked DECL_ARTIFICIAL and had
> no DECL_NAME, it'd be easy for us to notice that we shouldn't
> a
Richard Henderson wrote:
> On Thu, Nov 17, 2005 at 08:42:19PM -0400, Aldy Hernandez wrote:
>
>>Well, as I mentioned in the PR, macro writers can wrap the whole thing
>>in a statement expression and avoid the warning. Can't we suggest this
>>and keep (almost) everybody happy?
>
> I think so.
FWI
On Thu, Nov 17, 2005 at 11:53:31AM -0500, Andrew MacLeod wrote:
> The document is intended as a starting point and consists mostly of my
> thoughts at the moment. By the time the underlying RTL bits are done, I
> would like it to have evolved to include input from others. The more
> useful comment
On Nov 17, 2005, at 21:33, Dale Johannesen wrote:
When I arrived at Apple around 5 years ago, I was told of some recent
measurements that showed the assembler took around 5% of the time.
Don't know if that's still accurate. Of course the speed of the
assembler
is also relevant, and our stubs a
Andrew MacLeod wrote:
> It must be the season for this sort of thing :-)
I have not yet read the entire document, but I would very much like to
applaud both the goal of improving register allocation, and the spirit
in which you've approached it: in particular, posting a design and
getting comments
Jim Wilson wrote:
Gabriel Dos Reis wrote:
This is the fifth or so message from me, within the last few days,
that gets rejected. What is up?
Hmm, I don't see this in the overseers archive.
Because it is sourceware.org not sourceware.com. I should have noticed
that before I made the same m
On Nov 17, 2005, at 3:09 PM, Robert Dewar wrote:
Richard Earnshaw wrote:
We spend a lot of time printing out the results of compilation as
assembly language, only to have to parse it all again in the
assembler.
I never like arguments which have loaded words like "lot" without
quantification
On Thu, Nov 17, 2005 at 03:42:29PM -0800, Ian Lance Taylor wrote:
> I just tried a simple unoptimized compile. -ftime-report said that
> final took 5% of the time (obviously final does more than formatting),
> and the assembler took 4% of the total user time, and system time took
> 16% of wall clo
Gabriel Dos Reis wrote:
This is the fifth or so message from me, within the last few days,
that gets rejected. What is up?
Hmm, I don't see this in the overseers archive. I don't think it
reached them. Maybe it triggered the spam filter for having too many
capital letters in the subject l
Rafael Ávila de Espíndola wrote:
Thank you very much for showing that the problem was in the comment.
I've checked in a patch to fix the comment typo.
--
Jim Wilson, GNU Tools Support, http://www.specifix.com
On Fri, Nov 18, 2005 at 01:19:14AM +0100, Steven Bosscher wrote:
> BTW the gomp-branch adds 22 (!) new tree codes, just like that,
> for all languages. This is IMHO very unfair to other projects
> in need of extra tree codes.
Yeah, well, I don't see any way around it. We'll have to
solve the bi
On Thu, Nov 17, 2005 at 08:42:19PM -0400, Aldy Hernandez wrote:
> Well, as I mentioned in the PR, macro writers can wrap the whole thing
> in a statement expression and avoid the warning. Can't we suggest this
> and keep (almost) everybody happy?
I think so.
r~
From: "Jim Wilson" <[EMAIL PROTECTED]>
> Paul Albrecht wrote:
> > Is there some reason gcc hasn't been or can't be enhanced to provide output
> > for
> > cross-referencing programs?
>
> FYI, there are a number of tools available for producing
> cross-referencing info. See for instance
> htt
> A stronger case for changing this would be that gcc version
> n-1 didn't warn. As discussed elsewhere, some modicum of
> stability in warnings is desirable from the user's perspective.
> I don't know whether or not this applies in this case.
Well, as I mentioned in the PR, macro writers can wra
Paul Albrecht wrote:
Is there some reason gcc hasn't been or can't be enhanced to provide output for
a cross-referencing
programs?
FYI, there are a number of tools available for producing
cross-referencing info. See for instance
http://www.gnu.org/software/global/links.html
and try look
From: "Robert Dewar" <[EMAIL PROTECTED]>
> Paul Albrecht wrote:
> > Is there some reason gcc hasn't been or can't be enhanced to provide output
> > for a
> > cross-referencing programs?
> >
>
> No reason why it can't be, and the reason it hasn't is that no one has done
> it. Actually strictly
yo
On Thursday 17 November 2005 16:55, Steven Bosscher wrote:
> On Thursday 17 November 2005 16:51, Dorit Naishlos wrote:
> > only thing I can suggest in the context of the vectorizer is to use an
> > extra argument to save a few tree-codes:
>
> I don't think that this is a good idea. If we are going
Hi all,
on PowerPC G4 with MacOS-X 10.3.9 (powerpc-apple-darwin7.9.0 )
build from :
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20040913 (GNAT for Mac OS X build 1650)
with gcc cctools 576
same test with gcc cctools 590.12
$ ../gcc-20051112/con
Robert Dewar <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor wrote:
>
> >>We spend a lot of time printing out the results of compilation as
> >> assembly language, only to have to parse it all again in the
> >> assembler.
>
> I never like arguments which have loaded words like "lot" without
> qua
On Thu, Nov 17, 2005 at 03:18:00PM -0800, Ian Lance Taylor wrote:
> I don't think you should get a warning for not using the return value of a
> function, at least not under -Wunused.
For this, I agree. Except that we're not talking about the
return value of the function directly, we're talking a
Paul Albrecht wrote:
Is there some reason gcc hasn't been or can't be enhanced to provide output for
a cross-referencing
programs?
Paul Albrecht
No reason why it can't be, and the reason it hasn't is that
no one has done it. Actually strictly you don't mean gcc
here, you are referring to part
On Thu, Nov 17, 2005 at 03:00:42PM -0800, Joe Buck wrote:
> As in the example, these cases will usually arise in macros, where under
> some circumstances some computation will be wasted.
Which is no different from f()+1, for which no one is arguing
that the warning we give is incorrect. If you've
Richard Henderson <[EMAIL PROTECTED]> writes:
> On Thu, Nov 17, 2005 at 02:01:56PM -0800, Ian Lance Taylor wrote:
> > We traditionally do not warn about not using the value returned by a
> > function. And I don't see why adding a cast should change that.
> > Intuitively, a cast by itself is not a
Ian Lance Taylor wrote:
We spend a lot of time printing out the results of compilation as
assembly language, only to have to parse it all again in the assembler.
I never like arguments which have loaded words like "lot" without
quantification. Just how long *is* spent in this step, is it real
On Thu, Nov 17, 2005 at 06:08:35PM -0400, Aldy Hernandez wrote:
> On a similar note than PR debug/21391...
>
> In PR23336 we have the same thing happen with enums:
>
> enum something { JTI_PROMOTED_BYTE_TYPE_NODE, etc };
>
> use JTI_PROMOTED_BYTE_TYPE_NODE
>
> JTI_PROMOTED_BYTE_TYPE
Is there some reason gcc hasn't been or can't be enhanced to provide output for
a cross-referencing
programs?
Paul Albrecht
On Thu, Nov 17, 2005 at 02:54:48PM -0800, Richard Henderson wrote:
> On Thu, Nov 17, 2005 at 02:01:56PM -0800, Ian Lance Taylor wrote:
> > We traditionally do not warn about not using the value returned by a
> > function. And I don't see why adding a cast should change that.
> > Intuitively, a cas
On Thu, Nov 17, 2005 at 02:01:56PM -0800, Ian Lance Taylor wrote:
> We traditionally do not warn about not using the value returned by a
> function. And I don't see why adding a cast should change that.
> Intuitively, a cast by itself is not a computation.
In many cases is certainly is -- it's a
Snapshot gcc-4.0-20051117 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20051117/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Thomas Quinot wrote:
* Joel Sherrill <[EMAIL PROTECTED]>, 2005-11-16 :
RTEMS has networking functions but they are not available at this stage
during the build.
I am not sure I understand how this can happen (I am not familiar at all
with the RTEMS build process). If the network functions a
* Joel Sherrill <[EMAIL PROTECTED]>, 2005-11-16 :
> RTEMS has networking functions but they are not available at this stage
> during the build.
I am not sure I understand how this can happen (I am not familiar at all
with the RTEMS build process). If the network functions are available on
RTEMS,
On a similar note than PR debug/21391...
In PR23336 we have the same thing happen with enums:
enum something { JTI_PROMOTED_BYTE_TYPE_NODE, etc };
use JTI_PROMOTED_BYTE_TYPE_NODE
JTI_PROMOTED_BYTE_TYPE_NODE and "something" get pruned even though we
use it. I see two alternative
Aldy Hernandez <[EMAIL PROTECTED]> writes:
> this reduces to:
>
> int f(void);
> void g(void)
> { (unsigned) f(); }
>
> Which was made to deliberately warn by Joseph's patch here:
>
> http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00275.html
>
> I closed the bug as a WONT
Ulrich Weigand <[EMAIL PROTECTED]> writes:
> > Conversely, I don't know much we are going to care about speed here,
> > but I assume that we are going to care a bit. For the linker to
> > determine which files to pull in from an archive, it is going to have
> > to read the symbol tables of all th
Richard Earnshaw <[EMAIL PROTECTED]> writes:
> We spend a lot of time printing out the results of compilation as
> assembly language, only to have to parse it all again in the assembler.
> Given some of the problems this proposal throws up I think we should
> seriously look at bypassing as much o
Hi all,
on PowerPC G4 with MacOS-X 10.3.9 (powerpc-apple-darwin7.9.0 )
build from :
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20040913 (GNAT for Mac OS X build 1650)
with Apple's cctools 525
New 4.0.2 gcc -v output :
Using built-in specs.
Ta
Hi folks.
In this PR we are emitting a "value computed is not used" warning for the
following code (via some fancy macro expansion in the Linux kernel):
unsigned long t(void);
void apic_write_atomic(unsigned long reg, unsigned int v)
{
((__typeof__(*((volatile un
cedric wrote:
>
> hello, I have a problem when I try to instantiate static members. this code
> works with gcc-3.4.5 but not with gcc-4.0.2 (debian sid).
> here a test case with 3 files :
>
>
> / main.cpp
> #include
> #include "Test.h"
>
> int main(int argc, char **argv)
> {
> std:
On Thu, Nov 17, 2005 at 01:11:08PM +0100, Unruh, Erwin wrote:
> So my question: is there some equivalent.
A builtin function.
r~
On Thu, Nov 17, 2005 at 08:17:07AM +0100, Peter S. Mazinger wrote:
> -fstack-protector-all (all protection) being superset of -fstack-protector
> (random protection) it should also define __SSP__ 1
The IBM patch that I followed did exactly what I implemented.
I see no compelling reason to change
Ok. I've just checked the gcc-4_0-branch but trying to compile with
--with-cpu=ep9312 and --with-fpu=maverick still fails (but this is a different
problem).
I've reported this bug here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24914
It must be the season for this sort of thing :-)
I have been contemplating building a GCC register allocator from scratch
for some time. To that end, I have put together a bit of a document
given a high level overview of the various components I think would
benefit GCC, and a rough description of
> On Wed, Nov 16, 2005 at 02:26:28PM -0800, Mark Mitchell wrote:
> > > http://gcc.gnu.org/projects/lto/lto.pdf
> >
> > Section 4.2
> >
> > What is the rationale for using a stack-based representation rather
> > than a register-based representation? A infinite register based
> > solution
> >> Thanks for woking on this. Any specific reason why using the LLVM
> >> bytecode wasn't taken into account?
> >
> > It was.
> > A large number of alternatives were explored, including CIL, the JVM,
> > LLVM, etc.
> >
> >> It is proven to be stable, high-level enough to
> >> perform any kind of
Mark Mitchell <[EMAIL PROTECTED]> writes:
> http://gcc.gnu.org/projects/lto/lto.pdf
>
> Section 4.2 (Executable Representation) describes the GVM as a stack
> machine, and mentions load, store, duplicate, and swap operations.
> But it also discusses having registers which correspond to GIMPLE
On Thursday 17 November 2005 16:51, Dorit Naishlos wrote:
> only thing I can suggest in the context of the vectorizer is to use an
> extra argument to save a few tree-codes:
I don't think that this is a good idea. If we are going to need
more tree codes, we're just going to have to figure out a w
On Wed, Nov 16, 2005 at 02:26:28PM -0800, Mark Mitchell wrote:
> > http://gcc.gnu.org/projects/lto/lto.pdf
>
> Section 4.2
>
> What is the rationale for using a stack-based representation rather
> than a register-based representation? A infinite register based
> solution would seem to ma
Paul Brook <[EMAIL PROTECTED]> wrote on 11/16/2005 05:03:47 PM:
> On Wednesday 16 November 2005 14:35, Dorit Naishlos wrote:
> > We're going to commit to autovect-branch vectorization support for
> > non-unit-stride accesses.
> > We'd like to suggest a few new tree-codes/optabs in order to exp
Steven Bosscher <[EMAIL PROTECTED]> wrote on 11/16/2005 10:39:24 PM:
> On Wednesday 16 November 2005 15:35, Dorit Naishlos wrote:
> > We'd like to suggest a few new tree-codes/optabs in order to express
the
> > extraction and merging of elements from/to vectors.
>
> Watch out for tree code sta
hello, I have a problem when I try to instantiate static members. this code
works with gcc-3.4.5 but not with gcc-4.0.2 (debian sid).
here a test case with 3 files :
/ main.cpp
#include
#include "Test.h"
int main(int argc, char **argv)
{
std::cout << TestInt::member << std::endl;
On Thursday 17 November 2005 15:20, Hans-Peter Nilsson wrote:
> > From: Paul Brook <[EMAIL PROTECTED]>
> > Date: Thu, 17 Nov 2005 15:12:50 +
> >
> > > ../../../gcc-head-test/libiberty/regex.c:7699 (set (reg:SI 2 %d2)
> > >
> > >(sign_extend:SI (reg:HI 1 %d1 [59]))) 65 {*68k_extendhisi2}
> From: Paul Brook <[EMAIL PROTECTED]>
> Date: Thu, 17 Nov 2005 15:12:50 +
> > ../../../gcc-head-test/libiberty/regex.c:7699 (set (reg:SI 2 %d2)
> >
> >(sign_extend:SI (reg:HI 1 %d1 [59]))) 65 {*68k_extendhisi2} (nil)
> >(nil))
> > ../../../gcc-head-test/lib
> ../../../gcc-head-test/libiberty/regex.c: In function
> 'byte_common_op_match_null_string_p':
>
> ../../../gcc-head-test/libiberty/regex.c:7724: error: insn does not
> satisfy its constraints:
> (insn 158 85 159 8
> ../../../gcc-head-test/libiberty/regex.c:7699 (set
hi,
Daniel Berlin wrote:
I discovered this when deep hacking into the symbol code of GDB a while
ago. Apparently, some people enjoy breakpointing symbols by using the
fully mangled name, which appears (nowadays) mainly in the minsym table.
This sort of hack is often used to work around what
Doing an overnight build of all rtems targets, I can across this
new breakage for m68k-rtems4.7. I last built this target on Nov 3
from the head and it compiled then.
/home/joel/gcc-work/head/b-m68k-rtems4.7/./gcc/xgcc
-B/home/joel/gcc-work/head/b-m68k-rtems4.7/./gcc/ -nostdinc
-B/home/joel/
On Wed, 2005-11-16 at 20:33 -0700, Jeffrey A Law wrote:
> > Our understanding was that the debugger actually uses the symbol table,
> > in addition to the debugging information, in some cases. (This must be
> > true when not running with -g, but I thought it was true in other cases
> > as well.)
OK, here are the details:
first, I have a PDImode pointer and do not want to have general arithmetic on
that. So I invented a special RTL instruction to align a pointer. Within the
va_arg sometimes I need to align the pointer. In 3.3.2 the code snippet in
EXPAND_BUILTIN_VA_ARG looked like
tr
Ian Lance Taylor wrote:
> In section 3.4 (Linker) I have the same comment: for non-GNU targets,
> the native linker is sometimes required, so modifying the linker
> should not be a requirement. And the exact handling of .a files is
> surprisingly target dependent, so while it would be easy to cod
On Thu, 17 Nov 2005, Peter S. Mazinger wrote:
> On Wed, 16 Nov 2005, Richard Henderson wrote:
>
> > On Wed, Nov 16, 2005 at 10:32:45PM +0100, Peter S. Mazinger wrote:
> > > what happens w/ -fstack-protector-all -fstack-protector (in this order) ?
> > > do we have (2) or (1)
> >
> > We have 1.
>
On Thursday 17 November 2005 07:11, Unruh, Erwin wrote:
> Now va_arg has to be transformed to GIMPLE. So my question: is there
> some equivalent.
>
There isn't one. Have you looked at gimplify_va_arg_expr? What is it in
your construct that cannot be expressed in trees? There are several
targe
On Nov 17, 2005 01:11 PM, "Unruh, Erwin"
<[EMAIL PROTECTED]> wrote:
> is there some
> equivalent.
No, there isn't. You are not being very specific about the problem you
are trying to solve. You'll have to tell more before anyone can give
you a more helpful answer.
Gr.
Steven
Hello,
I am working on a private GCC port. Currently I am trying to move it
from 3.3.2
to 4.1.x. I have some strange constructs in the expansion of the va_arg
macro.
In 3.3.2 I used two "unspec" RTL constructs to solve that problem. Now
va_arg
has to be transformed to GIMPLE. So my question: is th
On Thu, 2005-11-17 at 01:27, Mark Mitchell wrote:
> Richard Henderson wrote:
> > In Requirement 4, you say that the function F from input files a.o and
> > b.o should still be named F in the output file. Why is this requirement
> > more than simply having the debug information reflect that both na
> On Thu, 2005-11-17 at 10:23, Dario Massarin wrote:
>
> > I would like to start with this bug report:
> >
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24861
> >
> > Could you give me some hints on where is the problem?
>
> It just happens that I fixed that last night :-)
Wow! Really? So
On Thu, 2005-11-17 at 10:23, Dario Massarin wrote:
> I would like to start with this bug report:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24861
>
> Could you give me some hints on where is the problem?
It just happens that I fixed that last night :-)
R.
Hello everybody
As you may already know the code that supports cirrus arm processors
with maverick crunch floating point unit (-mfpu=maverick), which
is included in gcc 4.x, is nearly complete but, as of now, broken.
So I'm going to spend some time in fixing it, but I'm pretty new
in gcc developm
Daniel Berlin <[EMAIL PROTECTED]> wrote:
>> Thanks for woking on this. Any specific reason why using the LLVM
>> bytecode wasn't taken into account?
>
> It was.
> A large number of alternatives were explored, including CIL, the JVM,
> LLVM, etc.
>
>> It is proven to be stable, high-level enough to
> RTEMS has networking functions but they are not available at this stage
> during the build. You only have the .h files provided with newlib. So
> this patch is needed to make *-rtems compile again. OK to commit?
Please post the corresponding ChangeLog so that this patch can be reviewed
and ap
68 matches
Mail list logo
