Steven Rostedt writes:
>
> And frame pointers do add a little overhead as well. Too bad the mcount
> ABI wasn't something like this:
>
>
> :
> callmcount
> [...]
>
> This way, the function address for mcount would have been (%esp) and the
> parent address woul
Thomas Gleixner wrote:
> While testing various kernel configs we found out that the problem
> comes and goes. Finally I started to compare the gcc command line
> options and after some fiddling it turned out that the following
> minimal deltas change the code generator behaviour:
>
> Bad: -march
Hi,
I have a problem about function call insn.
in "CALL @LABEL", only can jump backward/forward 32k SPACE. So
if it overflows, the function symbol_ref could move a register, then
"CALL Ri" (i represent 0 ~ 15).
But the question is gcc doesn't know the function symbol_ref 's
address
Andrew Haley wrote:
> Thomas Gleixner wrote:
>
>> While testing various kernel configs we found out that the problem
>> comes and goes. Finally I started to compare the gcc command line
>> options and after some fiddling it turned out that the following
>> minimal deltas change the code generator
On Fri, 2009-11-20 at 10:57 +0100, Andi Kleen wrote:
> Steven Rostedt writes:
> >
> > And frame pointers do add a little overhead as well. Too bad the mcount
> > ABI wasn't something like this:
> >
> >
> > :
> > callmcount
> > [...]
> >
> > This way, the function ad
An attempt to build either gcc-trunk or the most recent
snapshot (20091119) with Cygwin (the build compiler
is either GCC 4.4.0 or 4.5-20090604), configured as:
$ ../configure --prefix=/opt/gcc-4.5-20091119 -v --enable-bootstrap --enable-ve
rsion-specific-runtime-libs --enable-shared --enable-shar
2009/11/20 Piotr Wyderski :
> An attempt to build either gcc-trunk or the most recent
> snapshot (20091119) with Cygwin (the build compiler
> is either GCC 4.4.0 or 4.5-20090604), configured as:
>
> $ ../configure --prefix=/opt/gcc-4.5-20091119 -v --enable-bootstrap
> --enable-ve
> rsion-specific-
Kai Tietz wrote:
> This error you get is more related to used binutils version.The
> warning you get looks more like a cripled '-Wl,--tsaware'.
Thanks, that looks like a good explanation.
> Which binutils version you are using?
$ ld -v
GNU ld (GNU Binutils) 2.18.50.20080625
I'll try to upgrade
From some simple experiments (see below), it appears as though GCC aims
to
create a lop-sided tree when there are constants involved (func1 below),
but a balanced tree when there aren't (func2 below).
Our assumption is that GCC likes having constants all near to each other
to
aid with tree-based o
On Fri, Nov 20, 2009 at 10:05 AM, Ian Bolton wrote:
> From some simple experiments (see below), it appears as though GCC aims
> to
> create a lop-sided tree when there are constants involved (func1 below),
> but a balanced tree when there aren't (func2 below).
>
> Our assumption is that GCC likes
On Fri, Nov 20, 2009 at 4:18 PM, David Edelsohn wrote:
> On Fri, Nov 20, 2009 at 10:05 AM, Ian Bolton wrote:
>> From some simple experiments (see below), it appears as though GCC aims
>> to
>> create a lop-sided tree when there are constants involved (func1 below),
>> but a balanced tree when the
On Fri, 2009-11-20 at 10:18 -0500, David Edelsohn wrote:
> On Fri, Nov 20, 2009 at 10:05 AM, Ian Bolton wrote:
> > From some simple experiments (see below), it appears as though GCC aims
> > to
> > create a lop-sided tree when there are constants involved (func1 below),
> > but a balanced tree wh
Ingo, Thomas and Linus,
I know Thomas did a patch to force the -mtune=generic, but just in case
gcc decides to do something crazy again, this patch will catch it.
Should we try to get this in now?
-- Steve
On Fri, 2009-11-20 at 00:23 -0500, Steven Rostedt wrote:
> commit c7715fb611c69ac4b7f722a
On 11/20/2009 09:00 AM, Steven Rostedt wrote:
> Ingo, Thomas and Linus,
>
> I know Thomas did a patch to force the -mtune=generic, but just in case
> gcc decides to do something crazy again, this patch will catch it.
>
> Should we try to get this in now?
>
Sounds like a very good idea to me.
On 11/20/2009 04:21 AM, daniel tian wrote:
But the question is gcc doesn't know the function symbol_ref 's
address before ld taking care.
Now there is only one solution I could choose: to force all the
function call symbol_ref into register and CALL insn calls the
register.
But
On 11/20/2009 04:34 AM, Steven Rostedt wrote:
>>
>> If there's interest I can polish it up and submit formally.
>
> I would definitely be interested, and I would also be willing to test
> it.
>
I don't think there is any question that interception at the
architectural entry point would be the ri
We have a clarification from Apple on the problem of
dsymutils asserting since the VTA merge changes...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473#c27
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473#c29
Does the code in gcc/dwarfout.c currently check if
any block form with zero length
Steven Rostedt wrote:
> Ingo, Thomas and Linus,
>
> I know Thomas did a patch to force the -mtune=generic, but just in case
> gcc decides to do something crazy again, this patch will catch it.
>
> Should we try to get this in now?
I'm sure this makes sense, but a gcc test case would be even bett
On Fri, 2009-11-20 at 19:35 +, Andrew Haley wrote:
> Steven Rostedt wrote:
> > Ingo, Thomas and Linus,
> >
> > I know Thomas did a patch to force the -mtune=generic, but just in case
> > gcc decides to do something crazy again, this patch will catch it.
> >
> > Should we try to get this in no
On 11/20/2009 11:46 AM, Steven Rostedt wrote:
>
> Yes a gcc test suite will help new instances of gcc. But we need to
> worry about the instances of gcc that people have on their desktops now.
> This test case will catch the discrepancy between gcc and the function
> graph tracer. I'm not 100% con
Piotr Wyderski wrote:
> Kai Tietz wrote:
>
>> This error you get is more related to used binutils version.The
>> warning you get looks more like a cripled '-Wl,--tsaware'.
>
> Thanks, that looks like a good explanation.
Yes, I added this to HEAD recently
>> Which binutils version you are usin
Janis Johnson writes:
> On Wed, 2009-11-18 at 19:19 +0100, Rainer Orth wrote:
>> I've recently looked into what it takes to support decimal float on
>> additional platforms (like Solaris, IRIX, and Tru64 UNIX in my case).
>> I've found no documentation, and while I could figure out some things
>>
"Joseph S. Myers" writes:
> On Wed, 18 Nov 2009, Rainer Orth wrote:
>
>> be added on legacy platforms like IRIX and Tru64 UNIX, and even on
>> Solaris probably won't show up until DFP is fully standardized.
>
> I'd have expected the Solaris maintainers to care more about whether
> Solaris custom
On Fri, 20 Nov 2009, Rainer Orth wrote:
> > Much the same applies if anyone wishes to add fixed point (TR 18037)
> > support for more targets.
>
> I'll have a look at the last draft (N1169) for now. Right now, only
> MIPS support is in GCC, so there seems to be less traction so far.
Each of th
The release of GNU MPFR 2.4.2 ("andouillette sauce moutarde"
patch level 2) is imminent. Please help to make this release
as good as possible by downloading and testing this second
release candidate:
http://www.mpfr.org/mpfr-2.4.2/mpfr-2.4.2-rc2.tar.xz
http://www.mpfr.org/mpfr-2.4.2/mpfr-2.4.2-rc2
On Fri, Nov 20, 2009 at 9:06 PM, Dave Korn
wrote:
> Piotr Wyderski wrote:
>> Kai Tietz wrote:
>>
>>> This error you get is more related to used binutils version.The
>>> warning you get looks more like a cripled '-Wl,--tsaware'.
>>
>> Thanks, that looks like a good explanation.
>
> Yes, I added th
On 11/20/2009 11:58 PM, Vincent Lefevre wrote:
> The release of GNU MPFR 2.4.2 ("andouillette sauce moutarde"
>
Humm, not to all tastes... ;)
Paolo.
Hey Dave,
What OS are you bootstrapping on, and with which compiler/version?
(Cygwin, I assume, but you never know
;>)
I haven't been able to bootstrap for a few weeks, but no one answered my
email for help (which probably got lost in the kernel-related fighting):
http://gcc.gnu.org/ml/gcc/
28 matches
Mail list logo
