On 20 September 2014 00:52, Ian Grant wrote:
> None of this is useful to me. I'm trying to make a case for why people
> should have confidence in GNU software. You are NOT helping me in
> that, I assure you,
You seem to have already made up your mind it's GNU crap.
Being insulting is a funny way
On Sat, Sep 20, 2014 at 08:33:01AM +0100, Andrew Haley wrote:
> On 20/09/14 02:45, Ian Grant wrote:
>
> > You get first prize for most informative intelligent answer so far!
> > Careful, you might get second prize too :-)
> >
> > The problem is that we need to find a way to tell people _what_ is
On 20/09/14 02:45, Ian Grant wrote:
> You get first prize for most informative intelligent answer so far!
> Careful, you might get second prize too :-)
>
> The problem is that we need to find a way to tell people _what_ is in
> that "dwarf" code. Open BSD's gcc ignores it, prints a warning, and
>
Thanks Andrew!
You get first prize for most informative intelligent answer so far!
Careful, you might get second prize too :-)
The problem is that we need to find a way to tell people _what_ is in
that "dwarf" code. Open BSD's gcc ignores it, prints a warning, and
goes about its business. That's
On Fri, Sep 19, 2014 at 4:52 PM, Ian Grant wrote:
> None of this is useful to me. I'm trying to make a case for why people
> should have confidence in GNU software. You are NOT helping me in
> that, I assure you,
Again, try stripping out debugging information and look at the numbers
again. Or be
None of this is useful to me. I'm trying to make a case for why people
should have confidence in GNU software. You are NOT helping me in
that, I assure you,
We need to publish some simple steps that people can take to reassure
themselves that the 64MB binaries that GCC 4.9 produces on Linux
system
On 20 September 2014 00:01, Jonathan Wakely wrote:
> On 19 September 2014 16:21, Ian Grant wrote:
>> Thanks. But I asked what the non-vanilla sources were. I know what
>> the vanilla sources are, because I'm using them!
>
> The non-vanilla sources are everything else. That should be pretty obvious
On 19 September 2014 16:21, Ian Grant wrote:
> Thanks. But I asked what the non-vanilla sources were. I know what
> the vanilla sources are, because I'm using them!
The non-vanilla sources are everything else. That should be pretty obvious.
Are you just intentionally trying to waste everyone's t
On Thu, Sep 18, 2014 at 10:35 PM, Thomas Preud'homme
wrote:
>> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
>> Ian Grant
>>
>> And can anyone tell me what are the 'non-vanilla' sources?
>
> "Vanilla source" refers to unmodified source (as distributed on gcc.gnu.org
> for
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Ian Grant
>
> And can anyone tell me what are the 'non-vanilla' sources?
"Vanilla source" refers to unmodified source (as distributed on gcc.gnu.org for
the case of gcc). This is in contrast to modified source from distr
On Thu, Sep 18, 2014 at 9:37 PM, Joe Buck wrote:
> (delurking)
> Ah, this is commonly called the Thompson hack, since Ken Thompson
> actually produced a successful demo:
How do you know Thompson's attempt was the first instance? The
document I refer to in the blog is the "Unknown Air Force Repor
(delurking)
Ian Grant writes:
> In case it isn't obvious, what I am interested in is how easily we can know
> the problem of infeasibly large binaries isn't an instance of this one:
>
> http://livelogic.blogspot.com/2014/08/beware-insiduous-penetrator-my-son.html
Ah, this is commonly calle
In case it isn't obvious, what I am interested in is how easily we can
know the problem of infeasibly large binaries isn't an instance of
this one:
http://livelogic.blogspot.com/2014/08/beware-insiduous-penetrator-my-son.html
Ian
On Thu, Sep 18, 2014 at 8:32 PM, Jonathan Wakely wrote:
>> ian3@jaguar:~/usr/libexec/gcc$ size i686-pc-linux-gnu/4.9.0/{cc1,f951}
>>text databssdechexfilename
>> 14965183 23708 74494415733835 f0144b
>> i686-pc-linux-gnu/4.9.0/cc1
>> 15882830
On 19 September 2014 00:07, Ian Grant wrote:
>
> Actually, when I look at the output of size I realise I don't know
> what it means:
>
> ian3@jaguar:~/usr/libexec/gcc$ size i686-pc-linux-gnu/4.9.0/{cc1,f951}
>text databssdechexfilename
> 14965183 23708
On Thu, Sep 18, 2014 at 6:54 PM, Jonathan Wakely wrote:
> On 18 September 2014 23:46, Ian Grant wrote:
>> On Thu, Sep 18, 2014 at 5:22 PM, Tobias Ulmer wrote:
> Have you compared the binaries using size(1) instead of ls(1)?
Actually, when I look at the output of size I realise I don't know
what
On Thu, Sep 18, 2014 at 6:54 PM, Jonathan Wakely wrote:
> On 18 September 2014 23:46, Ian Grant wrote:
>> On Thu, Sep 18, 2014 at 5:22 PM, Tobias Ulmer wrote:
>>> On Wed, Sep 17, 2014 at 01:26:48PM -0400, Ian Grant wrote:
I can compile the first stage OK, and the binaries are quite modest:
>
On 18 September 2014 23:46, Ian Grant wrote:
> On Thu, Sep 18, 2014 at 5:22 PM, Tobias Ulmer wrote:
>> On Wed, Sep 17, 2014 at 01:26:48PM -0400, Ian Grant wrote:
>>> I can compile the first stage OK, and the binaries are quite modest:
>>>
>>> -rwxr-xr-x 1 ian ian 17.2M Sep 6 03:47 prev-gcc/cc1
On Thu, Sep 18, 2014 at 5:22 PM, Tobias Ulmer wrote:
> On Wed, Sep 17, 2014 at 01:26:48PM -0400, Ian Grant wrote:
>> I can compile the first stage OK, and the binaries are quite modest:
>>
>> -rwxr-xr-x 1 ian ian 17.2M Sep 6 03:47 prev-gcc/cc1
>> -rwxr-xr-x 1 ian ian 1.2M Sep 6 04:24 prev
On Thu, Sep 18, 2014 at 5:37 PM, Ian Grant wrote:
>
> On Thu, Sep 18, 2014 at 5:22 PM, Tobias Ulmer wrote:
>>
>> On Wed, Sep 17, 2014 at 01:26:48PM -0400, Ian Grant wrote:
>> > The reason I'm doing this is that I want to understand why the total
>> > size of the binaries grew from around 10MB (gc
On Wed, Sep 17, 2014 at 01:26:48PM -0400, Ian Grant wrote:
> The reason I'm doing this is that I want to understand why the total
> size of the binaries grew from around 10MB (gcc v 4.5) to over 70MB in
> 4.9
>
> I can compile the first stage OK, and the binaries are quite modest:
>
> -rwxr-xr-x
On Wed, Sep 17, 2014 at 2:59 PM, Marc Glisse wrote:
>>> Please don't call it "the Intel library", that doesn't mean anything.
>> Doesn't it? How did you know what 'it' was then? Or is that a stupid
>> question? This identity concept is much slipperier than it seems at
>> first, isn't it?
> You in
On Wed, 17 Sep 2014, Ian Grant wrote:
On Wed, Sep 17, 2014 at 1:36 PM, Marc Glisse wrote:
On Wed, 17 Sep 2014, Ian Grant wrote:
And is there any way to disable the Intel library?
--disable-libcilkrts (same as the other libs)
If it explicitly doesn't support your system, I am a bit surpris
On Wed, Sep 17, 2014 at 1:36 PM, Marc Glisse wrote:
> On Wed, 17 Sep 2014, Ian Grant wrote:
>
>> And is there any way to disable the Intel library?
> --disable-libcilkrts (same as the other libs)
> If it explicitly doesn't support your system, I am a bit surprised it isn't
> disabled automaticall
On Wed, 17 Sep 2014, Ian Grant wrote:
And is there any way to disable the Intel library?
--disable-libcilkrts (same as the other libs)
If it explicitly doesn't support your system, I am a bit surprised it
isn't disabled automatically, that seems like a bug.
Please don't call it "the Intel l
The reason I'm doing this is that I want to understand why the total
size of the binaries grew from around 10MB (gcc v 4.5) to over 70MB in
4.9
I can compile the first stage OK, and the binaries are quite modest:
-rwxr-xr-x 1 ian ian 17.2M Sep 6 03:47 prev-gcc/cc1
-rwxr-xr-x 1 ian ian 1.2
The reason I'm doing this is that I want to understand why the total
size of the binaries grew from around 10MB (gcc v 4.5) to over 70MB in
4.9
I can compile the first stage OK, and the binaries are quite modest:
-rwxr-xr-x 1 ian ian 17.2M Sep 6 03:47 prev-gcc/cc1
-rwxr-xr-x 1 ian ian 1.2
27 matches
Mail list logo
