> 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
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
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
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.
> 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 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
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 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
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 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.
>
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
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
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.)
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/
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
> ../../../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
> 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
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}
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;
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
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
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
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
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
> >> 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
> 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
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
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
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
On Thu, Nov 17, 2005 at 01:11:08PM +0100, Unruh, Erwin wrote:
> So my question: is there some equivalent.
A builtin function.
r~
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:
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
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
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
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
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
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
* 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,
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
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
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
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
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 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
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
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
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
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: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
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
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
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
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
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
> 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
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
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~
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
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
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
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
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
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
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
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
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
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
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
68 matches
Mail list logo
