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
Hello,
I could really use -Wdouble-promotion but, atm, it appears quite impractical,
$ cat double.cc
#include cstdio
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
On Tue, Sep 14, 2010 at 4:51 PM, Ian Lance Taylor i...@google.com 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.
On Tue, Sep 14, 2010 at 4:58 PM, Ian Lance Taylor i...@google.com 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
On Tue, Sep 14, 2010 at 7:14 PM, Ian Lance Taylor i...@google.com 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
On Tue, Sep 14, 2010 at 8:44 PM, Ian Lance Taylor i...@google.com 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
On Tue, Sep 14, 2010 at 9:47 PM, Ian Lance Taylor i...@google.com 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
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
On Fri, Sep 10, 2010 at 5:20 PM, Ian Lance Taylor i...@google.com 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++
On Thu, Apr 22, 2010 at 6:36 AM, Paolo Carlini paolo.carl...@oracle.com 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
On Thu, Apr 22, 2010 at 7:23 AM, Xinliang David Li davi...@google.com 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 Fri, Apr 23, 2010 at 5:48 AM, Dave Korn
dave.korn.cyg...@googlemail.com 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
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 cmath
#if __GNUC__ * 100 + __GNUC_MINOR__ 405
On Mon, Oct 19, 2009 at 7:34 PM, Ian Lance Taylor i...@google.com 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
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 cmath
static __attribute__((optimize(-fno-associative-math))) double
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
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 for
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 xmmintrin.h
typedef float v4sf_t __attribute__
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, but
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
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
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.
Thing
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
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
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
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.
Thanks.
I'm
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/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 on
Hello,
# cat vecop.cc
templatetypename T 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__
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
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,
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
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 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 {
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
where
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
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
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, 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
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,
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 xmmintrin.h
typedef __m128i
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://gcc.gnu.org
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
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
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
-n 10
msvc:2196 2100 1772 1692 1688 1444 1428 1312 1308
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
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:
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:
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
[ -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
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
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
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 SSE
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++
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
bogus
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
get
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:
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00739.html
/me ventilates.
You're my hero.
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/2006-03/msg00737.html
I think i've hit
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/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:
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?
$
.
Regards,
tbp.
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)
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, stack
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 xmmintrin.h
#include stdio.h
struct dir_t { __m128 x,y,z; };
int
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
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
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?
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, 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
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 above
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.
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 from dkbtrace and it shows
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 executable
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-optimizations does not
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 I
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.
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 int i void f() {}
};
}
template void dummy::foo::f666() {}
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:
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 that you
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.
84 matches
Mail list logo
