Make distclean can not remove intl/config.cache and fixincludes/config.cache.
The configure commandline I used in GCC building is
../gcc-dfp-cvs-Aung-10/configure --enable-languages=c --enable-shared
--enable-threads=posix --enable-checking --with-system-zlib --enable-__cxa_atexit
-with-cpu=def
Per Abrahamsen wrote:
> A -Weverything that turned on all boolean warnings would be nice. It
> would be useless alone, but nice followed by a lot of
> -Wno-somesillywarning -Wno-anothersillywarning arguments.
I agree. I acknowledge that it would be useless in the general sense (you
couldn't
us
As of now, the GCC 4.0 branch is completely frozen for the GCC 4.0.2
release. The release will be announced as soon as it has had time to
propagate to the various FTP mirror sites.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Hi,
The following code fragment is now causing problems under gcc 4.0.1
Everything is perfect under "gcc version 3.4.3"
Any recommended work-arounds?
= code fragment==
#ifndef __LOC_PV_FACTORY_H__
#define __LOC_PV_FACTORY_H__
line 10 --> #inclu
Paul Eggert writes:
> Would this weaker action pose an undue burden on GCC? My sense from
> the discussion is "no", but I'd like to double-check with the experts
I'd say "no", but I think the experts might see it as posing no burden
at all on GCC. The burden would be on whomever wants to use GCC
Snapshot gcc-3.4-20050920 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20050920/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.4 CVS branch
with the following options: -rgcc-ss-3_4-20050920
You'll
I'm getting a segmentation fault in the GCC build from today's CVS
HEAD. I am building the suite for mingw using a cross compiler from
Linux. This setup was working fine prior to updating to the latest
CVS head today. My old sources, which were working correctly, were
from 9/1/2005. In both cas
reg_used_between_p checks the CALL_INSN_FUNCTION_USAGE of
a CALL_INSN for CLOBBERS. I think it shouldn't; we are interested
in uses, not sets/ clobbers.
Hi,
I am sorry for not specifying all the details. I am hacking gcc 2.95.2 for
ARM to include my own version of register allocator. Currently, I am
supporting only single registers. i.e. No register pairs - No DImode. For
this I am trying to see there are no pseudo registers with DImode. But I
am s
> Peter Steinmetz writes:
Peter> If I see the following on an instruction definition:
Peter> (set_attr "type" "*")
Peter> What does * represent in this context as the value to assign to "type"?
The default value specified when the attr "type" is defined.
David
Quick question on syntax in md files as I'm not finding the documentation
to explain it. If I see the following on an instruction definition:
(set_attr "type" "*")
What does * represent in this context as the value to assign to "type"?
Thanks.
Pete
On Sep 19, 2005, at 10:36 PM, N V Krishna wrote:
When I try to compile something like:
foo(){
int a[] = {1,2};
}
gcc is combining them into a double (DImode) and handling as such.
Is there a switch by which I can direct gcc not to do so? I am
using gcc 2.95.2.
Side note, we aren't g
On Tue, 2005-09-20 at 13:50 -0400, [EMAIL PROTECTED] wrote:
> Does GCC have a function to build a data dependence graph (DDG) across
> multiple basic blocks?
No.
The best we have is create_ddg in ddg.c
Does GCC have a function to build a data dependence graph (DDG) across
multiple basic blocks? I think sched-rgn.c has something similar, but I
was hoping for a more general interface.
Thanks,
Chad
On Sep 19, 2005, at 11:07 PM, Hitha Nambiar wrote:
i am installing gcc-4.0.1 in mandrake (k ) linux.actually i want to
install apache server .for that gcc is neded.when i
i start configuring gcc it is showing a message like
configure:error:no acceptable cc found in $path
sir plz help me to com
On Sep 19, 2005, at 9:15 PM, Richard Henderson wrote:
On Mon, Sep 19, 2005 at 05:33:54PM -0700, Dale Johannesen wrote:
Do you have any constructive suggestions for how the RA might be
fixed,
then?
Short term? No. But I don't see this as a short term problem.
OK. Unfortunately, it is a sh
Tommy Vercetti wrote:
> Fair enough. Still - thou - I would kindly request adding singness warning as
> default in gcc. From security perspective, that's required. I would even
> generate errors on those, if you ask me, but I know this isn't quite normal
> for the rest of world.
Frankly, I ag
On Sep 20, 2005, at 11:09 AM, Andrew Pinski wrote:
On Sep 20, 2005, at 3:01 AM, Dorit Naishlos wrote:
We've had the testcase below in autovect-branch for a while, testing
that
the 3 loops get vectorized. On mainline the third loop now gets
eliminated
by DCE (.t44.dce3). Not sure I understa
On Sep 20, 2005, at 3:01 AM, Dorit Naishlos wrote:
We've had the testcase below in autovect-branch for a while, testing
that
the 3 loops get vectorized. On mainline the third loop now gets
eliminated
by DCE (.t44.dce3). Not sure I understand why... isn't the print loop
enough to keep it alive
On Sep 20, 2005, at 7:47 AM, Christian Joensson wrote:
Well... I just happend to shoot off a test build on cygwin... and it
barfs like this:
anyone else see this or am I just being stupid on my own here?
This is PR 21766.
-- Pinski
Michael Cieslinski wrote:
>Since last week this small program does no longer compile.
>My question are:
>Is this correct or should I file a bug report?
>How is it possible to initialize an iterator to NULL?
>
>
>
A patch was recently submitted specifically to stop this working, as it
shouldn't.
On Tue, 2005-09-20 at 15:44 +0200, Giovanni Bajo wrote:
> Daniel Berlin <[EMAIL PROTECTED]> wrote:
>
> > For example, Kenny and I discovered during his prespilling work that the
> > liveness is actually calculated wrong.
> >
> > It's half-forwards (local), half-backwards (globally), instead of all
Since last week this small program does no longer compile.
My question are:
Is this correct or should I file a bug report?
How is it possible to initialize an iterator to NULL?
Michael Cieslinski
#include
struct S { int x; };
std::list::iterator IT;
void Init()
{
IT = NULL;
}
g++
Daniel Berlin <[EMAIL PROTECTED]> wrote:
> For example, Kenny and I discovered during his prespilling work that the
> liveness is actually calculated wrong.
>
> It's half-forwards (local), half-backwards (globally), instead of all
> backwards, which is how liveness is normally calculated, so we
>
Well... I just happend to shoot off a test build on cygwin... and it
barfs like this:
if [ x"" != x ]; then \
/usr/local/src/trunk/objdir/./gcc/xgcc
-B/usr/local/src/trunk/objdir/./gcc/ -B/usr/local/i686-pc-cygwin/bin/
-B/usr/local/i686-pc-cygwin/lib/ -isystem
/usr/local/i686-pc-cygwin/include -
Original Message
>From: patriciak784-gccmainling
>Sent: 20 September 2005 12:15
> On x86 and GCC 3.4.2, the resulting asm code when
> leaving a stackframe is (in intel_syntax)
> mov esp,ebp
> pop ebp
> .(results in 0x89EC5D or 0x8BE55D)
> The AMD optimisation guide for AMD64 tells you not
On x86 and GCC 3.4.2, the resulting asm code when
leaving a stackframe is (in intel_syntax)
mov esp,ebp
pop ebp
.(results in 0x89EC5D or 0x8BE55D)
The AMD optimisation guide for AMD64 tells you not to
use mov esp, ebp - pop ebp but to use "leave"(just
0xC9)!
Perhaps using "enter x(16bit), imm8" is
So basically, pick a problem you see, and fix it.
The RTL infrastructure is exceptionally good at doing some things, and
exceptionally bad at doing some others. Sometimes, take into account
the coding style and it is good and bad at the same time. :-( CSE,
flow, etc. come to mind.
All
28 matches
Mail list logo