> I doubt that there is any documentation on this, but I'd be happy to be
> surprised. TARGET_MACHINE_DEPENDENT_REORG is pretty much free to
> rearrange things however it likes.
>
> If you write
>
> const int ai[] = { 1 };
> int main() { }
>
> then in some cases the global const variable will be p
Trevor Scroggins writes:
> While I still think the choice is arbitrary (why the front and not the
> back--and mine's a lay opinion, I know), what's the generally accepted
> method for reorganizing string literals and other constants to appear
> after the function asm rather than before it? Some t
Re: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01404.html
Do you have test cases for this?
Changing can_throw_internal/external to depend on whether or not future
inlining is possible looks *very* wrong to me. Surely the only thing
that matters for new code that might appear "below" this po
Rather, a safe ref distance. Apologies for the duplicate message.
Trev
-- Forwarded message --
From: Trevor Scroggins
Date: Fri, Jul 10, 2009 at 3:19 PM
Subject: Re: CONSTANT_POOL_BEFORE_FUNCTION has no effect in tm.h?
To: Ian Lance Taylor
Cc: gcc@gcc.gnu.org
While I still thi
While I still think the choice is arbitrary (why the front and not the
back--and mine's a lay opinion, I know), what's the generally accepted
method for reorganizing string literals and other constants to appear
after the function asm rather than before it? Some targets appear to
do something simil
On Thu, Jul 9, 2009 at 2:52 PM, Steve
Kargl wrote:
> On Thu, Jul 09, 2009 at 12:34:00PM -0400, NightStrike wrote:
>> I have been trying to run the gfortran testsuite for a while now, and
>> it keeps falling apart. Dominiq tried to find a revision that might
>> attribute to it, and though r147421 m
Mohamed Shafi writes:
> The GCC 4.4.0 internal says :
> [Macro] CALL_REALLY_USED_REGISTERS
> Like CALL_USED_REGISTERS except this macro doesn’t require that the
> entire set of
> FIXED_REGISTERS be included. (CALL_USED_REGISTERS must be a superset of FIXED_
> REGISTERS). This macro is optional. I
On Fri, Jul 10, 2009 at 1:48 PM, Maciej Cencora wrote:
> Hi,
>
> I think I've found a bug in g++. Let's say we have following files:
>
> // a.hpp
>
> template
> void func1()
> {
> // general code
> }
>
> // a.cpp
>
> #include "a.hpp"
>
> template<>
> void func1()
> {
> // specialized
Hi,
I think I've found a bug in g++. Let's say we have following files:
// a.hpp
template
void func1()
{
// general code
}
// a.cpp
#include "a.hpp"
template<>
void func1()
{
// specialized code
}
// main.cpp
#include "a.hpp"
int main(void)
{
func1();
