On Jan 27, 2009, at 10:47 PM, Ian Lance Taylor wrote:
Is LLVM smart enough to optimize that away, even when using shared
libraries?
Yes absolutely. Just build with -fvisibility-hidden or use an export
map to say that my_null_pointer is not exported. If it is static, it
will also do it at -O2.
Chris Lattner writes:
> On Jan 27, 2009, at 5:10 PM, Ian Lance Taylor wrote:
>
>> Chris Lattner writes:
>>
>>> On Jan 27, 2009, at 1:10 PM, Ian Lance Taylor wrote:
>>>
Laurent GUERBY writes:
> Just curious: is there a "portable" way to read from memory
> address zero in C code
On Jan 27, 2009, at 1:11 PM, Diego Novillo wrote:
The LTO branch is starting to get some semblance of stability, though
is by no means in any kind of mergeable state. I have updated the
wiki page to reflect the current status (Simon, Rafael, Doug, Cary,
please make sure I haven't missed anythi
On Jan 27, 2009, at 5:10 PM, Ian Lance Taylor wrote:
Chris Lattner writes:
On Jan 27, 2009, at 1:10 PM, Ian Lance Taylor wrote:
Laurent GUERBY writes:
Just curious: is there a "portable" way to read from memory
address zero in C code? "portable" here means likely to work
on most compile
> On Tue, Jan 27, 2009 at 05:24:36PM -0800, Dennis Clarke wrote:
>> This is old 32-bit Sparc so I don't think 64-bit code will serve any
>> purpose here.
>
> Specifying --disable-multilib at configure time should keep it from
> building the 64-bit libraries.
I'll give that a try thank you !
My o
On Tue, Jan 27, 2009 at 05:24:36PM -0800, Dennis Clarke wrote:
> This is old 32-bit Sparc so I don't think 64-bit code will serve any
> purpose here.
Specifying --disable-multilib at configure time should keep it from
building the 64-bit libraries.
Gerald Pfeifer writes:
> +January 27, 2008
2009 ;)
Adam
And here the website update...
Gerald
Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.683
retrieving revision 1.685
diff -u -3 -p -r1.683 -r1.685
--- index.html 24 Jan 2009 14:13:55 -
> On Tue, Jan 27, 2009 at 04:53:09PM -0800, Dennis Clarke wrote:
>>
>> This is on an old Sun Sparc machine running Solaris 8.
>>
>> I had CFLAGS set thus :
>>
>> $ echo $CFLAGS
>> -mcpu=v7 -m32 -mno-app-regs -pthreads
>
> That's your problem. Try again without this setting.
>
>> Shortly into what
On Tue, Jan 27, 2009 at 04:53:09PM -0800, Dennis Clarke wrote:
>
> This is on an old Sun Sparc machine running Solaris 8.
>
> I had CFLAGS set thus :
>
> $ echo $CFLAGS
> -mcpu=v7 -m32 -mno-app-regs -pthreads
That's your problem. Try again without this setting.
> Shortly into what looks like
Chris Lattner writes:
> On Jan 27, 2009, at 1:10 PM, Ian Lance Taylor wrote:
>
>> Laurent GUERBY writes:
>>
>>> Just curious: is there a "portable" way to read from memory
>>> address zero in C code? "portable" here means likely to work
>>> on most compilers without exotic compile flags in 2009.
This is on an old Sun Sparc machine running Solaris 8.
I had CFLAGS set thus :
$ echo $CFLAGS
-mcpu=v7 -m32 -mno-app-regs -pthreads
I was using gcc version 4.2.4 to perform this bootstrap and I set the
configure options for non-GNU as and ld thus :
$ ../gcc-4.3.3/configure --with-as=/usr/ccs/b
On Jan 27, 2009, at 1:10 PM, Ian Lance Taylor wrote:
Laurent GUERBY writes:
Just curious: is there a "portable" way to read from memory
address zero in C code? "portable" here means likely to work
on most compilers without exotic compile flags in 2009.
char *my_null_pointer;
char fn() { re
Laurent GUERBY wrote:
> >> Just curious: is there a "portable" way to read from memory
> >> address zero in C code? "portable" here means likely to work
> >> on most compilers without exotic compile flags in 2009.
Florian Weimer wrote:
> > No, C hasn't got a notion of addresses. The situation i
Florian Weimer wrote:
* Laurent GUERBY:
Just curious: is there a "portable" way to read from memory
address zero in C code? "portable" here means likely to work
on most compilers without exotic compile flags in 2009.
No, C hasn't got a notion of addresses. The situation is likely to
get even
On Tue, 27 Jan 2009, David Edelsohn wrote:
> The GCC Steering Committee, along with the Free Software Foundation
> and the Software Freedom Law Center, is pleased to announce the release
> of a new GCC Runtime Library Exception.
>
> This license exception has been developed to allow various GCC
>
On Tue, Jan 27, 2009 at 12:51:22PM -0800, Florian Weimer wrote:
> * David Edelsohn:
>
> > We have also published a rationale document and FAQ to help users
> > understand the exception better. It is avaliable at:
> >
> > http://www.gnu.org/licenses/gcc-exception-faq.html
>
> Is it deliberate t
On Tue, Jan 27, 2009 at 17:05, H.J. Lu wrote:
> What can I help to implement the fix?
Thanks. I just updated bug 38992 with the IRC thread where we
discussed a possible fix. I don't think it would be too complicated.
Diego.
On Tue, Jan 27, 2009 at 2:02 PM, Diego Novillo wrote:
> On Tue, Jan 27, 2009 at 16:58, H.J. Lu wrote:
>
>> LTO failed to bootstrap on RHEL5/ia32 and RHEL5/ia64:
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38992
>
> Thanks. This was known to us, though we had not filed a request.
> Essentia
On Tue, Jan 27, 2009 at 16:58, H.J. Lu wrote:
> LTO failed to bootstrap on RHEL5/ia32 and RHEL5/ia64:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38992
Thanks. This was known to us, though we had not filed a request.
Essentially, Red Hat distros use a different libelf than the one we
have b
On Tue, Jan 27, 2009 at 1:11 PM, Diego Novillo wrote:
> The LTO branch is starting to get some semblance of stability, though
> is by no means in any kind of mergeable state. I have updated the
> wiki page to reflect the current status (Simon, Rafael, Doug, Cary,
> please make sure I haven't miss
From: Ian Lance Taylor
Date: Tue, 27 Jan 2009 13:16:31 -0800
> A co-worker of mine at Google did some experiments along those lines
> using gold. He was not able to demonstrate any performance
> improvements, unfortunately (x86_64 target, proprietary test cases).
> He was hacking linker scripts.
On Tue, Jan 27, 2009 at 16:24, H.J. Lu wrote:
> I can try to run tests on Linux/ia32, Linux/ia64 and Linux/x86-64.
Thanks.
> Does it require gold?
No, It does not require gold. However, if you have gold installed,
you can use -use-linker-plugin to use the linker plugin to communicate
between
On Tue, Jan 27, 2009 at 1:11 PM, Diego Novillo wrote:
> The LTO branch is starting to get some semblance of stability, though
> is by no means in any kind of mergeable state. I have updated the
> wiki page to reflect the current status (Simon, Rafael, Doug, Cary,
> please make sure I haven't miss
David Edelsohn writes:
> The GCC Steering Committee, along with the Free Software Foundation
> and the Software Freedom Law Center, is pleased to announce the release
> of a new GCC Runtime Library Exception.
>
> This license exception has been developed to allow various GCC
> libraries to upgrad
Joern Rennecke writes:
> So I was wodering if we could get a good first-order approximation
> by placing library code that is called frequently together with the
> code that is calling it.
A co-worker of mine at Google did some experiments along those lines
using gold. He was not able to demons
The LTO branch is starting to get some semblance of stability, though
is by no means in any kind of mergeable state. I have updated the
wiki page to reflect the current status (Simon, Rafael, Doug, Cary,
please make sure I haven't missed anything substantial):
http://gcc.gnu.org/wiki/LinkTimeOpti
Robert Dewar writes:
> Interestingly, my viewpoint on this from the compiler domain might
> seem to be quite inconsistent. I think it is generally a bad idea
> for compilers to aggressively optimize based on assumptions that
> programs are free of these kinds of mistakes. I would only be in
> fav
Laurent GUERBY writes:
> Just curious: is there a "portable" way to read from memory
> address zero in C code? "portable" here means likely to work
> on most compilers without exotic compile flags in 2009.
char *my_null_pointer;
char fn() { return *my_null_pointer; }
It will be quite a while be
Daniel Jacobowitz writes:
> On Tue, Jan 27, 2009 at 06:52:18PM +1100, zol...@bendor.com.au wrote:
>> // Debug( tst->value );
>>
>>if ( ! tst ) {
>>ptr->next = (void *) 0;
>>break;
>>}
>
> This optimization comes up on the list frequently. Do folks thi
* David Edelsohn:
> We have also published a rationale document and FAQ to help users
> understand the exception better. It is avaliable at:
>
> http://www.gnu.org/licenses/gcc-exception-faq.html
Is it deliberate that the exception does not extend to programs
compiled with GCJ?
On Tue, 2009-01-27 at 21:37 +0100, Florian Weimer wrote:
> * Laurent GUERBY:
>
> > Just curious: is there a "portable" way to read from memory
> > address zero in C code? "portable" here means likely to work
> > on most compilers without exotic compile flags in 2009.
>
> No, C hasn't got a notion
* Laurent GUERBY:
> Just curious: is there a "portable" way to read from memory
> address zero in C code? "portable" here means likely to work
> on most compilers without exotic compile flags in 2009.
No, C hasn't got a notion of addresses. The situation is likely to
get even more extreme, not l
No new regressions. This should fix the TLS issue we were having with
libstdc++.
Diego.
The GCC Steering Committee, along with the Free Software Foundation
and the Software Freedom Law Center, is pleased to announce the release
of a new GCC Runtime Library Exception.
This license exception has been developed to allow various GCC
libraries to upgrade to GPLv3. It will also enable the
On Tue, Jan 27, 2009 at 05:42:04AM -0800, Daniel Jacobowitz wrote:
> On Tue, Jan 27, 2009 at 06:52:18PM +1100, zol...@bendor.com.au wrote:
> > // Debug( tst->value );
> >
> >if ( ! tst ) {
> >ptr->next = (void *) 0;
> >break;
> >}
>
> This optimization c
On Tue, Jan 27, 2009 at 09:33:17AM -0800, Steve Ellcey wrote:
> On Tue, 2009-01-27 at 12:31 +0100, Andi Kleen wrote:
> > Steve Ellcey writes:
> >
> > > because the crt files can't handle the large code model if they aren't
> > > compiled with this option.
> >
> > My understanding is that this wou
On Tue, Jan 27, 2009 at 9:42 AM, Steve Ellcey wrote:
> On Tue, 2009-01-27 at 09:39 -0800, H.J. Lu wrote:
>
>> Hi Steve,
>>
>> Can you open a bug report with a testcase?
>>
>> Thanks.
>
> I have submitted a bug report about the GCC bugs I ran into:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38
On Tue, 2009-01-27 at 09:39 -0800, H.J. Lu wrote:
> Hi Steve,
>
> Can you open a bug report with a testcase?
>
> Thanks.
I have submitted a bug report about the GCC bugs I ran into:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38988
Or do you mean a bug report about crtstuff.c not being compil
On Tue, Jan 27, 2009 at 9:33 AM, Steve Ellcey wrote:
> On Tue, 2009-01-27 at 12:31 +0100, Andi Kleen wrote:
>> Steve Ellcey writes:
>>
>> > because the crt files can't handle the large code model if they aren't
>> > compiled with this option.
>>
>> My understanding is that this would likely break
On Tue, 2009-01-27 at 12:31 +0100, Andi Kleen wrote:
> Steve Ellcey writes:
>
> > because the crt files can't handle the large code model if they aren't
> > compiled with this option.
>
> My understanding is that this would likely break old linkers which
> didn't do all large model relocations co
Sebastian Redl wrote:
> Laurent GUERBY wrote:
>> Just curious: is there a "portable" way to read from memory
>> address zero in C code? "portable" here means likely to work
>> on most compilers without exotic compile flags in 2009.
>>
> For C++, in *theory*, a reinterpret_cast(0) yields a pointe
Vincent Lefevre wrote:
On 2009-01-27 07:08:51 -0500, Robert Dewar wrote:
[...]
Interestingly, my viewpoint on this from the compiler domain might
seem to be quite inconsistent. I think it is generally a bad idea
for compilers to aggressively optimize based on assumptions that
programs are free o
On Tue, Jan 27, 2009 at 6:41 AM, Joern Rennecke wrote:
>
> The remaining question is how to best get the information from the
> compiler proper (cc1 / cc1plus etc) to the linker.
> Should the compiler write a temporary file, which is then read by the
> compiler driver to construct the link line?
>
On 2009-01-27 07:08:51 -0500, Robert Dewar wrote:
[...]
> Interestingly, my viewpoint on this from the compiler domain might
> seem to be quite inconsistent. I think it is generally a bad idea
> for compilers to aggressively optimize based on assumptions that
> programs are free of these kinds of m
When benchmarking, there is often noise from semi-random cache
layout issues. If the program in question has a code working set
size that fits in the instruction cache, I this nose can be mostly
attributed to thrashing because of unfortunate code layout.
If we could lay out the code working set
Richard Guenther writes:
> On Mon, Jan 26, 2009 at 7:53 PM, Ian Lance Taylor wrote:
>> Richard Guenther writes:
>>
>>> On Mon, Jan 26, 2009 at 4:23 PM, Andrew Walrond wrote:
I've tried two mirrors with the same results:
$ cat md5.sum | grep gcc-4.3.3.tar.bz2
d3338b75fa
Laurent GUERBY wrote:
> Just curious: is there a "portable" way to read from memory
> address zero in C code? "portable" here means likely to work
> on most compilers without exotic compile flags in 2009.
>
For C++, in *theory*, a reinterpret_cast(0) yields a pointer with
the value 0 that is not
On Tue, 2009-01-27 at 00:11 -0800, James Dennett wrote:
> On Mon, Jan 26, 2009 at 11:52 PM, wrote:
> > I was debugging a function and by inserting the debug statement crashed
> > the system. Some investigation revealed that gcc 4.3.2 arm-eabi (compiled
> > from sources) with -O2 under some circum
On Tue, Jan 27, 2009 at 06:52:18PM +1100, zol...@bendor.com.au wrote:
> // Debug( tst->value );
>
>if ( ! tst ) {
>ptr->next = (void *) 0;
>break;
>}
This optimization comes up on the list frequently. Do folks think a
corresponding warning would be a w
Robert Dewar wrote:
> James Dennett wrote:
>
>> I don't know how much work it would be to disable this optimization in
>> gcc.
>
> To me, it is always troublesome to talk of "disable this optimization"
> in a context like this.
In general I agree; on the other hand, for this particular optimizat
> I don't think that the compiler has a right to remove my test, just
> because it assumes that if I derferenced a pointer then it surely was not
> NULL.
While not related to your testcase directly, you contributed to finding
a couple of relatively severe bugs in GCC, so thank you!
Paolo
James Dennett wrote:
I don't know how much work it would be to disable this optimization in gcc.
To me, it is always troublesome to talk of "disable this optimization"
in a context like this. The program in question is not C, and its
semantics cannot be determined from the C standard. If the a
Steve Ellcey writes:
> The first one is: would it be reasonable to compile crt files with
> -mcmodel=large by default on the x86-64 linux platform? Currently the
> crt files are not compiled with this option and that makes it impossible
> to compile a program where the text segment is above 4GB
Richard Guenther wrote:
> On Tue, Jan 27, 2009 at 11:35 AM, Paolo Bonzini wrote:
> Not for PTA though ;)
Care to expand?
>>> PTA tracks points-to-NULL as pointing to "nothing".
>>> This probably should be conditional on -fdelete-null-pointer-checks.
>>> Otherwise *NULL and *anything won't
Paolo Bonzini wrote:
Not for PTA though ;)
>>> Care to expand?
>> PTA tracks points-to-NULL as pointing to "nothing".
>> This probably should be conditional on -fdelete-null-pointer-checks.
>> Otherwise *NULL and *anything won't alias.
>
> Yes, you're right. I'll see if I can construct a tes
On Tue, Jan 27, 2009 at 11:35 AM, Paolo Bonzini wrote:
Not for PTA though ;)
>>> Care to expand?
>>
>> PTA tracks points-to-NULL as pointing to "nothing".
>> This probably should be conditional on -fdelete-null-pointer-checks.
>> Otherwise *NULL and *anything won't alias.
>
> Yes, you're righ
>>> Not for PTA though ;)
>> Care to expand?
>
> PTA tracks points-to-NULL as pointing to "nothing".
> This probably should be conditional on -fdelete-null-pointer-checks.
> Otherwise *NULL and *anything won't alias.
Yes, you're right. I'll see if I can construct a testcase and a patch.
BTW, I
On Tue, Jan 27, 2009 at 11:29 AM, Paolo Bonzini wrote:
>
>>> However, -fno-delete-null-pointer-checks will do.
>>
>> Not for PTA though ;)
>
> Care to expand?
PTA tracks points-to-NULL separately (as pointing to "nothing"). See
/* x = integer is all glommed to a single variable, which doesn't
>> However, -fno-delete-null-pointer-checks will do.
>
> Not for PTA though ;)
Care to expand?
Paolo
On Tue, Jan 27, 2009 at 9:33 AM, Paolo Bonzini wrote:
> James Dennett wrote:
>> On Mon, Jan 26, 2009 at 11:52 PM, wrote:
>>> I was debugging a function and by inserting the debug statement crashed
>>> the system. Some investigation revealed that gcc 4.3.2 arm-eabi (compiled
>>> from sources) wit
On Mon, Jan 26, 2009 at 7:53 PM, Ian Lance Taylor wrote:
> Richard Guenther writes:
>
>> On Mon, Jan 26, 2009 at 4:23 PM, Andrew Walrond wrote:
>>> I've tried two mirrors with the same results:
>>>
>>> $ cat md5.sum | grep gcc-4.3.3.tar.bz2
>>>
>>> d3338b75fa6f83be08908b1eed56d439 gcc-4.3.3.tar
James Dennett wrote:
> On Mon, Jan 26, 2009 at 11:52 PM, wrote:
>> I was debugging a function and by inserting the debug statement crashed
>> the system. Some investigation revealed that gcc 4.3.2 arm-eabi (compiled
>> from sources) with -O2 under some circumstances assumes that if a pointer
>> i
On Tue, 27 Jan 2009, James Dennett wrote:
> On Mon, Jan 26, 2009 at 11:52 PM, wrote:
> > I was debugging a function and by inserting the debug statement crashed
> > the system. Some investigation revealed that gcc 4.3.2 arm-eabi (compiled
> > from sources) with -O2 under some circumstances assum
On Mon, Jan 26, 2009 at 11:52 PM, wrote:
> I was debugging a function and by inserting the debug statement crashed
> the system. Some investigation revealed that gcc 4.3.2 arm-eabi (compiled
> from sources) with -O2 under some circumstances assumes that if a pointer
> is dereferenced, it can not
65 matches
Mail list logo
