I came across a "gotcha" whilst trying to test the static
implementation of libgfortran on PPC64-apple-darwin8.
Thanks to Tobias B for pointing me at 99% of the solution.
Probably the number of affected systems is small ;) - but, FWIW,
here's HOWTO and a fix.
-
If you host on {powerpc,
Thanks for all the helpful suggestions made in response to :
http://gcc.gnu.org/ml/gcc/2008-06/msg00244.html
--
Here is version 2 of the patch.
This is now conditional on darwin* as the host.
(I guess, in principle, it should really depend on LD_FOR_TARGET, but
I couldn't see how to achiev
Hi, I reported a problem I have with abort to the glibc bug tracker at
http://sourceware.org/bugzilla/show_bug.cgi?id=6522> which might
provide some reading material.
Anyway, it has been pointed out to me that the requested change would
not accomplish much anyway since GCC has its own builtin not
Hi all,
my intention is to add a pass at the Gimple (maybe SSA) level. The
current problem is that I would like to generate code that saves the
contents of the stack to a different memory location. Is there a way
to access stack pointer and stack size (and the direction in which the
stack
David Kastrup <[EMAIL PROTECTED]> writes:
>
> However, the problem is obviously not restricted to Emacs. If the
> "noreturn" attribute for the internal abort were removed, at least only
> abort calls with compatible stack frame and the same (tentative)
> followup code would get folded. That would
On Tue, Jun 17, 2008 at 11:33 AM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> David Kastrup <[EMAIL PROTECTED]> writes:
>>
>> However, the problem is obviously not restricted to Emacs. If the
>> "noreturn" attribute for the internal abort were removed, at least only
>> abort calls with compatible stac
Richard Guenther wrote:
> On Tue, Jun 17, 2008 at 11:33 AM, Andi Kleen <[EMAIL PROTECTED]> wrote:
>> David Kastrup <[EMAIL PROTECTED]> writes:
>>> However, the problem is obviously not restricted to Emacs. If the
>>> "noreturn" attribute for the internal abort were removed, at least only
>>> abort
On Tue, Jun 17, 2008 at 12:04 PM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
>> On Tue, Jun 17, 2008 at 11:33 AM, Andi Kleen <[EMAIL PROTECTED]> wrote:
>>> David Kastrup <[EMAIL PROTECTED]> writes:
However, the problem is obviously not restricted to Emacs. If the
"no
On Tue, Jun 17, 2008 at 12:04 PM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> But it would still cross jump the call then wouldn't it?
Depends if they return to the same basic block next ...
-- Pinski
On Tue, Jun 17, 2008 at 3:58 PM, David Kastrup <[EMAIL PROTECTED]> wrote:
> Probably better would be to just disable the crossjumping optimization
> for calls of abort. Maybe this would warrant a new attribute.
Read the long thread starting at
http://gcc.gnu.org/ml/gcc/2005-03/msg00568.html and l
On Tue, Jun 17, 2008 at 9:58 AM, David Kastrup <[EMAIL PROTECTED]> wrote:
>
> Hi, I reported a problem I have with abort to the glibc bug tracker at
> http://sourceware.org/bugzilla/show_bug.cgi?id=6522> which might
> provide some reading material.
>
> Anyway, it has been pointed out to me that the
Is there a way to
access stack pointer and stack size (and the direction in which the
stack is growing) on the tree level?
The explanation why I want to save the stack contents is the following:
Code:
... use stack variables
__tm_atomic { /* begin transaction */
access shared locations in he
On Sun, Jun 15, 2008 at 12:49 PM, Jay <[EMAIL PROTECTED]> wrote:
>
> When gcc configures the in-tree gmp/mpfr, why
> does it use --host=none-${host_vendor}-${host_os}
> --target=none-${host_vendor}-${host_os}
>
> instead of --host=${host_alias} --target=${target_alias}
>
> This "breaks" config.ca
Hi,
I have stumbled upon a quirk that appears to me to be
illogical. Maybe someone can help me to understand this:
sample code ~
#include
const int gic = 0;
const int * gcip;
int * gip;
int main(int argc, char * argv[]) {
const int ic = 0;
const int
Karen Shaeffer <[EMAIL PROTECTED]> writes:
> int main(int argc, char * argv[]) {
> const int ic = 0;
> const int * cip;
> int * ip;
> cip =
> ip = (int *)cip;
> *ip = 5;
> printf("const int ic = %d *cip = %d *ip = %d\n", ic, *cip, *ip);
> printf("&ic = %pcip = %pip =
Tom,
Thanks a lot for pointing us to the sparse annotations. We will take a
look and see what its support looks like.
Le-chun
On Sun, Jun 15, 2008 at 2:43 PM, Tom Tromey <[EMAIL PROTECTED]> wrote:
>> "Le-Chun" == Le-Chun Wu <[EMAIL PROTECTED]> writes:
>
> Le-Chun> Here is the design doc for
On Tue, Jun 17, 2008 at 11:01:31AM -0700, Ian Lance Taylor wrote:
> >
> > output ~~
> > $ const_ints
> > const int ic = 0 *cip = 5 *ip = 5
> > &ic = 0xbfbd72a0cip = 0xbfbd72a0ip = 0xbf
2008/6/12 Jonathan Wakely:
> 2008/6/11 Volker Reichelt:
>> * Scopes in for-loops:
>>
>> void foo()
>> {
>>for (int i=0; i<10; ++i) {}
>>i = 0;
>> }
>>
>> warn.cc: In function 'void foo()':
>> warn.cc:4: warning: name lookup of 'i' changed for new ISO 'for' scoping
>> warn.cc:3: warnin
"Daniel Berlin" <[EMAIL PROTECTED]> writes:
> You are about 3 years late to the party on this one :)
>
> http://gcc.gnu.org/ml/gcc/2005-03/msg00568.html
Yup.
> Realistically, you are not going to be able to get good stacktraces
> with optimized code for *other* reasons, abort is just the first t
On Tue, Jun 17, 2008 at 11:01:31AM -0700, Ian Lance Taylor wrote:
> > output ~~
> > $ const_ints
> > const int ic = 0 *cip = 5 *ip = 5
> > &ic = 0xbfbd72a0cip = 0xbfbd72a0ip = 0xbfbd72a0
> > ~~
On Tue, Jun 17, 2008 at 9:44 PM, Karen Shaeffer
<[EMAIL PROTECTED]> wrote:
> On Tue, Jun 17, 2008 at 11:01:31AM -0700, Ian Lance Taylor wrote:
>> > output ~~
>> > $ const_ints
>> > const int ic = 0 *cip = 5 *ip = 5
>> > &ic = 0xbfbd72a0cip = 0xbf
On Tue, Jun 17, 2008 at 09:52:17PM -0400, Andrew Pinski wrote:
> On Tue, Jun 17, 2008 at 9:44 PM, Karen Shaeffer
> <[EMAIL PROTECTED]> wrote:
> > On Tue, Jun 17, 2008 at 11:01:31AM -0700, Ian Lance Taylor wrote:
> >> > output ~~
> >> > $ const_ints
> >>
Karen Shaeffer <[EMAIL PROTECTED]> writes:
> I see your point. My sticking point is that the process is actually
> running on a physical machine. And the addresses, although virtual,
> do translate to a unique physical memory location. And, the value
> stored in that location cannot be 0 and 5 at
[again as plain text]
Ah, I didn't realize any C or C++ code could be configured for other than a
specific processor but I guess that makes sense -- it is Makefile, config.h,
and such that are being modified, not the .o files, and they might be the same
across many configurations, like if the
As I promised at the summit today, I have created the branch
gcc-in-cxx (I originally said gcc-in-c++, but I decided that it was
better to avoid possible meta-characters). The goal of this branch is
to develop a version of gcc which is compiled with C++. Here are my
presentation slides in PDF for
Hello Karen,
Tuesday, June 17, 2008, 10:38:20 PM, you wrote:
> Hi Ian, I can live with that. My problem was that the addresses
> cannot be correct. In my opinion, the undefined behavior should be
> limited to the value in the address or in some form of error. But to
> let the buggy code ex
26 matches
Mail list logo
