On 10 July 2010 15:52, Alexandre Oliva wrote:
> for reasons as yet undetermined, GNU
> ld in Fedora 13 fails to link with libgmpxx, unless libstdc++ and libm
> are linked in explicitly. This is inconvenient, but not such a big
> deal.
Isn't that because of
http://docs.fedoraproject.org/en-US/Fedo
Todd,
On Wed, 19 May 2010, Todd Rinaldo wrote:
> I'm writing to report a discrepancy in
> http://gcc.gnu.org/install/prerequisites.html
>
> I just discovered that if gmp is boot strapped during gcc build and an
> older m4 exists, when gmp calls flex, it will fail during configure
> with:
>
>
Snapshot gcc-4.6-20100710 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20100710/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
John Smith writes:
> Im working on a C source level debugger. The debug info available in elf
> format. How could be 'step over' implemented?
> The problem is at 'Point1', anyway I can wait for the
> next source line (reading it from the .debug_line table).
>
> Thanks
>
>
> ...
> if (a == 1)
> x
Maxiwell Garcia writes:
> I am writing a paper about instruction-set architecture simulators. In
> first time, I used gcc-4.4.0 and the compilation time reached 33
> minutes (with -O3) for my simulator and the performance reached 270
> MIPS (Million instruction per second). When I used the gcc-4.
Sean Hunt writes:
> void foo () __attribute__((noreturn)); // right per spec
> void foo __attribute__((noreturn)) (); // works
> __attribute__((noreturn)) void foo (); // works
>
> It's obvious that the first example of each kind (noreturn appearing
> after the function declarator) mu
Jérémie Salvucci writes:
> I am trying to get an access to local variables of a function thanks
> to the GIMPLE representation. When I read the dump file after the CFG
> pass, I can see a new temporary variable added. For example with the
> identity function I would like to get an access to the u
On 07/10/2010 10:01 PM, Gerald Pfeifer wrote:
On Sat, 10 Jul 2010, Steven Bosscher wrote:
Well, let me add one short comment then. I'd say hppa2-hpux is still
much more relevant than ia64-hpux -- at least, everywhere I'm looking
i.e. workstations. It may be different in the server market.
Anywa
On Sat, 10 Jul 2010, Steven Bosscher wrote:
> Well, let me add one short comment then. I'd say hppa2-hpux is still
> much more relevant than ia64-hpux -- at least, everywhere I'm looking
> i.e. workstations. It may be different in the server market.
>
> Anyway, when I look at posted gcc-testresult
On Sat, Jul 10, 2010 at 9:36 PM, Gerald Pfeifer wrote:
> On Mon, 7 Jun 2010, Paolo Bonzini wrote:
>> From http://gcc.gnu.org/ml/gcc/2009-09/msg00501.html:
>>> It was also suggested to change hppa2.0w-hp-hpux11.11
>>> to ia64-hpux and to change s390-linux-gnu to s390x-linux-gnu in the
>>> list of s
On Mon, 7 Jun 2010, Paolo Bonzini wrote:
> From http://gcc.gnu.org/ml/gcc/2009-09/msg00501.html:
>> It was also suggested to change hppa2.0w-hp-hpux11.11
>> to ia64-hpux and to change s390-linux-gnu to s390x-linux-gnu in the
>> list of secondary targets.
> Shall we proceed?
I'd say "Yes", and I di
On Wed, 12 May 2010, Michael Eager wrote:
> Could someone please review these patches?
>
> Add support for Xilinx MicroBlaze processor:
>
> http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01903.html
This is okay with three small changes.
Please use "Do not" instead of "Don't" in invoke.texi.
Use
Hi,
Im working on a C source level debugger. The debug info available in elf
format. How could be 'step over' implemented?
The problem is at 'Point1', anyway I can wait for the
next source line (reading it from the .debug_line table).
Thanks
...
if (a == 1)
x = 1; //Point1
else if (a == 2)
x
On Sat, Jul 10, 2010 at 03:11:51AM -0400, Joern Rennecke wrote:
> Quoting Jack Howarth :
>
>> Also, I don't seem able to suppress this build failure with...
>
> I think fcode should be assigned some value in the default case instead.
>
>> Is that expected behavior in current gcc trunk?
>
> Strange,
I envision a serious problem for C++ builds of GCC. The next 3
paragraphs provide some context on how I came across it, but are not
critical to understand it, so feel free to skip.
For the past several hours, I've been trying to get the GCC build
machinery to come to terms with gmp in the build t
Quoting Jack Howarth :
Also, I don't seem able to suppress this build failure with...
I think fcode should be assigned some value in the default case instead.
Is that expected behavior in current gcc trunk?
Strange, I just bootstrapped r162030 with a small unrelated change on gcc16
(x86_64
16 matches
Mail list logo
