After looking on the internet on the term "dumping core" I noticed that
one had to write a piece of code to cause the crash.
I noted that one had to know what to do to cause the crash to get the
dump and gathered that while computer scientists and most engineers know
how to do this, it is not so ob
> Simply building in a small standardized intrinsic function name to a
> common crash function that computer scientists might write to cause
> a core dump would make the compiler more user friendly to the non
> computer science crowd.
I'm confused. Why isn't "abort" the function that you want?
Aspertame Man writes:
> After looking on the internet on the term "dumping core" I noticed that
> one had to write a piece of code to cause the crash.
Try looking for gcore.
Andreas.
--
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E
I am writing a plugin that should dump out function declarations and
definitions as the compiler sees them. One thing that I noticed
(besides that Brian Hackett's PLUGIN_FINISH_DECL hook should really be
applied to future versions) was that there does not seem to be a
function that could output the
AspertameMan wrote:
> Back in the 1970's when we ran fortran on an IBM machine we had this
> really powerful command called CALL FDUMP that if inserted into a
> program would send the names and values of every variable, at the time
> of its call, to a printer or file. [...]
This sounds like
On 06/12/2010 02:20, H.J. Lu wrote:
> BTW, the new linker passed bootstrap-lto with all default languages.
> I am planning to include this patch in the next Linux binutils.
>
I missed the IR object in an archive:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42690#c34
On Mon, Dec 6, 2010 at 9:23 AM, Dave Korn wrote:
> On 06/12/2010 02:20, H.J. Lu wrote:
>
>> BTW, the new linker passed bootstrap-lto with all default languages.
>> I am planning to include this patch in the next Linux binutils.
>>
> I missed the IR object in an archive:
>
>
On Mon, Dec 6, 2010 at 9:23 AM, Dave Korn wrote:
>
> Well, I reckon this patch is great (but don't have the approval rights).
> It's passed an lto-bootstrap of gcc on i686-pc-cygwin and the tests are well
> underway without anything abnormal showing up.
>
Can we close
http://gcc.gnu.org/bugzill
On 06/12/2010 17:44, H.J. Lu wrote:
> On Mon, Dec 6, 2010 at 9:23 AM, Dave Korn wrote:
>> Well, I reckon this patch is great (but don't have the approval rights).
>> It's passed an lto-bootstrap of gcc on i686-pc-cygwin and the tests are well
>> underway without anything abnormal showing up.
>>
>
On Mon, Dec 6, 2010 at 10:19 AM, Dave Korn wrote:
> On 06/12/2010 17:44, H.J. Lu wrote:
>> On Mon, Dec 6, 2010 at 9:23 AM, Dave Korn wrote:
>>> Well, I reckon this patch is great (but don't have the approval rights).
>>> It's passed an lto-bootstrap of gcc on i686-pc-cygwin and the tests are wel
roy rosen writes:
> If I have two load SI insns. Is there any way to combine them into one
> load DI insn?
> Not using peephole which can catch only this limited case of being
> sequential insns.
> I have seen something done in ARM (*arith_adjacentmem) but it is very
> awkward and would not be re
Hi,
"ld -r" doesn't work with mixed IR/non-IR objects:
http://www.sourceware.org/bugzilla/show_bug.cgi?id=12291
Some compilers support it. Should it be supported?
--
H.J.
On 12/06/2010 02:30 PM, H.J. Lu wrote:
> Hi,
>
> "ld -r" doesn't work with mixed IR/non-IR objects:
>
> http://www.sourceware.org/bugzilla/show_bug.cgi?id=12291
>
> Some compilers support it. Should it be supported?
>
As we discussed in person, I think it would be user friendly to support
it,
> Hi,
>
> "ld -r" doesn't work with mixed IR/non-IR objects:
>
> http://www.sourceware.org/bugzilla/show_bug.cgi?id=12291
There are various bugs for it in gcc bugzilla too.
> Some compilers support it. Should it be supported?
Yes. I've been working on it (slim lto was the first part needed for i
On Mon, Dec 6, 2010 at 2:43 PM, Andi Kleen wrote:
>> Hi,
>>
>> "ld -r" doesn't work with mixed IR/non-IR objects:
>>
>> http://www.sourceware.org/bugzilla/show_bug.cgi?id=12291
>
> There are various bugs for it in gcc bugzilla too.
>
>> Some compilers support it. Should it be supported?
>
> Yes. I
> On Mon, Dec 6, 2010 at 2:43 PM, Andi Kleen wrote:
>>> Hi,
>>>
>>> "ld -r" doesn't work with mixed IR/non-IR objects:
>>>
>>> http://www.sourceware.org/bugzilla/show_bug.cgi?id=12291
>>
>> There are various bugs for it in gcc bugzilla too.
>>
>>> Some compilers support it. Should it be supported?
On Mon, Dec 06, 2010 at 09:57:14AM -0800, H.J. Lu wrote:
> Personally, I think 2 stage linking is one way to fix this issue.
Ian has stated that he thinks this is a really bad idea. I haven't
approved the patch because I value Ian's opinion, and can see why he
thinks it is the wrong way to go. O
On Mon, Dec 6, 2010 at 3:29 PM, Alan Modra wrote:
> On Mon, Dec 06, 2010 at 09:57:14AM -0800, H.J. Lu wrote:
>> Personally, I think 2 stage linking is one way to fix this issue.
>
> Ian has stated that he thinks this is a really bad idea. I haven't
> approved the patch because I value Ian's opini
This is the beta release of binutils 2.21.51.0.2 for Linux, which is
based on binutils 2010 1206 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been
Alan Modra writes:
> On Mon, Dec 06, 2010 at 09:57:14AM -0800, H.J. Lu wrote:
>> Personally, I think 2 stage linking is one way to fix this issue.
>
> Ian has stated that he thinks this is a really bad idea. I haven't
> approved the patch because I value Ian's opinion, and can see why he
> think
"H.J. Lu" writes:
> I don't have such programs at hand. Will timings from gccgo, which is
> written in C++, help?
gccgo by itself is not really a large C++ program. It's only about
50,000 lines of C++.
Building gcc with --enable-build-with-cxx would get you a large C++
program, but of course i
On Mon, Dec 6, 2010 at 3:54 PM, Ian Lance Taylor wrote:
> Alan Modra writes:
>
>> On Mon, Dec 06, 2010 at 09:57:14AM -0800, H.J. Lu wrote:
>>> Personally, I think 2 stage linking is one way to fix this issue.
>>
>> Ian has stated that he thinks this is a really bad idea. I haven't
>> approved th
On Mon, Dec 6, 2010 at 3:55 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> I don't have such programs at hand. Will timings from gccgo, which is
>> written in C++, help?
>
> gccgo by itself is not really a large C++ program. It's only about
> 50,000 lines of C++.
>
> Building gcc with --en
On Mon, Dec 6, 2010 at 3:09 PM, Andi Kleen wrote:
>> On Mon, Dec 6, 2010 at 2:43 PM, Andi Kleen wrote:
Hi,
"ld -r" doesn't work with mixed IR/non-IR objects:
http://www.sourceware.org/bugzilla/show_bug.cgi?id=12291
>>>
>>> There are various bugs for it in gcc bugzilla too
"H.J. Lu" writes:
> On Mon, Dec 6, 2010 at 3:54 PM, Ian Lance Taylor wrote:
>> Alan Modra writes:
>>
>>> On Mon, Dec 06, 2010 at 09:57:14AM -0800, H.J. Lu wrote:
Personally, I think 2 stage linking is one way to fix this issue.
>>>
>>> Ian has stated that he thinks this is a really bad ide
On Mon, Dec 6, 2010 at 4:08 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> On Mon, Dec 6, 2010 at 3:54 PM, Ian Lance Taylor wrote:
>>> Alan Modra writes:
>>>
On Mon, Dec 06, 2010 at 09:57:14AM -0800, H.J. Lu wrote:
> Personally, I think 2 stage linking is one way to fix this issu
On Mon, Dec 6, 2010 at 5:02 PM, H.J. Lu wrote:
> On Mon, Dec 6, 2010 at 4:08 PM, Ian Lance Taylor wrote:
>> "H.J. Lu" writes:
>>
>>> On Mon, Dec 6, 2010 at 3:54 PM, Ian Lance Taylor wrote:
Alan Modra writes:
> On Mon, Dec 06, 2010 at 09:57:14AM -0800, H.J. Lu wrote:
>> Person
>>> I see no particular reason why that should be the case. The issues are
>>> conceptually simple.
>>
>> I'd like to a gold implementation which works on all known cases.
You'd like to what?
> BTW, gold LTO plugin miscompiled 416.gamess in SPEC CPU 2006:
>
> http://www.sourceware.org/bugzilla/s
On Mon, Dec 6, 2010 at 5:19 PM, Cary Coutant wrote:
I see no particular reason why that should be the case. The issues are
conceptually simple.
>>>
>>> I'd like to a gold implementation which works on all known cases.
>
> You'd like to what?
I'd like to see gold implementation which wo
29 matches
Mail list logo
