David N. Bradley wrote:
I am trying to compile the cactuscode package and can not get past the
error :
Statement order error: declaration after DATA
Somehow the whole is very odd.
a) I tried your program with gfortran 4.1 to 4.8, g95 and g77 - and none
of them prints this error - all comp
On 09/11/2012 04:33 PM, Steve Ellcey wrote:
In some configuration files there is comment that says that the variable
tracking pass should be run after all optimizations which change the order
of instructions and that it requires a valid control flow graph to work.
But my understanding of the del
Quoting Ian Lance Taylor :
On Tue, Sep 11, 2012 at 3:18 PM, Lawrence Crowl wrote:
The contrib/config-list.mk tool appears to be suffering from bitrot.
The make failures for a limited subset of configurations consisted
exclusively of:
cc1: warnings being treated as errors
../../../../gcc/fixin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I am trying to compile the cactuscode package and can not get past the
error :
Statement order error: declaration after DATA
can you point me in the direction of a fix. I included offending file
as an attachment.
Dave
kb9qhd Amateur Radio Serv
On Tue, Sep 11, 2012 at 3:18 PM, Lawrence Crowl wrote:
> The contrib/config-list.mk tool appears to be suffering from bitrot.
> The make failures for a limited subset of configurations consisted
> exclusively of:
>
> cc1: warnings being treated as errors
> ../../../../gcc/fixincludes/server.c: In
I have a question about the the variable tracking and the delay slot passes.
In some configuration files there is comment that says that the variable
tracking pass should be run after all optimizations which change the order
of instructions and that it requires a valid control flow graph to work.
The contrib/config-list.mk tool appears to be suffering from bitrot.
The make failures for a limited subset of configurations consisted
exclusively of:
cc1: warnings being treated as errors
../../../../gcc/fixincludes/server.c: In function 'server_setup':
../../../../gcc/fixincludes/server.c:195:
We do not yet seem to have consensus on a long term plan.
Would it be reasonable to start on short term prepatory work?
In particular, I was think we could do
Add converters and testers.
Change callers to use those.
and maybe
Change callers to use type-safe parameters.
Where those mea
On Tue, Sep 11, 2012 at 11:31 AM, Mohamed Abou Samra
wrote:
> Hi All,
>
> I'm trying to write a small program to check the decimal floating point gcc
> extension but I encountered some problems
>
> The program just converts a _Decimal64 number to double to print it and I
> used the function (do
Hi All,
I'm trying to write a small program to check the decimal floating point gcc
extension but I encountered some problems
The program just converts a _Decimal64 number to double to print it and I used
the function (double __bid_truncdddf (_Decimal64 a) as the gnu online docs show)
#includ
Hi,
On Mon, 10 Sep 2012, Gabriel Dos Reis wrote:
> > You could also do this with an explicit pointer-to-context-struct
> > parameter that's passed around (and that version of the patch I
> > posted), but the class-based approached seems nicer to me.
>
> Are we talking about encapsulation or "l
> Is there any interest in updating the in-tree libtool to something
> newer? This update would allow to use a -fno-fat-lto-objects
> lto-bootstrap target, that should speed up the (lto) build time.
>
> If there is interest, when would be the best date for such an update?
There is definitely an i
Is there any interest in updating the in-tree libtool to something
newer? This update would allow to use a -fno-fat-lto-objects
lto-bootstrap target, that should speed up the (lto) build time.
If there is interest, when would be the best date for such an update?
Thanks.
--
Markus
On Tue, Sep 11, 2012 at 3:10 AM, David Malcolm wrote:
> On Mon, 2012-09-10 at 17:20 +0200, Michael Matz wrote:
>> Hi David,
>>
>> On Mon, 10 Sep 2012, David Malcolm wrote:
>>
>> > Is it possible for you to post your work-in-progress code somewhere?
>>
>> Attached.
>
> Many thanks for posting this!
On 11 September 2012 03:37, Richard Henderson wrote:
> On 09/10/2012 01:41 AM, Zhenqiang Chen wrote:
>> In function maybe_record_trace_start, there is a check:
>>
>> /* We ought to have the same state incoming to a given trace no
>> matter how we arrive at the trace. Anything else
15 matches
Mail list logo