On 09/28/2010 11:09 AM, Kai Tietz wrote:
ChangeLog
2010-09-28 Kai Tietz
* config/i386/cygming.h (ASM_OUTPUT_DWARF_OFFSET): Output
addition zero for padding of secrel32 requested for 8 bytes.
I will apply this today, if there aren't any objections.
Please don't
On 09/28/2010 01:51 AM, Dave Korn wrote:
Huh, am I doing something seriously wrong? It takes me four hours to
boostrap GCC at with all languages enabled at -j8 on an AMD2x64
You must be. I just bootstrapped with c, c++, and java, and it was
real40m36.704s
user164m5.664s
sys
On 09/28/2010 12:35 PM, Dave Korn wrote:
On 28/09/2010 11:44, Andrew Haley wrote:
On 09/28/2010 01:51 AM, Dave Korn wrote:
Huh, am I doing something seriously wrong? It takes me four hours to
boostrap GCC at with all languages enabled at -j8 on an AMD2x64
You must be. I just
On 09/27/2010 01:23 AM, Jay K wrote:
Hi. You know, gmp/mpfr/mpc are a significant
portion of building any frontend/backend.
I disagree. Most of the time I don't notice them.
The result is a lot faster to build, if you are just doing a just
a single stage build of a compiler.
Sure, but if
On 09/27/2010 10:36 AM, Luke A. Guest wrote:
On Mon, 2010-09-27 at 11:12 +0200, Olivier Hainque wrote:
Hello Luke,
Luke A. Guest wrote:
I'm having a look into getting DWARF2 exceptions (ZCX) working on ARM.
Thanks :-)
Well, I'm reading as much as I can regarding this, but finding it
On 11/09/10 20:28, Steven Bosscher wrote:
On Sat, Sep 11, 2010 at 8:48 PM, Andrew Haley a...@redhat.com wrote:
On 09/10/2010 11:50 PM, Steven Bosscher wrote:
There is just one front-end file left that still has to #undef
IN_GCC_FRONTEND, allowing the front end to include RTL headers. The
one
On 11/09/10 21:21, Joseph S. Myers wrote:
On Sat, 11 Sep 2010, Andrew Haley wrote:
The test tells us whether the back-end has atomic builtins. If it doesn't
then we generate calls to the libgcj back end. I really don't want gcj
to generate calls to nonexistent __compare_and_swap_4
On 09/10/2010 11:50 PM, Steven Bosscher wrote:
There is just one front-end file left that still has to #undef
IN_GCC_FRONTEND, allowing the front end to include RTL headers. The
one remaining file is java/builtins.c.
In java/builtins.c there are (what appear to be) functions that
generate
On 09/07/2010 02:12 PM, Joel wrote:
Hello,
Apparently, at least for MIPS target, GCC generates labels starting
from 2: $L2, $L3, etc.
Do you know why the numbering begins at 2?
When I saw this question before, I thought that it'd be easy to find
out by debugging gcc. However, I also thought
On 09/06/2010 06:18 PM, NightStrike wrote:
On Mon, Sep 6, 2010 at 12:21 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Mon, Sep 6, 2010 at 6:19 PM, NightStrike nightstr...@gmail.com wrote:
On Mon, Sep 6, 2010 at 5:21 AM, Richard Guenther rguent...@suse.de wrote:
On Mon, 6 Sep 2010,
On 08/30/2010 03:50 PM, Vincent Lefevre wrote:
On 2010-08-30 14:46:57 +0200, Michael Matz wrote:
int x = x;
is the way GCC offers this idiom since about forever, no need for an
attribute. Downthread I see that people worry about this generating an
actual (uninitialized) access to x. They
[ Redirect to gcc. This is a dev issue. ]
On 08/27/2010 10:39 PM, Tom Browder wrote:
On Fri, Aug 27, 2010 at 09:17, Andrew Haley a...@redhat.com wrote:
However, just running download_prerequisites is, IMVHO, the only sane way
to do it.
That's the solution I used, and I got a good build
On 08/21/2010 10:43 AM, Florian Weimer wrote:
* H. J. Lu:
Sometime I have to do
int x = 0;
to silence gcc from uninitialized warnings when I know it is
unnecessary.
I guess the official idiom is
int x = x;
and it is somewhat used in the GNU project although it is not
portable.
On 06/29/2010 06:53 AM, Kevin Bowling wrote:
In the GCC 4.5 announcement:
Support for the classic POWER architecture implemented in the
original RIOS and RIOS2 processors of the old IBM RS/6000 product line
has been obsoleted in the rs6000 port. This does not affect the new
generation Power
On 06/03/2010 09:47 PM, Robert Dewar wrote:
Andrew Haley wrote:
Right, but I didn't think there was any plan to convert en masse to
C++ -- just to allow people to use it where appropriate. Apart from
anything else, there's always a nonzero probablility of breaking
something.
It's
On 06/02/2010 09:19 PM, DJ Delorie wrote:
Robert Dewar de...@adacore.com writes:
I would create a specific committee to reccommend a C++ coding
standard (preferably based on one of the standard ones available, such
as Google).
Doing things in secret like that is not the Open Source Way.
On 06/03/2010 12:09 PM, Richard Guenther wrote:
On Thu, Jun 3, 2010 at 12:51 PM, Robert Dewar de...@adacore.com wrote:
Steven Bosscher wrote:
Indeed. It is, well, perhaps not surprising, but quite annoying (to me
at least) that a possible move to C++ as implementation language of
GCC is so
On 05/18/2010 04:24 AM, Sandeep Soni wrote:
On Tue, May 18, 2010 at 2:34 AM, Andrew Haley a...@redhat.com wrote:
For example:
A textual GIMPLE tuple for the statement a=b+c can be like
GIMPLE_ASSIGNPLUS_EXPR,a,b,c (As demonstrated by the internal
manual also
On 05/18/2010 04:05 PM, Dave Korn wrote:
On 18/05/2010 15:17, Steven Bosscher wrote:
IMHO, ideally we would have a syntax that is human readable and human
writable. S-expressions are not as easy to read for me as something
that resembles C.
I'd like it that way too, but I acknowledge
On 05/17/2010 09:15 PM, Sandeep Soni wrote:
Hi,
As part of GSoC 2010, I am developing a front end for GIMPLE.
You can find the basic theme of the project at:
http://gcc.gnu.org/wiki/GimpleFrontEnd
One of the most important components in this GIMPLE Front End is to
convert the GIMPLE
On 04/25/2010 06:05 PM, Steven Bosscher wrote:
On Sun, Apr 25, 2010 at 6:48 PM, Michael Witten mfwit...@gmail.com wrote:
On Sun, Apr 25, 2010 at 11:33, Richard Kenner
If I submit a patch to the GCC project---necessitating an assignment
of the copyright to the FSF---then can the people of the
On 04/21/2010 06:35 PM, Chris Lattner wrote:
On Apr 21, 2010, at 3:32 AM, Tomohiro Matsuyama wrote:
Hi, all
I have been working on implementing a tool-set of code assistance
called GCCSense, which enables code-completion for C/C++ in editors
or a terminal.
On 04/15/2010 12:57 PM, Basile Starynkevitch wrote:
Of course I do know about gcj. But I never met any person using it,
and I don't know about any person or project really using it (as an
example, I am not sure than any Debian or Fedora package is compiled
with gcj into a native executable;
On 04/15/2010 01:07 PM, Steven Bosscher wrote:
On Thu, Apr 15, 2010 at 2:03 PM, Andrew Haley a...@redhat.com wrote:
On 04/15/2010 12:57 PM, Basile Starynkevitch wrote:
Of course I do know about gcj. But I never met any person using it,
and I don't know about any person or project really using
On 04/13/2010 10:45 AM, Richard Guenther wrote:
On Tue, Apr 13, 2010 at 10:55 AM, Bingfeng Mei b...@broadcom.com wrote:
Something like printf (Though I read somewhere glibc extension of printf
make it non-pure).
Surely printf writes to global memory (it clobbers the stdout FILE*)
I suppose
On 04/12/2010 05:27 PM, Bingfeng Mei wrote:
Hello,
One of our engineers requested a feature so that
compiler can avoid to re-load variables after a function
call if it is known not to write to memory. It should
slash considerable code size in our applications. I found
the existing pure and
On 04/12/2010 07:22 PM, Dave Korn wrote:
On 12/04/2010 17:33, Andrew Haley wrote:
On 04/12/2010 05:27 PM, Bingfeng Mei wrote:
Hello,
One of our engineers requested a feature so that
compiler can avoid to re-load variables after a function
call if it is known not to write to memory. It should
On 28/03/10 15:45, Carrot Wei wrote:
Hi
The detailed description of the optimization is at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43129. This is an ARM
specific optimization.
This optimization uses one less register (the register hold the GOT
base), to get this beneficial the ideal
On 03/22/2010 12:43 PM, Robert Dewar wrote:
the code for computing the hash has to be taken into account, but
nothing else than actual benchmarks will give an accurate
comparison.
I agree. I'd also like to point out that as it is not very difficult
to do these benchmarks, the proponent(s)
On 03/18/2010 05:22 AM, Jae Hyuk Kwak wrote:
On Wed, Mar 17, 2010 at 1:04 PM, Michael Meissner
meiss...@linux.vnet.ibm.com wrote:
Note, that many hash tables are computed by the modulus operation, which is
often fairly expensive (and on machines without a hardware divide unit,
requiring a
On 03/18/2010 05:22 AM, Jae Hyuk Kwak wrote:
On Wed, Mar 17, 2010 at 1:04 PM, Michael Meissner
meiss...@linux.vnet.ibm.com wrote:
Note, that many hash tables are computed by the modulus operation, which is
often fairly expensive (and on machines without a hardware divide unit,
requiring a
On 03/06/2010 04:43 AM, John Regehr wrote:
The question is, what should C and C++ compilers do with this code?
volatile int x;
void foo (void) {
x;
}
This question is not totally stupid: embedded systems use code like this
when reading a hardware register has a useful side
On 06/03/10 15:54, John Regehr wrote:
I'm not sure this follows. It's stated explicitly that The
expression is evaluated and its value is discarded. How can you
evaluate the expression without reading the volatle?
I'm certainly not an expert on this material but I wouldn't think you'd
On 03/04/2010 07:27 PM, b95705...@ntu.edu.tw wrote:
引述 Andrew Haley a...@redhat.com:
There is no reason in principle this shouldn't be part of gcc.
I think no-one has responded yet because they don't know what it would
be for, and how much work it would involve.
What compiler doing is: c
On 03/03/2010 04:52 AM, b95705...@ntu.edu.tw wrote:
I am highly interestd in implementing C compiler for EFI Byte Code in
gcc and participate in Google Summer Code.
EFI is a much larger, more complex,OS-like replacement for the older BIOS
firmware interface present in all IBM PC-compatible
On 03/03/2010 10:53 AM, Tristan Gingold wrote:
On Mar 3, 2010, at 11:36 AM, Andrew Haley wrote:
On 03/03/2010 04:52 AM, b95705...@ntu.edu.tw wrote:
I am highly interestd in implementing C compiler for EFI Byte Code in
gcc and participate in Google Summer Code.
EFI is a much larger, more
On 03/02/2010 08:55 AM, Alain Ketterlin wrote:
It looks like gcc sometimes produces useless conditional branches.
I've found code like this:
xor%edx,%edx
; code with no effect on edx (see full code below)
test %edx,%edx
jnesomewhere else
The branch on the last line
On 03/02/2010 09:38 AM, Peter Kourzanov wrote:
I have the following variation on Duff's device that seems to
mis-compile on all GCC versions I can access within a minute (that
is gcc-3.{3,4}, gcc-4.{1,2,3,4} on x86 and gcc-4.3.2 on x86_64). The
symptoms are as follows:
$ gcc-4.4 -o
On 03/02/2010 10:34 AM, Pjotr Kourzanov wrote:
int duff4_fails(char * dst,const char * src,const size_t n)
{
const size_t rem=n % 4, a=rem + (!rem)*4;
char * d=dst+=a;
const char * s=src+=a;
/* gcc bug? dst+=n; */
switch (rem) {
case 0: for(dst+=n;ddst;d+=4,s+=4) {
On 02/21/2010 12:13 PM, Richard Guenther wrote:
On Sun, Feb 21, 2010 at 1:06 PM, Geert Bosch bo...@adacore.com wrote:
On Feb 21, 2010, at 06:18, Steven Bosscher wrote:
My point: gcc may fail to attract users (and/or may be losing users)
when it tries to tailor to the needs of minorities.
On 02/22/2010 12:29 AM, Erik Trulsson wrote:
On Sun, Feb 21, 2010 at 11:35:11PM +, Dave Korn wrote:
On 21/02/2010 22:42, Erik Trulsson wrote:
Yes, it does if the user is using binaries compiled by somebody else,
and that somebody else did not explicitly specify any CPU-flags.
I believe
On 02/17/2010 04:50 AM, dib.cool...@gmail.com wrote:
hi...
I am a student of b.sc first yr in comp.science
can you tell me
which parsing technique is used in ANSI c language and in gcc?
A hand-written recursive descent parser. It's in gcc/c-parse.c.
and how the parse tree is
On 01/25/2010 02:42 PM, Erik Trulsson wrote:
On Mon, Jan 25, 2010 at 02:19:04PM +0100, Richard Guenther wrote:
On Mon, Jan 25, 2010 at 1:24 PM, Piotr Wyderski
piotr.wyder...@gmail.com wrote:
I have a hash function hash(T v) overloaded for all integral
types. I want to provide a variant for
On 01/10/2010 10:30 AM, Andreas Schwab wrote:
Dave Korn dave.korn.cyg...@googlemail.com writes:
Is that really right? The type of the pointer (in6-__s6_addr) that we're
casting is unsigned char *, so shouldn't it already alias everything anyway
and dereferencing it be allowed, like it is
On 01/10/2010 12:39 PM, Andreas Schwab wrote:
Andrew Haley a...@redhat.com writes:
Why do you say the effective type is different?
The object type is uint8_t, but accessed as uint32_t. That is
undefined.
Unless uint8_t is a character type, as I understand it. That is
clearly
On 01/10/2010 02:39 PM, Paul Koning wrote:
...
typedef unsigned char uint8_t;
typedef unsigned int uint32_t;
struct in6_addr
{
uint8_t __s6_addr[16];
};
static inline int
address_in_use (unsigned char *a, struct in6_addr *in6)
{
if const uint32_t *)(a))[0]
==
On 01/10/2010 04:58 PM, Patrick Horgan wrote:
Andrew Haley wrote:
On 01/10/2010 12:39 PM, Andreas Schwab wrote:
Andrew Haley a...@redhat.com writes:
Why do you say the effective type is different?
The object type is uint8_t, but accessed as uint32_t. That is
undefined.
Unless
On 01/06/2010 07:24 PM, Joshua Haberman wrote:
In the notes that Nick referenced it says:
Is there anybody that thinks the rules are clear enough? No one is
really able to interpret them. So it seems that they are not
clear enough. The problem is how to state them.
[...]
On 01/07/2010 11:42 AM, Richard Guenther wrote:
On Thu, Jan 7, 2010 at 12:29 PM, Andrew Haley a...@redhat.com wrote:
On 01/06/2010 07:24 PM, Joshua Haberman wrote:
The response I think you may get is that this is already settled.
I've seen this same argument many times (in mailing lists
On 01/06/2010 04:09 AM, Joshua Haberman wrote:
Erik Trulsson ertr1013 at student.uu.se writes:
On Sun, Jan 03, 2010 at 05:46:48AM +, Joshua Haberman wrote:
The aliasing policies that GCC implements seem to be more strict than
what is in the C99 standard. I am wondering if this is true or
On 01/06/2010 09:59 AM, Mark Colby wrote:
Yabbut, how come RTL cse can handle it in x86_64, but PPC not?
Probably because the RTL on x86_64 uses and's and ior's, but PPC uses
set's of zero_extract's (insvsi).
Aha! Yes, that'll probably be it. It should be easy to fix cse to
recognize
On 01/05/2010 01:15 AM, Erik Trulsson wrote:
On Mon, Jan 04, 2010 at 08:17:00PM +, Joshua Haberman wrote:
Andrew Haley aph at redhat.com writes:
On 01/03/2010 10:14 PM, Joshua Haberman wrote:
Andrew Haley aph at redhat.com writes:
6.3.2.3
A pointer to an object or incomplete type may
On 01/05/2010 02:09 AM, Joshua Haberman wrote:
Erik Trulsson ertr1013 at student.uu.se writes:
On Mon, Jan 04, 2010 at 08:17:00PM +, Joshua Haberman wrote:
The text you quoted does not contain any shall not language about
dereferencing, so this conclusion does not follow.
It doesn't have
On 01/05/2010 03:23 PM, Vincent Lefevre wrote:
On 2010-01-05 10:31:13 +, Andrew Haley wrote:
An object shall have its stored value accessed only by an lvalue
expression that has one of the following types:
but
(union u*)i
is not a legal lvalue expression because the dereference
On 01/05/2010 07:58 PM, Joshua Haberman wrote:
Andrew Haley aph at redhat.com writes:
but
(union u*)i
is not a legal lvalue expression because the dereference is undefined
behaviour.
Your example does not contain a dereference.
You may only dereference a pointer as permitted
On 01/05/2010 07:38 PM, Joshua Haberman wrote:
Robert Dewar dewar at adacore.com writes:
In any case the gcc interpretation is clearly what's
intended in my view, so if it can be argued that the
standard is inconsistent with this interpretation (I
am unconvinced that this burden has been
On 01/03/2010 10:14 PM, Joshua Haberman wrote:
Andrew Haley aph at redhat.com writes:
On 01/03/2010 10:53 AM, Richard Guenther wrote:
GCC follows its own documentation here, not some random
websites and maybe not the strict reading of the standard.
GCC is compatible with C99 in this regard
On 01/04/2010 10:51 AM, Mark Colby wrote:
This sounds like a dumb question I know. However the following code
snippet results in many more machine instructions under 4.4.2 than under
2.9.5 (I am running a cygwin-PowerPC cross):
typedef unsigned int U32;
typedef union
{
U32 R;
On 01/04/2010 12:07 PM, Jakub Jelinek wrote:
On Mon, Jan 04, 2010 at 12:18:50PM +0100, Steven Bosscher wrote:
On Mon, Jan 4, 2010 at 12:02 PM, Andrew Haley a...@redhat.com wrote:
This optimization is done by the first RTL cse pass. I can't understand
why it's not being done for your target. I
On 01/04/2010 04:17 PM, Nathan Froyd wrote:
On Mon, Jan 04, 2010 at 04:08:17PM +, Andrew Haley wrote:
On 01/04/2010 12:07 PM, Jakub Jelinek wrote:
IMHO we really should have some late tree pass that converts adjacent
bitfield operations into integral operations on non-bitfields (likely
On 01/03/2010 10:53 AM, Richard Guenther wrote:
GCC follows its own documentation here, not some random
websites and maybe not the strict reading of the standard.
GCC is compatible with C99 in this regard.
Andrew.
On 01/03/2010 12:52 PM, Andreas Schwab wrote:
Florian Weimer f...@deneb.enyo.de writes:
* Joshua Haberman:
To me this allows the following:
int i;
union u { int x; } *pu = (union u*)i;
printf(%d\n, pu-x);
I think the cast on the secodn line is undefined,
Only if union u has
[redir to gcc-help]
On 01/01/2010 05:44 AM, Andris Kalnozols wrote:
If the bug was a basic programming error, one would expect a
runtime failure (dereferencing a NULL pointer) no matter which
compiler was used.
I would not expect that, and I have no idea whay you would. Undefined
behaviour
Jean Christophe Beyler wrote:
Dear all,
Found on http://gmplib.org/.
N.B. gcc 4.3.2 miscompiles GMP 4.3.x on 64-bit machines. The problem
is specific to that very release; specifically gcc 4.3.1 and 4.3.3
seem to work fine.
Since porting to a newer version is difficult for me right
H. Peter Anvin wrote:
On 12/09/2009 06:56 AM, Michael Matz wrote:
Aren't bits in the _Bool byte ofbar specified by the psABI
Right now they are specified in the psABI, you suggested to remove that
specification.
The intent of H.J.'s proposal is to require bits 7:1 == 0 in all cases
(and
H.J. Lu wrote:
On Wed, Dec 9, 2009 at 7:10 AM, Andrew Haley a...@redhat.com wrote:
H. Peter Anvin wrote:
On 12/09/2009 06:56 AM, Michael Matz wrote:
Aren't bits in the _Bool byte ofbar specified by the psABI
Right now they are specified in the psABI, you suggested to remove
Hi,
Michael Matz wrote:
On Wed, 9 Dec 2009, Andrew Haley wrote:
The intent of H.J.'s proposal is to require bits 7:1 == 0 in all cases
(and higher bits as don't cares, the same way a char is passed), as
opposed to the current text which requires 63:1 == 0 when passed as
registers
H.J. Lu wrote:
On Wed, Dec 9, 2009 at 7:51 AM, Andrew Haley a...@redhat.com wrote:
H.J. Lu wrote:
On Wed, Dec 9, 2009 at 7:10 AM, Andrew Haley a...@redhat.com wrote:
H. Peter Anvin wrote:
On 12/09/2009 06:56 AM, Michael Matz wrote:
Aren't bits in the _Bool byte ofbar specified by the psABI
Ehren Metcalfe wrote:
I've recently come across a couple of issues trying to compile Firefox
trunk with 4.5 (I have a very simple plugin that I need to run on
mozilla-central). I've posted two bugs here
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42139 and here
H. Peter Anvin wrote:
On 11/25/2009 08:44 AM, Jakub Jelinek wrote:
If you compile kernels 90%+ people out there run with -p on i?86/x86_64,
then certainly coming up with a new gcc switch and new profiling ABI is
desirable. -p on i?86/x86_64 e.g. forces -fno-omit-frame-pointer, which
makes
Jeff Law wrote:
Ultimately I think there are X issues here.
1. What to do in the immediate term with the repo. I've got no
strong opinions here.
2. What to do longer term. I'd like to see us fix the whitespace
stuff then use hooks or a cron job to make sure they don't come back
yunfeng zhang wrote:
The idea I got is about removing .got section in ELF format totally.
Before we go, let's see the limitation on the idea
1) It must be deployed on aligned segment model, such as Linux, which cs.start
= ds.start.
2) Currently, I only know how to do on x86 ELF.
Here is
H.J. Lu wrote:
On Sun, Nov 22, 2009 at 9:20 AM, Andrew Haley a...@redhat.com wrote:
H.J. Lu wrote:
On Fri, Nov 20, 2009 at 11:35 AM, Andrew Haley a...@redhat.com wrote:
Steven Rostedt wrote:
Ingo, Thomas and Linus,
I know Thomas did a patch to force the -mtune=generic, but just in case
gcc
Jakub Jelinek wrote:
On Tue, Nov 24, 2009 at 03:55:49PM +0100, Thomas Gleixner wrote:
you should compile your code with -maccumulate-outgoing-args, and there's
no need to use -mtune=generic. Is that right?
Seems to work. What other side effects has that ?
Faster code, significant increase
Jakub Jelinek wrote:
On Tue, Nov 24, 2009 at 03:32:20PM +, Andrew Haley wrote:
Jakub Jelinek wrote:
On Tue, Nov 24, 2009 at 03:55:49PM +0100, Thomas Gleixner wrote:
you should compile your code with -maccumulate-outgoing-args, and there's
no need to use -mtune=generic. Is that right
Ross Ridge wrote:
Andrew Haley writes:
Alright. So, it is possible in theory for gcc to generate code that
only uses -maccumulate-outgoing-args when it needs to realign SP.
And, therefore, we could have a nice option for the kernel: one with
(mostly) good code density and never generates
H. Peter Anvin wrote:
On 11/24/2009 07:46 AM, Andrew Haley wrote:
Yes, a lot. The difference is that -maccumulate-outgoing-args allocates
space for arguments of the callee with most arguments in the prologue, using
subtraction from sp, then to pass arguments uses movl XXX, 4(%esp) etc
H.J. Lu wrote:
On Fri, Nov 20, 2009 at 11:35 AM, Andrew Haley a...@redhat.com wrote:
Steven Rostedt wrote:
Ingo, Thomas and Linus,
I know Thomas did a patch to force the -mtune=generic, but just in case
gcc decides to do something crazy again, this patch will catch it.
Should we try to get
Thomas Gleixner wrote:
While testing various kernel configs we found out that the problem
comes and goes. Finally I started to compare the gcc command line
options and after some fiddling it turned out that the following
minimal deltas change the code generator behaviour:
Bad:
Andrew Haley wrote:
Thomas Gleixner wrote:
While testing various kernel configs we found out that the problem
comes and goes. Finally I started to compare the gcc command line
options and after some fiddling it turned out that the following
minimal deltas change the code generator behaviour
Thomas Gleixner wrote:
On Thu, 19 Nov 2009, Thomas Gleixner wrote:
Can the GCC folks please shed some light on this:
standard function start:
push %ebp
mov%esp, %ebp
call mcount
modified function start on a handful of functions only seen
Thomas Gleixner wrote:
On Thu, 19 Nov 2009, Andrew Haley wrote:
Thomas Gleixner wrote:
There is no real obvious reason why the edi magic needs to be done
_before_
push %ebp
mov%esp,%ebp
Sure there is: unless you do the adjustment first %ebp won't be 16-aligned.
And why
Thomas Gleixner wrote:
On Thu, 19 Nov 2009, Thomas Gleixner wrote:
Can the GCC folks please shed some light on this:
standard function start:
push %ebp
mov%esp, %ebp
call mcount
modified function start on a handful of functions only seen
Richard Guenther wrote:
And
you didn't provide us with a testcase either ... so please open
a bugzilla and attach preprocessed source of a file that
shows the problem, note the function it happens in and provide
the command-line options you used for building.
I've got all that off-list. I
Steven Rostedt wrote:
On Thu, 2009-11-19 at 18:20 +, Andrew Haley wrote:
OK, I found it. There is a struct defined as
struct entry {
...
} __attribute__((__aligned__((1 (4);
and then in timer_stats_update_stats you have a local variable of type
struct entry:
void
Mark Cave-Ayland wrote:
So I'm really confused as to how adding a simply function pointer in the
global declaration section (without even adding any code to reference
it) suddenly incurs an extra 40% overhead? Can anyone explain why this
is, and/or point me to any suitable gcc optimisation
Mark Cave-Ayland wrote:
Andrew Haley wrote:
There are a few possibilities, such as changing the alignment of the
data,
but without seeing the code it's hard to say.
It's just a standard checkout from the OpenBIOS SVN with a patch I can
provide to implement the recursive Fibonacci function
Matthias Klose wrote:
On 19.10.2009 19:42, Andrew Haley wrote:
Ian Lance Taylor wrote:
Andrew Haleya...@redhat.com writes:
Matthias Klose wrote:
--enable-plugin is used by classpath (part of libjava) and now by GCC
itself. disabling the build of the gcjwebplugin now disables plugin
Ian Lance Taylor wrote:
Andrew Haley a...@redhat.com writes:
Matthias Klose wrote:
--enable-plugin is used by classpath (part of libjava) and now by GCC
itself. disabling the build of the gcjwebplugin now disables plugin
support in GCC as well. Please could the option for enabling GCC
daniel tian wrote:
2009/9/28 Basile STARYNKEVITCH bas...@starynkevitch.net:
daniel tian wrote:
Thanks.
But how to debug cc1. Because now I port the gcc to my RISC target.
But when build the libgcc2.c. Some error occurred. So i have to debug
it.
Any advice about how to debug?
Start gdb
daniel tian wrote:
/home/daniel.tian/gcc_rice_dev/rice-binutils/build-gcc-debug/./gcc/xgcc
-B/home/daniel.tian/gcc_rice_dev/rice-binutils/build-gcc-debug/./gcc/
-B/usr/local/cross/rice-elf/rice-elf/bin/
-B/usr/local/cross/rice-elf/rice-elf/lib/ -isystem
daniel tian wrote:
2009/9/21 sumanth sumanth.gundapn...@redpinesignals.com:
Hi ,
Follow this wiki http://gcc.gnu.org/wiki/DebuggingGCC; to know how to
debug gcc.
As far as I know compute_frame_pointer_to_fb_displacement is the
displacement between your
frame pointer and the frame
Ian Lance Taylor wrote:
Andrew Haley a...@redhat.com writes:
This seems to be an an old bug that has come back. We're generating
L1210:
jmp *%eax
.L4:
.L5:
...
jmp .L1210
.L1171:
.L1172:
...
jmp .L1210
.L1168:
.L1169
Alex Turjan wrote:
Dear all,
Im writing to you regarding the dead store elimination (dse) which runs after
register allocation. Apparently dse removes wrongly the following store
(present in bb2):
(insn 374 47 52 2 test.c:107 (set (mem/c:SI (plus:PSI (reg/f:PSI 55 ptr15)
This seems to be an an old bug that has come back. We're generating
L1210:
jmp *%eax
.L4:
.L5:
...
jmp .L1210
.L1171:
.L1172:
...
jmp .L1210
.L1168:
.L1169:
...
jmp .L1210
instead of
.L1210:
jmp *%eax
.L4:
Oliver Kellogg wrote:
On Fri, 2009-08-14 at 10:41 +0100, Andrew Haley wrote:
I am stuck here, i.e. I don't know how to find the code
that is
at fault.
Is there some way to trace a pointer entered in
G.free_object_list
back to its origin in the code?
The usual way to find this is to use
okell...@freenet.de wrote:
Working on the GNAT multi-source compile feature
(see http://gcc.gnu.org/ml/gcc/2009-04/msg00380.html),
I am running into crashes in ggc_collect() on compiling
the 2nd file in the compile job.
Following the advice given in
Richard Guenther wrote:
On Thu, 16 Jul 2009, Andrew Haley wrote:
Jan Hubicka wrote:
Running target unix/
FAIL: StackTrace2 output - source compiled test
FAIL: StackTrace2 -findirect-dispatch output - source compiled test
FAIL: StackTrace2 -O3 output - source compiled test
FAIL
Andrew Haley wrote:
Richard Guenther wrote:
On Thu, 16 Jul 2009, Andrew Haley wrote:
Jan Hubicka wrote:
Running target unix/
FAIL: StackTrace2 output - source compiled test
FAIL: StackTrace2 -findirect-dispatch output - source compiled test
FAIL: StackTrace2 -O3 output - source compiled
Andreas Schwab wrote:
Zachary Turner divisorthe...@gmail.com writes:
So if a=5 before a function call, then foo(++a, ++a), might invoke
foo(6, 6), foo(6, 7), or foo(7, 6).
Or even foo(42, 666).
Or demons might fly out of your nose.
Andrew.
501 - 600 of 1166 matches
Mail list logo
