Possible bug in g++ - template specialization
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();
return 0;
}
Now when we run the program compiled with: g++ main.cpp a.cpp -o main
specialized version of func1 will be called, but when compiled with
-Os flag the general version will be called.
I'm not an expert but I believe the -Os behaviour is the correct one.
Please CC me when replying, as I'm not subscribed to the mailing list.
Regards,
Maciej Cencora
Re: Possible bug in g++ - template specialization
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 code
> }
>
> // main.cpp
>
> #include "a.hpp"
>
> int main(void)
> {
> func1();
>
> return 0;
> }
>
>
> Now when we run the program compiled with: g++ main.cpp a.cpp -o main
> specialized version of func1 will be called, but when compiled with
> -Os flag the general version will be called.
> I'm not an expert but I believe the -Os behaviour is the correct one.
By not making the specialized version available at the point of
instantiation you are violating the one-definition rule (ODR, no need
to diagnose it) and the behavior is undefined.
Richard.
Re: CALL_USED_REGISTERS vs CALL_REALLY_USED_REGISTERS
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. If not specifed, it defaults to the value > of > CALL_USED_REGISTERS. > > But it doesn't say why one needs to use this. > What is the need for the macro CALL_REALLY_USED_REGISTERS when > compared to CALL_USED_REGISTERS? As the doc says, CALL_USED_REGISTERS is required to include all fixed registers. However, some ABIs have fixed registers which appear in the insn stream and are not modified by calls. It can be useful for gcc to know that those registers are not changed by a call instruction. In particular, this means that if gcc uses the value of the register in an expression which includes a call, it knows that it does not have to copy the register into a callee-saved register to preserve the value. For example, the MIPS register $28 aka $gp has this characteristic. It is a fixed register in that it is not available for the register allocator. However, the instruction stream will contain code to use the register to access global variables (or small variables, depending on the ABI). The register is not changed by function calls, so gcc does not have to extra steps to preserve its value. Also, gcc can CSE $gp plus a large offset across a function call. Ian
Re: Can't run gfortran testsuite
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 might have something to do with >> it: http://gcc.gnu.org/viewcvs?view=rev&revision=147421 >> >> These are the errors I get that prevent the testsuite from running >> more than a few thousand tests: >> >> ERROR: tcl error sourcing >> /dev/shm/build/gcc-svn/gcc/gcc/testsuite/gfortran.dg/dg.exp. >> ERROR: can't read "status": no such variable >> ERROR: tcl error sourcing >> /dev/shm/build/gcc-svn/gcc/gcc/testsuite/gfortran.dg/gomp/gomp.exp. >> ERROR: torture-init: torture_without_loops is not empty as expected >> ERROR: tcl error sourcing >> /dev/shm/build/gcc-svn/gcc/gcc/testsuite/gfortran.dg/vect/vect.exp. >> ERROR: torture-init: torture_without_loops is not empty as expected >> ERROR: tcl error sourcing >> /dev/shm/build/gcc-svn/gcc/gcc/testsuite/gfortran.fortran-torture/compile/compile.exp. >> ERROR: torture-init: torture_without_loops is not empty as expected >> ERROR: tcl error sourcing >> /dev/shm/build/gcc-svn/gcc/gcc/testsuite/gfortran.fortran-torture/execute/execute.exp. >> ERROR: torture-init: torture_without_loops is not empty as expected > > This appears to be a general testsuite issue. You try pinging Janis > on IRC. She may have an idea on the cause. I'm also emailing the general gcc list about this. Does anyone have any idea on how to handle this situation?
Re: CONSTANT_POOL_BEFORE_FUNCTION has no effect in tm.h?
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 similar in TARGET_MACHINE_DEPENDENT_REORG to relocate
read-only data to a safe jump distance. Where should I begin looking
in source/documentation to gain an understanding of the process?
Also, I don't really grok your example, which probably belies a lack
of deep understanding of C or GCC or both. In every case I tried,
'const int ai[] = { 1 };' (and volatile ...) was translated to an
immediate value of 1.
Trev
On Mon, Jul 6, 2009 at 11:45 AM, Ian Lance Taylor wrote:
> Trevor Scroggins writes:
>
>> No, that won't work. The assembler only recognizes .text, .data, and
>> .bss and doesn't support .section. Surely there's a simple hook that
>> instructs that compiler to print locals after a function instead of
>> before it?
>
> No. Why should there be? Even if you fix the case of string constants,
> you will run into trouble as soon as somebody writes
> const int ai[] = { 1 };
>
> Most systems require some sort of startup code to run before main,
> anyhow. If you have no such requirement, then I recommend simply being
> disciplined in how you write the "main" function, or paying the cost of
> two or four initial bytes to branch to the main function from the start
> of the .text section.
>
> Ian
Fwd: CONSTANT_POOL_BEFORE_FUNCTION has no effect in tm.h?
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 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 similar in TARGET_MACHINE_DEPENDENT_REORG to relocate
read-only data to a safe jump distance. Where should I begin looking
in source/documentation to gain an understanding of the process?
Also, I don't really grok your example, which probably belies a lack
of deep understanding of C or GCC or both. In every case I tried,
'const int ai[] = { 1 };' (and volatile ...) was translated to an
immediate value of 1.
Trev
On Mon, Jul 6, 2009 at 11:45 AM, Ian Lance Taylor wrote:
> Trevor Scroggins writes:
>
>> No, that won't work. The assembler only recognizes .text, .data, and
>> .bss and doesn't support .section. Surely there's a simple hook that
>> instructs that compiler to print locals after a function instead of
>> before it?
>
> No. Why should there be? Even if you fix the case of string constants,
> you will run into trouble as soon as somebody writes
> const int ai[] = { 1 };
>
> Most systems require some sort of startup code to run before main,
> anyhow. If you have no such requirement, then I recommend simply being
> disciplined in how you write the "main" function, or paying the cost of
> two or four initial bytes to branch to the main function from the start
> of the .text section.
>
> Ian
can_throw_internal affected by inlining?
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 position in the tree is whether or not it might throw, and the only thing that changes with inlining is increased knowledge of whether and how it throws. The only thing I can imagine is that somehow an inline function was incorrectly marked as nothrow, and then it was inlined exposing the throw (i.e. resx) which then led the problem you report. On the trans-mem branch this is causing me problems. I'm replacing a direct function call with an indirect function call. Neither can be inlined, but inlinable_call_p thinks that it's a possibility for the indirect function call. With your logic, this magically changes a statement from !can_throw_internal to can_throw_internal. Which then of course results in a verify_cfg abort. r~
Re: CONSTANT_POOL_BEFORE_FUNCTION has no effect in tm.h?
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 targets appear to
> do something similar in TARGET_MACHINE_DEPENDENT_REORG to relocate
> read-only data to a safe jump distance. Where should I begin looking
> in source/documentation to gain an understanding of the process?
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.
> Also, I don't really grok your example, which probably belies a lack
> of deep understanding of C or GCC or both. In every case I tried,
> 'const int ai[] = { 1 };' (and volatile ...) was translated to an
> immediate value of 1.
If you write
const int ai[] = { 1 };
int main() { }
then in some cases the global const variable will be put into the
readonly section of the object file before the function.
Ian
Re: CONSTANT_POOL_BEFORE_FUNCTION has no effect in tm.h?
> 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 put into the
> readonly section of the object file before the function.
Ah. Understood.
/* [static] */ const int ai[] = { 1 };
int main () { }
locates a .long 1 in .text before main() just as
int main ()
{
foo("bar");
}
locates an .ascii "bar\0" in .text before main().
So, I'd have to relocate read-only globals as well.
Trev
