On Tue, Sep 14, 2010 at 9:47 PM, Ian Lance Taylor wrote:
> So far my best guess is that your definition is
> "warn about implicit conversions from float to double except for those
> conversions caused by default argument promotion applied to arguments
> passed to unnamed parameters." Is that what
On Tue, Sep 14, 2010 at 8:44 PM, Ian Lance Taylor wrote:
> Let me put it a different way: what is it that you want, expressed in
> terms of C/C++ code? What should the compiler be warning about?
Hmm. I think the provided example captures most of what i care about,
float area(float radius) { ret
On Tue, Sep 14, 2010 at 7:14 PM, Ian Lance Taylor wrote:
> What is it that you want?
I'd like to have a warning for when a value of type float is
implicitly promoted to double, for performance reasons (on x86). Note
that in that context, caring about variadic functions makes little
sense to begin
On Tue, Sep 14, 2010 at 4:58 PM, Ian Lance Taylor wrote:
> This question is not appropriate for the mailing list g...@gcc.gnu.org.
> ...
> This is among the kinds of things which -Wdouble-promotion is documented
> to warn about, so, yes, this is how it's meant to be.
Honestly i've pondered not sen
On Tue, Sep 14, 2010 at 4:51 PM, Ian Lance Taylor wrote:
> Please do file a PR if there isn't one already. Thanks.
I have no idea if that could happen outside C++ and couldn't find
anything relevant, thus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45668
That's the best i can do.
And thanks for y
Hello,
I could really use -Wdouble-promotion but, atm, it appears quite impractical,
$ cat double.cc
#include
void foo(...);
int main() {
float f = 1;
foo(f);
printf("%f", f);
}
$ /usr/local/gcc-4.6-20100913/bin/g++ -Wdouble-promotion double.cc
double.cc: In function 'int m
Hello,
i know it's no good form to reply to self, or be that insistent, but
i've been hit again.
In the bug report discussion, i've been told by A. Pinski that, as of
now, forward declarations shall have matching attributes. That's fine,
i suppose. What's not is that:
. that new behavior, as far
On Fri, Sep 10, 2010 at 5:20 PM, Ian Lance Taylor wrote:
> Since you do have a test case, you could try using a tool like delta to reduce
> it to something that you can share.
My delta-fu is too weak to get anywhere with an error so easily
produced (mismatched prototype, plus g++ senseless diagnos
Since about 2010/09/07 i've had a weird error with a mismatched
prototype involving an argument once forward declared as 'class foo;'
and later defined as 'class __attribute((aligned(16))) foo {...};', a
bit like
namespace n1 {
class fwd;
namespace n2 {
class foo {
void bar(fw
On Fri, Apr 23, 2010 at 5:48 AM, Dave Korn
wrote:
> Dear tbp, please don't accuse people of being deceptive or fraudulent, it is
> not a nice thing to do.
Indeed. That wasn't the intent.
Seeing libstdc++ being combed over for constexpr, i've conveniently
fooled myself in
On Thu, Apr 22, 2010 at 7:23 AM, Xinliang David Li wrote:
> The dead store problem seems to be a regression in SRA.
Thanks for looking into it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43846
On Thu, Apr 22, 2010 at 6:36 AM, Paolo Carlini wrote:
> In any case, keep in mind that constexpr are not available yet, maybe the
> parser can already recognize some uses but the semantics is not done yet.
Ah, so it was nothing but smokes & mirrors. Thanks for the clarification.
Hello,
having finally built myself a 4.5.0 (linux x86-64), i've quickly tried
it on some of my code and it soon became apparent some things weren't
for the better.
Here's my febrile attempt to sum up what surprised me
$ cat huh.cc
#include
#if __GNUC__ * 100 + __GNUC_MINOR__ < 405
#define
On Mon, Oct 19, 2009 at 7:34 PM, Ian Lance Taylor wrote:
> Please file a bug report.
> __attribute__((optimize())) is definitely only half-baked.
Apparently the code i've posted is just a variation around that 1 year
old PR 37565 and if that doesn't work, worrying about the rest is
entirely futile
Hang on while i put on my flame-proof suit. There.
Merrily trying to make a test-case showing how unmanageable it is to
try to override *math* flags per function, i soon had to stop
because...
$ cat amusing.cc
#include
static __attribute__((optimize("-fno-associative-math"))) double
foo1(double x)
Hello.
the autovectorizer is enabled by default in g++ 4.3 and does a fine
job most of the time. Except it gets mightily pissed off if you dare
to tweak the alignment and after much experimentation i haven't yet
devised how to plug all the holes.
This silly example shows where things start to get u
On Dec 29, 2007 4:35 PM, Uros Bizjak <[EMAIL PROTECTED]> wrote:
> Attached patch fixes these problems by using correct shortcuts when
> generating intrinsic functions.
>
> Patch was bootstrapped and regression tested with {,-m32} on
> x86_64-pc-linux-gnu. Patch is committed to SVN.
>
> Thanks a lot
Merry xmas,
i lately had some use for -mrecip but it turned out to come with all
sorts of strings attached and apparently no opt-out. Briefly, barring
inline asm, i can't get gcc to emit those ops without a NR fixup.
# cat src/pr-recip.c
#include
typedef float v4sf_t __attribute__ ((__vector_siz
On Nov 29, 2007 9:29 PM, Weddington, Eric <[EMAIL PROTECTED]> wrote:
> and I would also postulate the general embedded community, would
> *really* like to have this functionality, especially your Stage 1. There
> are many AVR, or embedded, applications where they are generally
> optimized for size,
Paolo Bonzini wrote:
I'm not sure that it is *so* useful for a user to have access to it,
except for specialized cases:
As there's other means, it may not be that useful but for sure it's
extremely convenient.
2) selection operations on vectors, kind of (v1 <= v2 ? v3 : v4). These
can be wri
Mark Mitchell wrote:
One option is for the user to use intrinsics. It's been claimed that
results in worse code. There doesn't seem any obvious reason for that,
but, if true, we should try to fix it; we don't want to penalize people
who are using the intrinsics. So, let's assume using intrinsi
On 8/23/07, Tim Prince <[EMAIL PROTECTED]> wrote:
> The primary icc/icl use of SSE/SSE2 masking operations, of course, is in
> the auto-vectorization of fabs[f] and conditional operations:
>
> sum = 0.f;
> i__2 = *n;
> for (i__ = 1; i__ <= i__2; ++i__)
> if (a[i__] > 0.f
On 8/23/07, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> I've added 5 minutes ago an XFAILed test for exactly this code. OTOH, I
> have also committed a fix that will avoid producing tons of shuffle and
> unpacking instructions when function "bar" is compiled with "-msse" but
> without "-msse2".
Tha
Paolo Bonzini wrote:
Because it's *not* strictly typed. Strict typing means that you accept
the same things accepted for the element type. So it's not a
regression, it's a bug fix.
# cat regressionorbugfix.cc
typedef float v4sf_t __attribute__ ((__vector_size__ (16)));
typedef int v4si_t __at
Paolo Bonzini wrote:
To some extent I agree with Andrew Pinski here. Saying that you need
support in a generic vector extension for "vector float | vector float"
in order to generate ANDPS and not PXOR, is just wrong. That should be
done by the back-end.
I guess i fail to grasp the logic mand
Andrew Pinski wrote:
Which hardware (remember GCC is a generic compiler)? VMX/Altivec and
SPU actually does not have different instructions for bitwise
and/ior/xor for different vector types (it is all the same
instruction). I have ran into ICEs with even bitwise on vector
float/double on x86 a
Ross Ridge wrote:
If I were tbp, I'd just code all his vector operatations using intrinsics.
The other responses in this thread have made it clear that GCC's vector
arithemetic operations are really only designed to be used with the Cell
Broadband Engine and other Power PC processors
On 8/22/07, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> I think you're running too far with your sarcasm. SSE's instructions do
> not go so far as to specify integer vs. floating point. To me, "ps"
> means "32-bit SIMD", independent of integerness.
Excuse me if i'm amazed being replied bitwise ops
Ian Lance Taylor wrote:
What does it mean to do a bitwise-or of a floating point value?
Apparently enough for a small vendor like Intel to propose such things
as orps, andps, andnps, and xorps.
So, that's what i feared... it was intentional. And now i guess the only
sanctioned access to those o
Hello,
# cat vecop.cc
template T foo() {
T
a = { 0, 1, 2, 3 }, b = { 4, 5, 6, 7 },
c = a | b,
d = c & b,
e = d ^ b;
return e;
}
int main() {
typedef float v4sf_t __attribute__ ((__vector_size__ (16)));
On 7/24/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
For performance small arrays should be the same as individual members
(I can see the annoying fact that initialization is a headache - this has
annoyed me as well). For larger arrays (>4 members), aliasing will
make a difference possibly, m
On 7/19/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
Of course, if any then the array indexing variant is fixed. It would be nice
to see a complete testcase with a pessimization, maybe you can file
a bugreport about this?
There's many issues for all alternatives and i'm not qualified to
pinp
On 7/19/07, Dave Korn <[EMAIL PROTECTED]> wrote:
Bogus codegen is the inevitable result of bogus code. Garbage in, garbage
out.
BTW, the const indexing is completely undefined too.
That's the kind of answer i'd get from gcc-help and at that point i'd
be none wiser because i already know th
On 7/19/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
Of course, if any then the array indexing variant is fixed. It would be nice
to see a complete testcase with a pessimization, maybe you can file
a bugreport about this?
By essence they're hard to trigger in small testcases (that's not
wher
On 7/19/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
Well, I always used the array variant, but you should be able to do
[snip]
if you need to (why does the array form not work for you?)
Because if you bench in some non trivial program, on x86/x86-64 at
least, those variations (struct { flo
I have that usual heavy duty 3 fp components class that needs to be
reasonably efficient and takes this form for g++
struct vec_t {
float x,y,z;
const float &operator()(const uint_t i) const { return *(&x + i); }
float &operator()(const uint_t i) { return *(&x + i); } // <-
On 6/18/07, Uros Bizjak <[EMAIL PROTECTED]> wrote:
IMO, due to limited range of operands for -mrecip pass (inf, -inf);
where 0.0 is excluded, it should be keept out of -ffast-math. There is
no point to fix reciprocals only for 0.0, we need to fix both
conversions for infinity and 0.0, even in -f
On 6/18/07, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
I understand your problems, but let me state that your objections are
totally subjective. *You* need a specific behaviour from -ffast-math
(eg: keep NaN/Inf), but that's not what *I* need. So, we have different
goals.
No. My NaN are my problem
On 6/18/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
No, that's not the contract with -ffast-math. Note that -ffast-math
enables -funsafe-math-optimizations which is allowed to change results
(add/remove rounding operations, contract expressions, do transforms
like a/b to a * 1/b, do transfor
On 6/18/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
Of course there are cases with every optimization enabled by -ffast-math that
can break existing programs. Just that we know of one case beforehand shouldn't
prevent us from enabling -mrecip at -ffast-math (provided -mno-recip
still works,
On 4/2/07, Richard Henderson <[EMAIL PROTECTED]> wrote:
On Mon, Apr 02, 2007 at 04:23:21PM +0200, tbp wrote:
> Am i just wrong believing that ought to work?
Yes.
It's hard to argue with a terse compiler or maintainer. Perhaps i
should have picked an easier target like
http
While doing (or trying to) some cleanup thanks to -mcx16, i've been a
bit surprised that
<--< cut <--<
typedef int TItype __attribute__ ((mode (TI)));
TItype m_128;
void test(TItype x_128)
{
m_128 = __sync_val_compare_and_swap (&m_128, x_128, m_128);
}
#include
typedef __m128i foo_t;
//
On 1/29/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
It doesn't need to be a small testcase. If you have a preprocessed
source file and a command-line, I'm sure one of the GCC developers would
be able to analyze the situation. We're all good at isolating problems,
even starting with big complic
On 1/28/07, Jan Hubicka <[EMAIL PROTECTED]> wrote:
BTW when inlining seems to make so noticeable difference, did you try to
use profile feedback?
Once a year, i try.
But then it boils down to the fact that as a programmer i have no way
to express how/where i want gcc to put its nose into. And i
On 1/28/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Certainly, if we're generating zillions of zero-initializations to
contiguous memory, rather than using memset, or an inline loop, that
seems unfortunate. Would you please file a bug report?
Because it takes, or seems to, a large function wit
On 1/28/07, Jan Hubicka <[EMAIL PROTECTED]> wrote:
I am not quite sure what you mean by direct inlining here. At -O2 G++
Decorating everything in sight with attribute always_inline/noinline
(flatten wasn't an option because it used to be troublesome and not as
'portable' across compilers).
I
On 1/28/07, Jan Hubicka <[EMAIL PROTECTED]> wrote:
Also having some testcases showing inlining deffects in GCC would be
very interesting for me. Now after IPA-SSA has been merged, I plan to
do some retuning of inliner for 4.3 release since a lot has changes
about properties of it's input and it
On 1/28/07, Jan Hubicka <[EMAIL PROTECTED]> wrote:
Actually we do have one stack frame shrinking pass already. It depends
on where the bloat is comming from - we can pack (with some limitations)
memory used by structures/arrays used by different inline functions or
lexical blocks. We don't do a
On 1/28/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
On 1/28/07, tbp <[EMAIL PROTECTED]> wrote:
> objdump -wdrfC --no-show-raw-insn $1|perl -pe 's/^\s+\w+:\s+//'|perl
> -ne 'printf "%4d\n", hex($1) if /sub\s+\$(0x\w+),%esp/'|sort -r| head
>
Let it be clear from the start this is a potshot and while those
trends aren't exactly new or specific to my code, i haven't tried to
provide anything but specific data from one of my app, on
win32/cygwin.
Primo, gcc getting much better wrt inling exacerbates the fact that
it's not as good as oth
[ -f stage_final ] || echo stage3 > stage_final
make[1]: Entering directory `/cygdrive/d/src/gcc/gcc-4.3-20070126/yo'
make[2]: Entering directory `/cygdrive/d/src/gcc/gcc-4.3-20070126/yo'
make[3]: Entering directory `/cygdrive/d/src/gcc/gcc-4.3-20070126/yo'
rm -f stage_current
make[3]: Leaving dir
On 8/6/06, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> Is there a way to enable such exotic codegen for 32bit environments?
With libgcc-math you didn't have exotic instructions, but you had
trascendental operations compiled with -mfpmath=sse and with a special
ABI. -mfpmath=sse won about 8% over
Basically i'd like to have the cake and also eat it.
With g++-4.2-20060805/cygwin on a k8 box on some software path with
lots of sp float ops but no transcendentals or library calls
-mfpmath=sse,387: 5.2 Mray/s
-mfpmath=sse: 6 Mray/s
That 15% performance difference is no surprise when you see thi
As i don't know which party (g++, stdc++, cygwin) to put the blame on
i'll start here.
I've traced back a weird performance issue to a 'new' returning non
cpu-local memory but only when the binary is launched from the
shell/console. That suggests some crt friction.
(threads where those allocations
On 6/19/06, Richard Guenther <[EMAIL PROTECTED]> wrote:
Using -mfpmath=sse -msse2 is a workaround if you have a processor that supports
SSE2 instructions. As opposed to -ffloat-store, it works reliably and
with no performance
impact.
Such slab test can be turned into a branchless sequence of SS
On 3/13/06, Richard Guenther <[EMAIL PROTECTED]> wrote:
> I don't think this is related, and a quick check with the patch shows
> still unaligned
> moves to the stack.
Patience is a virtue i guess :)
Is there good chances your inlining fix will hit mainline soon?
On 3/13/06, tbp <[EMAIL PROTECTED]> wrote:
> On 3/13/06, Richard Guenther <[EMAIL PROTECTED]> wrote:
> > http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00739.html
> /me ventilates.
> You're my hero.
A double+ hero on top of that.
http://gcc.gnu.org/ml/gcc-patches/20
On 3/13/06, Richard Guenther <[EMAIL PROTECTED]> wrote:
> http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00739.html
/me ventilates.
You're my hero.
On 3/13/06, Richard Guenther <[EMAIL PROTECTED]> wrote:
> I see the bug and will have a fix in a moment.
You made my day. Or you're about to. Unless you're lying and i'll have
to curse you for 7 generations.
On 3/13/06, Richard Guenther <[EMAIL PROTECTED]> wrote:
> Of course from 4.1.0 on you can easier stick an
> __attribute__((flatten)) on the function you want everything inlined to
> (finalblow) and get everything inlined into it.
But that's not really what i'm after: i expect trivial functions to
g
On 3/13/06, Richard Guenther <[EMAIL PROTECTED]> wrote:
> Starting with gcc 4.1.0 we have inline heuristics in place that will _always_
> inline such simple "wrappers". So, if this still happens, there is a bug in
> the
> heuristics and that should be reported. Before 4.1.0 the heuristics were
On 3/13/06, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
>Wait wait. PR/21195 is about inlining
> the SSE builtins.
No. PR/21195 was really about inline heuristic going ballistic.
Those intrinsics are thin wrappers around builtins, and ultimately
resolve to a couple of operations. Typical C++ (accesso
On 3/13/06, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> Actually the best way of improving the inline heuristics is to get
> a real testcase (and not some benchmark) where the inline heuristics
> is messed up.
Ah, you mean a brand new testcase because PR-21195 wasn't good enough?
$ /usr/local/gcc-
On 3/12/06, Steven Bosscher <[EMAIL PROTECTED]> wrote:
> > Yes, why is the benchmark not valid?
>
> It is valid. We should understand why this behavior has changed so
> drastically.
This benchmark maybe useless, it still exposes a weakness of gcc4. At
least it's not news to me:
http://gcc.gnu.org
On 3/11/06, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> Unlikely, since you haven't described at all what the problem is.
> That's why we prefer bug reports with testcases.
"...segfaults due to bogus SSE alignments"
40666a: movaps %xmm0,0x348(%esp)
d like to know if it's a known issue by any
chance.
Regards,
tbp.
;t imply
explicitely force inlining everything in sight, i'd like to know. Or
if there's something in the work.
Regards,
tbp.
On 2/4/06, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> Dale Johannesen and I came up with a patch to the C++ front-end
> for this except it did not work with some C++ cases.
Ah, so i'm not totally inane.
Is there a PR i can track for this one?
As i coulnd't understand why g++ insisted on spitting movq $0,
only to rewrite the same place a few cycles behind (with a different
width), i've made a testcase and now 20mn later i'm even more puzzled.
#include
#include
struct dir_t { __m128 x,y,z; };
int creative_codegen(const struct dir_t
On 1/25/06, Diego Novillo <[EMAIL PROTECTED]> wrote:
> You'll need to do what this message suggests. http://gcc.gnu.org/bugzilla/
Sorry for the lag.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25983
On 1/25/06, Diego Novillo <[EMAIL PROTECTED]> wrote:
> Well, the compiler still shouldn't ICE. I'll send a fix shortly.
I know i've exhausted my pseudo-ICE quota for the day, but i have
another candidate knocking at the door with insistence:
src/raytrace_packet.cpp: In member function 'void rt::ra
On 1/25/06, Diego Novillo <[EMAIL PROTECTED]> wrote:
> A couple more weeks, or you can try the gomp branch.
Thanks, will do.
Hopefully i won't fall for the ICE trick that easily next time.
On 1/25/06, Richard Henderson <[EMAIL PROTECTED]> wrote:
> c++ gomp is not merged to mainline.
Indeed, that makes up for a solid reason not to work.
Should i hold my breath?
Hello,
I wanted to play a bit with OpenMP after fighting a (long) while to
get a 4.2 snapshot compiled on my debian64 box... alas...
fresh svn checkout, multilib disabled because it's a no go on my box.
# /usr/local/gomp/bin/g++ -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured
Hello,
after setting up the latest snapshot, i was caught off guard as all my
numbers were off (and usually it's better than a swiss clock).
So, i've double checked, stripped some cruft from compiler command
line and pitted various snapshots (20050410, 20050424, 20050501) vs
20050508 in my app.
No
On 5/8/05, Steven Bosscher <[EMAIL PROTECTED]> wrote:
> Hi,
Hello,
> I have looked at the GCSE CPROP passes with CSE path following
> disabled ("-O1 -fgcse --param max-cse-path-length=1"). The input
> code are the cc1-i files from 20040726 (with checking enabled).
While that discussion flies way
On 5/3/05, Scott Robert Ladd <[EMAIL PROTECTED]> wrote:
> tbp wrote:
> Granted, POV-Ray may not be state-of-the-art, but then, I know quite a
> few people who say that (even legitimately) about just about every
> software product in existence.
True. Still, POV has evolved fr
On 5/2/05, Scott Robert Ladd <[EMAIL PROTECTED]> wrote:
> You might want to a look at my just-published review of GCC 4.0, where I
> compare it's performance on some well-known applications, including LAME
> and POV-Ray, on Pentium 4 and Opteron. In terms of POV-Ray, 4.0 produced
> a smaller execut
On 4/29/05, Uros Bizjak <[EMAIL PROTECTED]> wrote:
> Hello Scott!
Hello Scott & Uros,
> > Specifically, the -funsafe-math-optimizations flag doesn't work
> > correctly on AMD64 because the default on that platform is
> > -mfpmath=sse. Without specifying -mfpmath=387,
> > -funsafe-math-optimizatio
On 4/20/05, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> Yes this was intentional, you should not be using the builtin functions,
> instead use intrinsics from the header files.
Now that intrinsics are first class citizens it would be a real plus
if someone could convince gcc to not spit horrors like
On Apr 6, 2005 2:08 PM, tbp <[EMAIL PROTECTED]> wrote:
> I'll try to pinpoint the problem a bit better.
Alas, since the other day the code using that static array has changed
a bit and i can't reproduce the bug.
So, after all, it really was gcc's fault.
I'll try to dig up the original version.
On Apr 6, 2005 3:18 AM, James E Wilson <[EMAIL PROTECTED]> wrote:
> I would guess a limitation of cygwin binutils support, or perhaps of
> Windows itself.
Binutils, perhaps. Windows certainly not as msvc2k3 & icc8.1 don't
have such issue with the same code.
> This seems to work fine on linux. If
Ok, since i've already looked like an uneducated fool today and i'm
grasping at straws...
Question: why do i get an unaligned array as soon as g++ (4.1.0
20050327, cygwin) finds out that it's static (i mean even if i try to
fool it around a bit)?
It seems to only happen with multidimensionnal arra
On Apr 4, 2005 1:04 PM, Jonathan Wakely <[EMAIL PROTECTED]> wrote:
> Hope that helps,
Yes, thanks and for once gcc warning was explicit enough (with a hint
about namespace) for me to fix it.
I stand corrected.
On Apr 4, 2005 12:50 PM, Jonathan Wakely <[EMAIL PROTECTED]> wrote:
> GCC 3.4 *does* whine, and I think Intel will in strict mode.
Can't get neither gcc 3.4.1 to whine about it (-Wall) nor icc 8.1 with
the highest warning level enabled.
On Apr 4, 2005 12:21 PM, Nathan Sidwell <[EMAIL PROTECTED]> wrote:
> That's not a declaration, it's a definition of an already declared fn.
> the case you had was a definition that was _also_ a declaration.
[...]
> See the difference?
Yes, and i know about it...
> Although it is kind of quirky tha
On Apr 4, 2005 11:54 AM, Nathan Sidwell <[EMAIL PROTECTED]> wrote:
> > Am i missing something obvious?
> well, not 'obvious', but that is what [14.7.3]/2 says.
I especially don't quite get why specialization have to be defined
that way when non specialized version don't have to, ie that is legit:
n
Hello,
i'm a bit puzzled by the behaviour of gcc4 (old 4.0 & recent 4.1
snapshots) regarding how template specialization should be qualified
wrt namespace:
namespace dummy {
struct foo {
template void f() {}
};
}
template<> void dummy::foo::f<666>() {}
testcase.c
88 matches
Mail list logo
